RFC 1274
The COSINE and Internet X.500 Schema
RFC 1274: The COSINE and Internet X.500 Schema ๐
Okay bestie, let's get into it ๐ This is RFC 1274, The COSINE and Internet X.500 Schema, from the Network Working Group. It was written by P. Barker and S. Kille of University College London and is dated November 1991 ๐ The category is an IAB standards track protocol, and the header doesn't list any obsoletes or updates ๐ฆ
Status of this Memo โจ
So this is an IAB standards track protocol for the whole Internet community ๐ and they're literally asking for discussion and suggestions for improvements ๐ฌ For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" ๐ And distribution of this memo is unlimited ๐ซถ
Abstract ๐ธ
This doc suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots ๐ง The schema doesn't depend on any specific implementation, which is so smart ๐ Besides indicating support for the standard object classes and attributes, it defines a big pile of generally useful object classes and attributes too ๐ There's also an appendix with a machine processable version of the schema ๐ค
The doc also proposes a way for the schema to evolve alongside emerging requirements ๐ฆ Proformas to support that process are included ๐
Corrections and additions to the schema should be sent to na-update@cs.ucl.ac.uk, as described within ๐
1. Introduction ๐
Directory Services are a fundamental requirement of both human and computer communications' systems ๐ Humans need to be able to look up details about other people, like telephone numbers, facsimile numbers and paper mail addresses ๐ Computing systems need Directory Services too, for things like supporting address look-ups for a variety of services, and for user-friendly naming and distribution lists in electronic mail systems ๐ฌ
Directory Services have recently been standardised and published as the 1988 CCITT X.500 / ISO IS9594 recommendations [1] โจ It's a good basis for real services, and a considerable amount of Directory Service piloting activity is currently underway ๐ฅ In the U.S., the PSI White Pages Pilot [4] has stimulated use of X.500 on the Internet ๐บ๐ธ In Britain, the U.K. Academic Community Directory Pilot [5] is similarly promoting use of X.500 ๐ฌ๐ง It's giving momentum, no cap ๐
2. Motivation and aims of this document ๐ฆ
In a number of areas the X.500 standard only provides a basis for services ๐ One of those areas is the Directory's Schema or Naming Architecture ๐งฉ The standard defines a number of useful object classes, in X.521, and attribute types, in X.520 ๐ They're meant to be generally useful across a range of directory applications ๐ But while these standard definitions are a useful starting point, they're not enough as a basis for a large scale pilot directory ๐ญ
Administrators can define their own sets of additional attribute types and object classes, and that's allowed, but it's undesirable for some common attributes and objects ๐ The same objects and attribute types would get privately defined many times over ๐ That would make the directory's generality weaker, because remote systems wouldn't be able to work out the semantics of these privately defined data types ๐ซ
A number of useful additions to the standard definitions were made in this note's forerunner, "The THORN and RARE Naming Architecture" [2] ๐ They've been heavily used in early X.500 piloting activities ๐ฅ Both the THORN and Quipu X.500 implementations have used these definitions too ๐
Since that earlier note came out, a number of further requirements have shown up as the volume and variety of piloting activity has grown ๐ Even more requirements seem likely as the scale of X.500 pilot services increases ๐ So it's argued that just reissuing an updated version of the original note isn't sufficient ๐ โโ๏ธ The schema is a "living document" that needs procedures for:
- Allowing submission of requests for new attributes and object classes to be added into the schema;
- Allowing groups of object classes and attribute types defined elsewhere to be integrated into the schema.
- Checking for the redundancy of any previously defined attribute types and object classes.
This document tries to set up procedures for continually updating the schema ๐ Two proformas are set out for this purpose ๐ It also gives descriptive detail for the additional object classes and attribute types defined in the schema ๐งพ Those descriptions follow the style used in X.520 and X.521 ๐ Finally, in line with the style of the standards documents, appendices will include the entire schema ๐ The plain text versions of the appendices are meant to be machine processable, so a system's schema tables can be derived from them ๐ค Appendix C lists all the schema's object classes and attribute types in their respective ASN.1 macro formats ๐ง
The scope and intended remit of this coordination activity should be clearly understood ๐
- Esoteric and local, highly experimental requirements should continue to be met by private definitions.
- Requirements which have support from more than one site will usually be integrated into the schema. Put another way, the tendency will be to include useful additions to the schema rather than exclude them ๐
- An attempt will be made to avoid duplication of object classes and attribute types for essentially similar real world objects ๐ซถ
3. What conformance to this schema means ๐
It's not reasonable to require that a DSA which supports this schema has specific code to handle each of the defined syntaxes ๐ โโ๏ธ However, the following requirements are made of a system that claims conformance to this specification ๐
- A DSA shall be able to store all of the attributes and object class values specified. (Note that this implies support for all the object classes and attribute types required by strong authentication as defined in X.509.) ๐
- A DUA shall be able to identify each attribute type and object class to the user, with an appropriate representation (e.g., a string). ๐ท๏ธ
- These statement are qualified for large attributes values (>1kbyte). A conforming DSA does not have to store such attribute values, and a DUA does not have to display such values, although it must indicate their presence. ๐งพ
The following are desirable, but not required ๐ธ
- For a DSA to match correctly on the basis of all attribute syntaxes defined
- For a DSA to enforce the Object Class schema implied by these definitions
- For a DUA to correctly display the attribute values (syntaxes) defined
- For DUAs and DSAs to maintain compatibility with a previous version of the schema
4. Requesting new object classes and attribute types ๐
This section defines procedures for requesting new object classes and attribute types to be added to the schema ๐ Proformas for object classes and attribute types are specified, with examples of how to use them ๐ A mechanism for making requests for large groups of new object classes and attribute types is described in the next section ๐ง
As stated earlier, it's anticipated that the schema will evolve considerably over time ๐ฆ As X.500 gets used for a widening range of applications, there will be requirements for extensions to the schema ๐ This document proposes formalising this procedure by requiring requests for additions to the schema to be submitted as completed proformas ๐ That stipulation will greatly simplify subsequent revisions of the schema ๐
There is one qualification to the above when it comes to requests for modifications to an existing object class ๐ If a modification merely involves additional, optional attributes, the object class will be enhanced as requested โจ Systems are expected to be resilient to such changes to the schema ๐ช However, requests to modify an object class such that the mandatory attribute types require altering won't be met ๐ โโ๏ธ Instead, a new object class will be created, and the original object class expired following the scheme described in the next main section ๐ชฆ
It's anticipated that most requests for modifications to the schema will be met without any editorial intervention ๐ Sometimes, though, some discussion between the submitter of a request and the schema's editor may be required ๐ฌ For example, the editor may have to judge the relative merits of two very similar requests, and as a result one of the parties may not get quite what they want ๐ญ When the submitter of a request feels aggrieved about an editorial decision, the requestor may appeal to a broader community by explaining their views to the mailing list osi-ds@cs.ucl.ac.uk ๐ฃ We'll pay attention to any consensus that emerges from discussions on the schema on this list ๐ If it proves that this list is used almost solely for discussions on schema issues, a separate discussion list will be created ๐
To help produce the proformas mentioned above, tools are included in Appendix B that will verify a proforma has been correctly formatted ๐ ๏ธ
Completed proformas should be mailed to na-update@cs.ucl.ac.uk ๐
4.1. Object Class proforma ๐ง
This section gives an example, completed proforma for a new object class, alcoholic drink ๐ธ A proforma for object class specified in BNF is included in Appendix A ๐
Object Class: Alcoholic Drink
Description: The Alcoholic Drink object class is used to define
entries representing intoxicating beverages.
ASN1OCMacro: alcoholicDrink OBJECT-CLASS
SUBCLASS OF drink
MUST CONTAIN {
percentAlcohol}
MAY CONTAIN {
normalServing,
hue}
An object class description consists of three fields, separated by blank lines ๐ฉท The keywords Object Class, Description and ASN1OCMacro, and their suffixed colons, must be included exactly as above ๐
The Object Class field should be used for a textual description of the object class ๐ท๏ธ That's at most three or four words, so keep it snappy โจ
The Description field should contain some explanatory text about the intended use of the object class ๐ It can run to a number of lines ๐
The ASN1OCMacro field should follow the definition of the object class macro as specified in X.501 ๐ง The example above shows the main features, and there are many more examples to study in the section defining the Pilot Object Classes ๐ธ
4.2. Attribute type proforma ๐
okay so this bit gives us a finished example proforma for a brand new attribute type, hue ๐. it's one of the attribute types in the alcoholic drink object class ๐ธ, and it's giving very complete.
Attribute Type: Hue
Description: The Hue attribute type specifies the hue of
an object. (Note that a description may run to several
lines.)
OCMust:
OCMay: alcoholicDrink
ASN1ATMacro:hue ATTRIBUTE
WITH ATTRIBUTE SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-hue))
ub-hue INTEGER ::= 256
ok so an attribute type description has five fields, separated by blank lines ๐ . the keywords Attribute Type, Description, OCMust, OCMay and ASN1ATMacro, along with their suffixed colons, must be included exactly as above. no improvising on the spelling, bestie ๐ญ.
the Attribute Type field is for a textual description of the attribute type. this should be at most three or four words, so keep it snappy โจ.
the Description field is where you explain what the attribute type is meant to be used for. it can run to a number of lines, so go as long as you need ๐.
the OCMust field is a comma-separated list of the object classes for which this attribute is mandatory. it's the "you literally cannot skip this one" list ๐ โโ๏ธ.
the OCMay field is a comma-separated list of the object classes for which this attribute is optional. it's the "bring it if you want" list ๐ซถ.
the ASN1ATMacro field should follow the definition of the attribute macro as specified in X.501. the example above shows some of the features, and you should especially peep the format for specifying size constraints ๐. it's giving neat and precise.
5. Integrating groups of object classes and attribute types. ๐งฉ
okay this section describes two mechanisms that may be used to bring a whole bunch of new object classes and attribute types into the schema. it's a big deal, so listen up ๐ฃ.
the first mechanism lets groups of related, privately defined object classes and attribute types move into the schema. an example of when that might make sense is when some experimental use of the Directory has been widely adopted within the pilot ๐ฆ. this kind of transition will happen if the following conditions hold:
- The definitions are well structured: i.e., they are not scattered over a multiplicity of object identifier subtrees.
- The definitions are in use at a number of sites, and having to adopt new object identifiers would be unnecessarily disruptive.
the second mechanism lets you claim an object subtree for a group of new definitions. there's a pilotGroups object identifier that's been defined for exactly this purpose ๐ธ. this is the move for an experiment that needs a considerable number of new object identifiers. it leaves room to be flexible while you experiment, and it should make managing the pilot's object identifiers, and keeping them coherent, way easier ๐ง.
in both cases, the object classes, attribute types and syntaxes should be defined and described in an RFC. it's suggested that those documents follow the style this document uses for object class and attribute type definitions ๐. a reference will be given in this schema to the document that contains the definitions, so everyone can find them.
6. Removing "old" object classes and attribute types. ๐๏ธ
it's also super important that object classes and attribute types that are no longer used or useful get removed from the schema ๐. some object classes and attribute types that started out as pilot extensions might be included as standard definitions in future versions of the standard. when that happens, there should be a fairly rapid transition to the standard definitions. another possibility is that newer, more specific definitions make the original ones obsolete ๐.
two things are essential here, and I'm not kidding ๐ฅ.
First, it's crucial that "old" definitions get retired as gracefully as possible. the intention to retire a definition will be sent to the osi-ds@cs.ucl.ac.uk mail list. if nobody objects, the definition will be marked for expiry with a given expiry date. the definition stays in the schema until that expiry date. in the meantime, users of the schema should make sure they move over to the new, alternative definitions ๐ฆ.
Second, users of the schema must have the right to argue for keeping definitions they regard as necessary, especially when there are no other definitions that closely meet their requirements. it's clearly impossible to lay down hard and fast rules on this, because no two cases will ever be quite the same ๐คทโโ๏ธ. the refereeing on these matters is meant to be sympathetic, bestie! ๐ฅน as for requests for additions, an aggrieved user can "go to arbitration" by starting a discussion on the osi-ds@cs.ucl.ac.uk mail list โ๏ธ.
7. Object Identifiers ๐ข
some additional object identifiers are defined for this schema. they're also reproduced in Appendix C, so you can find them there too โจ.
data OBJECT IDENTIFIER ::= {ccitt 9}
pss OBJECT IDENTIFIER ::= {data 2342}
ucl OBJECT IDENTIFIER ::= {pss 19200300}
pilot OBJECT IDENTIFIER ::= {ucl 100}
pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
{pilotAttributeSyntax 5}
8. Object Classes ๐ท
8.1. X.500 standard object classes ๐
a number of generally useful object classes are defined in X.521, and these are supported here ๐. refer to that document for descriptions of the suggested usage of these object classes. the ASN.1 for these object classes is reproduced for completeness in Appendix C.
8.2. X.400 standard object classes ๐ฌ
a number of object classes defined in X.400 are supported too ๐. refer to X.402 for descriptions of how to use these object classes. the ASN.1 for them is reproduced for completeness in Appendix C.
8.3. COSINE/Internet object classes ๐
this section tries to fuse together the object classes designed for use in the COSINE and Internet pilot activities, which is a whole vibe ๐ซถ. descriptions are given of the suggested usage of these object classes. the ASN.1 for them is also reproduced in Appendix C.
8.3.1. Pilot Object ๐งธ
the PilotObject object class is used as a sub-class, so common, useful attributes can be assigned to entries of all the other object classes ๐.
pilotObject OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN {
info,
photo,
manager,
uniqueIdentifier,
lastModifiedTime,
lastModifiedBy,
dITRedirect,
audio}
::= {pilotObjectClass 3}
8.3.2. Pilot Person ๐งโ๐ค
the PilotPerson object class is used as a sub-class of person. it lets you assign a bunch of additional attributes to entries of the person object class ๐ .
pilotPerson OBJECT-CLASS
SUBCLASS OF person
MAY CONTAIN {
userid,
textEncodedORAddress,
rfc822Mailbox,
favouriteDrink,
roomNumber,
userClass,
homeTelephoneNumber,
homePostalAddress,
secretary,
personalTitle,
preferredDeliveryMethod,
businessCategory,
janetMailbox,
otherMailbox,
mobileTelephoneNumber,
pagerTelephoneNumber,
organizationalStatus,
mailPreferenceOption,
personalSignature}
::= {pilotObjectClass 4}
8.3.3. Account ๐ป
the Account object class is used to define entries that represent computer accounts ๐ฅ๏ธ. the userid attribute should be used for naming entries of this object class.
account OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
userid}
MAY CONTAIN {
description,
seeAlso,
localityName,
organizationName,
organizationalUnitName,
host}
::= {pilotObjectClass 5}
8.3.4. Document ๐
the Document object class is used to define entries that represent documents ๐.
document OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
documentIdentifier}
MAY CONTAIN {
commonName,
description,
seeAlso,
localityName,
organizationName,
organizationalUnitName,
documentTitle,
documentVersion,
documentAuthor,
documentLocation,
documentPublisher}
::= {pilotObjectClass 6}
8.3.5. Room ๐ช
the Room object class is used to define entries that represent rooms ๐๏ธ. the commonName attribute should be used for naming entries of this object class.
room OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
roomNumber,
description,
seeAlso,
telephoneNumber}
::= {pilotObjectClass 7}
8.3.6. Document Series ๐
the Document Series object class is used to define an entry that represents a series of documents, like The Request For Comments papers ๐ฆ.
documentSeries OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
description,
seeAlso,
telephoneNumber,
localityName,
organizationName,
organizationalUnitName}
::= {pilotObjectClass 9}
8.3.7. Domain ๐
the Domain object class is used to define entries that represent DNS or NRS domains ๐. the domainComponent attribute should be used for naming entries of this object class. the usage of this object class is described in more detail in [3].
domain OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
domainComponent}
MAY CONTAIN {
associatedName,
organizationName,
organizationalAttributeSet}
::= {pilotObjectClass 13}
8.3.8. RFC822 Local Part โ๏ธ
the RFC822 Local Part object class is used to define entries that represent the local part of RFC822 mail addresses ๐. it treats this part of an RFC822 address as a domain. the usage of this object class is described in more detail in [3].
rFC822localPart OBJECT-CLASS
SUBCLASS OF domain
MAY CONTAIN {
commonName,
surname,
description,
seeAlso,
telephoneNumber,
postalAttributeSet,
telecommunicationAttributeSet}
::= {pilotObjectClass 14}
8.3.9. DNS Domain ๐งโโ๏ธ
the DNS Domain (Domain NameServer) object class is used to define entries for DNS domains ๐ธ. the usage of this object class is described in more detail in [3].
dNSDomain OBJECT-CLASS
SUBCLASS OF domain
MAY CONTAIN {
ARecord,
MDRecord,
MXRecord,
NSRecord,
SOARecord,
CNAMERecord}
::= {pilotObjectClass 15}
8.3.10. Domain Related Object ๐ธ
okay so the Domain Related Object object class is for entries that stand in for DNS/NRS domains that are basically the "same thing" as an X.500 domain, like an organisation or an organisational unit ๐ขโจ. There's more on how to use this one in [3], so go check that if you want the full tea ๐ต.
domainRelatedObject OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
associatedDomain}
::= {pilotObjectClass 17}
8.3.11. Friendly Country ๐
The Friendly Country object class is for country entries in the DIT, and it's giving friendlier names than the regular country object class lets you use ๐. Quick reminder that the naming attribute of country, countryName, has to be a 2 letter string defined in ISO 3166, so no creative spelling there ๐
โโ๏ธ.
friendlyCountry OBJECT-CLASS
SUBCLASS OF country
MUST CONTAIN {
friendlyCountryName}
::= {pilotObjectClass 18}
8.3.12. Simple Security Object ๐
Simple Security Object is the lowkey hero for when an entry's main object classes don't let it have a userPassword attribute. This class gives it a pass to hold one anyway ๐ฆ.
simpleSecurityObject OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
userPassword }
::= {pilotObjectClass 19}
8.3.13. Pilot Organization ๐๏ธ
PilotOrganization is a sub-class of both organization and organizationalUnit. It lets those entries wear a few extra attributes, which is very main character energy ๐.
pilotOrganization OBJECT-CLASS
SUBCLASS OF organization, organizationalUnit
MAY CONTAIN {
buildingName}
::= {pilotObjectClass 20}
8.3.14. Pilot DSA ๐๏ธ
PilotDSA is a sub-class of the dsa object class, so DSA entries can pick up some extra attributes too ๐ง. The one that's required here is dSAQuality.
pilotDSA OBJECT-CLASS
SUBCLASS OF dsa
MUST CONTAIN {
dSAQuality}
::= {pilotObjectClass 21}
8.3.15. Quality Labelled Data ๐ท๏ธ
Quality Labelled Data is how you slap data quality attributes onto whole subtrees in the DIT ๐ . If you want the deeper dive, see [8].
qualityLabelledData OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
dSAQuality}
MAY CONTAIN {
subtreeMinimumQuality,
subtreeMaximumQuality}
::= {pilotObjectClass 22}
9. Attribute Types โจ
9.1. X.500 standard attribute types ๐
A bunch of generally useful attribute types are defined in X.520, and yes, they're all supported ๐. For descriptions of how each one is meant to be used, go to that document. The ASN.1 for these attribute types is copied over for completeness in Appendix C.
9.2. X.400 standard attribute types ๐ฌ
The standard X.400 attribute types are supported ๐. For the full details, check X.402. The ASN.1 for these attribute types is reproduced in Appendix C.
9.3. COSINE/Internet attribute types ๐
This section covers every attribute type defined for the COSINE and Internet pilots ๐ฆ. Each one comes with a note on its suggested usage. The ASN.1 for all of them is reproduced in Appendix C.
9.3.1. Userid ๐โโ๏ธ
Userid is a computer system login name, so it's basically your username ๐ป.
userid ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-user-identifier))
::= {pilotAttributeType 1}
9.3.2. Text Encoded O/R Address ๐ค
Text Encoded O/R Address is a text encoding of an X.400 O/R address, as specified in RFC 987 ๐. Honestly, this one is on its way out. It's deprecated because it was only ever meant for interim use.
This attribute will be the first candidate for the attribute expiry mechanisms! ๐
textEncodedORAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-text-encoded-or-address))
::= {pilotAttributeType 2}
9.3.3. RFC 822 Mailbox ๐ง
RFC822 Mailbox is an electronic mailbox attribute that follows the syntax from RFC 822 โ๏ธ. Heads up: this one shouldn't be used for greybook or other non-Internet order mailboxes ๐ โโ๏ธ.
rfc822Mailbox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
(SIZE (1 .. ub-rfc822-mailbox))
::= {pilotAttributeType 3}
9.3.4. Information โน๏ธ
Information is for any general info about an object ๐๏ธ. It's recommended that you avoid using this one for specific stuff, and put specific requirements into other attribute types (possibly extra ones) instead. Keep it clean, bestie ๐งน.
info ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-information))
::= {pilotAttributeType 4}
9.3.5. Favourite Drink ๐ง
Favourite Drink is the favourite drink of an object (or a person) ๐ฅค. Iconic, no notes.
favouriteDrink ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-favourite-drink))
::= {pilotAttributeType 5}
9.3.6. Room Number ๐ช
Room Number is the room number of an object ๐. Little tip (it's in the original, so it's legit): the commonName attribute should be used for naming room objects.
roomNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-room-number))
::= {pilotAttributeType 6}
9.3.7. Photo ๐ธ
Photo is a "photograph" for an object ๐ผ๏ธ. It's meant to be encoded in G3 fax as explained in recommendation T.4, and it gets an ASN.1 wrapper so it's compatible with an X.400 BodyPart as defined in X.420. Very old-school, very iconic ๐ซถ.
IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
information-objects }
photo ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
(SIZE (1 .. ub-photo))
::= {pilotAttributeType 7}
9.3.8. User Class ๐
User Class is a category of computer user ๐งโ๐. What it means is up to local interpretation. In academia you'll see stuff like undergraduate student, researcher, or lecturer. Also, the organizationalStatus attribute is often the better pick now, since it doesn't only cover computer users ๐ธ.
userClass ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-user-class))
::= {pilotAttributeType 8}
9.3.9. Host ๐ฅ๏ธ
Host is a host computer, nothing more, nothing less ๐ค.
host ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-host))
::= {pilotAttributeType 9}
9.3.10. Manager ๐
Manager is the manager of whatever object the entry represents ๐ผ.
manager ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 10}
9.3.11. Document Identifier ๐
Document Identifier is a unique ID for a document ๐โจ.
documentIdentifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-identifier))
::= {pilotAttributeType 11}
9.3.12. Document Title ๐ฐ
Document Title is the title of a document ๐.
documentTitle ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-title))
::= {pilotAttributeType 12}
9.3.13. Document Version ๐ข
Document Version is the version number of a document ๐ท๏ธ.
documentVersion ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-version))
::= {pilotAttributeType 13}
9.3.14. Document Author โ๏ธ
Document Author is the distinguished name of a document's author ๐๏ธ.
documentAuthor ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 14}
9.3.15. Document Location ๐
Document Location is where the document original lives ๐บ๏ธ.
documentLocation ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-location))
::= {pilotAttributeType 15}
9.3.16. Home Telephone Number โ๏ธ
Home Telephone Number is a home phone number tied to a person ๐ก. Values should follow the agreed format for international telephone numbers, like "+44 71 123 4567" ๐.
homeTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
telephoneNumberSyntax
::= {pilotAttributeType 20}
9.3.17. Secretary ๐๏ธ
Secretary is the secretary of a person, and its value is a distinguished name ๐โโ๏ธ.
secretary ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 21}
9.3.18. Other Mailbox ๐ฎ
Other Mailbox is for electronic mailbox types that aren't X.400 or rfc822 ๐คน. The example types in the grammar below (Telemail, X378) are just examples.
otherMailbox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
SEQUENCE {
mailboxType PrintableString, -- e.g. Telemail
mailbox IA5String -- e.g. X378:Joe
}
::= {pilotAttributeType 22}
9.3.19. Last Modified Time โฐ
Last Modified Time is the last time an entry was modified, in UTC time ๐ฐ๏ธ. Ideally, the DSA should be the one maintaining this attribute.
lastModifiedTime ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
uTCTimeSyntax
::= {pilotAttributeType 23}
9.3.20. Last Modified By ๐งโ๐ป
Last Modified By is the distinguished name of whoever last changed the entry ๐. Ideally, the DSA should maintain this one too.
lastModifiedBy ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 24}
9.3.21. Domain Component ๐
Domain Component is a DNS/NRS domain, like "uk" or "ac" ๐ฌ๐ง. It only holds one value (SINGLE VALUE), so pick wisely ๐.
domainComponent ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
SINGLE VALUE
::= {pilotAttributeType 25}
9.3.22. DNS ARecord ๐งญ
ARecord is the attribute for a type A (Address) DNS resource record [6] [7] ๐ก.
aRecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 26}
9.3.23. MX Record ๐ฌ
MX Record is the attribute for a type MX (Mail Exchange) DNS resource record [6] [7] ๐.
mXRecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 28}
9.3.24. NS Record ๐
NS Record is the attribute for an NS (Name Server) DNS resource record [6] [7] ๐ง.
nSRecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 29}
9.3.25. SOA Record ๐
SOA Record is the attribute for a type SOA (Start of Authority) DNS resource record [6] [7] ๐ฅ.
sOARecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 30}
9.3.26. CNAME Record ๐
CNAME Record is the attribute for a type CNAME (Canonical Name) DNS resource record [6] [7] ๐ซง.
cNAMERecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
iA5StringSyntax
::= {pilotAttributeType 31}
9.3.27. Associated Domain ๐ธ
okay so the Associated Domain attribute type is how you link a DIT object to a DNS or NRS domain ๐ฆ. like, the entry with the distinguished name "C=GB, O=University College London" gets an associated domain of UCL.AC.UK. โจ also!! all domains should be represented in rfc822 order, so keep that in mind ๐
. see [3] for more details of usage of this attribute ๐ซถ
associatedDomain ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
::= {pilotAttributeType 37}
9.3.28. Associated Name ๐ง
the Associated Name attribute type points at an entry in the organisational DIT that's associated with a DNS/NRS domain ๐ it's the other half of the 9.3.27 friendship ๐ฏโโ๏ธ see [3] for more details of usage of this attribute โจ
associatedName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 38}
9.3.29. Home postal address ๐ก
the Home postal address attribute type is where someone's home postal address lives ๐ this should be limited to up to 6 lines of 30 characters each, so keep it short and sweet ๐
homePostalAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
postalAddress
MATCHES FOR EQUALITY
::= {pilotAttributeType 39}
9.3.30. Personal Title ๐
the Personal Title attribute type holds a personal title for a person ๐ examples are "Ms", "Dr", "Prof" and "Rev". very iconic lineup, no notes ๐
personalTitle ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-personal-title))
::= {pilotAttributeType 40}
9.3.31. Mobile Telephone Number ๐ฑ
the Mobile Telephone Number attribute type is a mobile number tied to a person ๐ attribute values should follow the agreed format for international telephone numbers, like +44 71 123 4567 ๐
mobileTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
telephoneNumberSyntax
::= {pilotAttributeType 41}
9.3.32. Pager Telephone Number ๐
the Pager Telephone Number attribute type is for a pager number belonging to an object ๐ฆ same deal as above: attribute values should follow the agreed format for international telephone numbers, so +44 71 123 4567 is the vibe โญ
pagerTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
telephoneNumberSyntax
::= {pilotAttributeType 42}
9.3.33. Friendly Country Name ๐
the Friendly Country Name attribute type holds country names in a human readable format ๐ธ the standard attribute country name must be one of the two-letter codes defined in ISO 3166, so the friendly one is just the pretty version ๐
friendlyCountryName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
::= {pilotAttributeType 43}
9.3.34. Unique Identifier ๐
the Unique Identifier attribute type is a "unique identifier" for an object in the Directory โจ the domain it's unique within, and what it actually means, are for local definition ๐ง like, for a person it might be an institution-wide payroll number, and for an organisational unit it might be a department code ๐ผ
uniqueIdentifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-unique-identifier))
::= {pilotAttributeType 44}
9.3.35. Organisational Status ๐
the Organisational Status attribute type is the category a person is often known by inside an organisation ๐ฆ in academia that could be stuff like undergraduate student, researcher, lecturer, etc ๐
a Directory administrator should probably consider carefully the distinctions between this and the title and userClass attributes ๐ it's giving "think before you type" energy ๐ญ
organizationalStatus ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-organizational-status))
::= {pilotAttributeType 45}
9.3.36. Janet Mailbox ๐ฌ
the Janet Mailbox attribute type stores an electronic mailbox that follows the syntax in the Grey Book of the Coloured Book series ๐ it's here for the convenience of U.K users who aren't familiar with rfc822 and little-endian mail addresses, so it's a whole accessibility moment ๐ซถ
entries using this attribute MUST also include an rfc822Mailbox attribute. no exceptions, bestie ๐
janetMailbox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
(SIZE (1 .. ub-janet-mailbox))
::= {pilotAttributeType 46}
9.3.37. Mail Preference Option ๐ฃ
the Mail Preference Option attribute lets people say whether they want their names on mailing lists, electronic or physical ๐ if the attribute is absent, it should be read as if it were present with the value "no-list-inclusion" ๐ โโ๏ธ anyone using the directory to build mailing lists should interpret this attribute and respect its value ๐
mailPreferenceOption ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ENUMERATED {
no-list-inclusion(0),
any-list-inclusion(1), -- may be added to any lists
professional-list-inclusion(2)
-- may be added to lists
-- which the list provider
-- views as related to the
-- users professional inter-
-- ests, perhaps evaluated
-- from the business of the
-- organisation or keywords
-- in the entry.
}
::= {pilotAttributeType 47}
9.3.38. Building Name ๐ข
the Building Name attribute type names the building where an organisation or organisational unit is based ๐ซ cute and simple, love that for us ๐ธ
buildingName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-building-name))
::= {pilotAttributeType 48}
9.3.39. DSA Quality ๐
the DSA Quality attribute type says what quality a DSA is purported to have ๐ it lets a DSA manager show the expected level of availability of the DSA โจ see [8] for details of the syntax ๐ง
dSAQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
SINGLE VALUE
::= {pilotAttributeType 49}
9.3.40. Single Level Quality ๐ช
the Single Level Quality attribute type is the purported data quality at the level right below it in the DIT ๐ฆ see [8] for details of the syntax ๐
singleLevelQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DataQualitySyntax
SINGLE VALUE
::= {pilotAttributeType 50}
9.3.41. Subtree Minimum Quality ๐ณ
the Subtree Minimum Quality attribute type is the purported minimum data quality for a DIT subtree ๐ฟ see [8] for more discussion and details of the syntax ๐ซถ
subtreeMinimumQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DataQualitySyntax
SINGLE VALUE
-- Defaults to singleLevelQuality
::= {pilotAttributeType 51}
9.3.42. Subtree Maximum Quality ๐ฒ
the Subtree Maximum Quality attribute type is the opposite energy: the purported maximum data quality for a DIT subtree ๐ฅ see [8] for more discussion and details of the syntax ๐
subtreeMaximumQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DataQualitySyntax
SINGLE VALUE
-- Defaults to singleLevelQuality
::= {pilotAttributeType 52}
9.3.43. Personal Signature โ๏ธ
the Personal Signature attribute type lets you represent a person's signature ๐๏ธ this should be encoded in G3 fax as explained in recommendation T.4, with an ASN.1 wrapper so it works with an X.400 BodyPart as defined in X.420 ๐ช very main character, very official ๐
IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
information-objects }
personalSignature ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
(SIZE (1 .. ub-personal-signature))
::= {pilotAttributeType 53}
9.3.44. DIT Redirect ๐ฆ
the DIT Redirect attribute type says "hey, the object from this entry has a newer entry now" ๐ the entry with the redirect should be expired after a suitable grace period โณ this may be used when someone changes their place of work and gets a new organisational DN, which is such a big life moment ๐ฅน
dITRedirect ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 54}
9.3.45. Audio ๐
the Audio attribute type lets you store sounds in the Directory ๐ถ it uses a u-law encoded sound file, the kind the "play" utility on a Sun 4 used ๐ธ this is an interim format, so it's a little bit of a placeholder moment ๐
audio ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
Audio
(SIZE (1 .. ub-audio))
::= {pilotAttributeType 55}
9.3.46. Publisher of Document ๐
the Publisher of Document attribute is the person and/or organization that published a document ๐ง literally the credits, but make it structured ๐
documentPublisher ATTRIBUTE
WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
::= {pilotAttributeType 56}
9.4. Generally useful syntaxes ๐งฉ
caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
IA5String
MATCHES FOR EQUALITY SUBSTRINGS
iA5StringSyntax ATTRIBUTE-SYNTAX
IA5String
MATCHES FOR EQUALITY SUBSTRINGS
-- Syntaxes to support the DNS attributes
DNSRecordSyntax ATTRIBUTE-SYNTAX
IA5String
MATCHES FOR EQUALITY
NRSInformationSyntax ATTRIBUTE-SYNTAX
NRSInformation
MATCHES FOR EQUALITY
NRSInformation ::= SET {
[0] Context,
[1] Address-space-id,
routes [2] SEQUENCE OF SEQUENCE {
Route-cost,
Addressing-info }
}
9.5. Upper bounds on length of attribute values ๐
ub-document-identifier INTEGER ::= 256
ub-document-location INTEGER ::= 256
ub-document-title INTEGER ::= 256
ub-document-version INTEGER ::= 256
ub-favourite-drink INTEGER ::= 256
ub-host INTEGER ::= 256
ub-information INTEGER ::= 2048
ub-unique-identifier INTEGER ::= 256
ub-personal-title INTEGER ::= 256
ub-photo INTEGER ::= 250000
ub-rfc822-mailbox INTEGER ::= 256
ub-room-number INTEGER ::= 256
ub-text-or-address INTEGER ::= 256
ub-user-class INTEGER ::= 256
ub-user-identifier INTEGER ::= 256
ub-organizational-status INTEGER ::= 256
ub-janet-mailbox INTEGER ::= 256
ub-building-name INTEGER ::= 256
ub-personal-signature ::= 50000
ub-audio INTEGER ::= 250000
References โจ
[1] CCITT/ISO, "X.500, The Directory - overview of concepts, models and services, CCITT /ISO IS 9594.
[2] Kille, S., "The THORN and RARE X.500 Naming Architecture, in University College London, Department of Computer Science Research Note 89/48, May 1989.
[3] Kille, S., "X.500 and Domains", RFC 1279, University College London, November 1991.
[4] Rose, M., "PSI/NYSERNet White Pages Pilot Project: Status Report", Technical Report 90-09-10-1, published by NYSERNet Inc, 1990.
[5] Craigie, J., "UK Academic Community Directory Service Pilot Project, pp. 305-310 in Computer Networks and ISDN Systems 17 (1989), published by North Holland.
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987.
[7] Mockapetris, P., "Domain Names - Implementation and Specification, RFC 1035, USC/Information Sciences Institute, November 1987.
[8] Kille, S., "Handling QOS (Quality of service) in the Directory," publication in process, March 1991.
APPENDIX A - Object Class and Attribute Type proformas ๐
Okay so this is where the proformas live, and they're written in BNF. First up, some definitions that both proformas share, bestie ๐ซถ
EOL ::= -- the end of line character(s)
BlankLine ::= -- a line consisting solely of an EOL character
String ::= <anychar> | <String> <anychar>
anychar ::= --any character occurring in general text, excluding
-- the end of line character
lString ::= <lowercase> <otherstring>
lowercase ::= [a-z]
UString ::= <uppercase> <otherstring>
uppercase ::= [A-Z]
otherstring ::= <otherchar> | <otherstring> <otherchar>
otherchar ::= <lowercase> | <uppercase> | <digit>
Integer ::= <digit> | <Integer> <digit>
digit ::= [0-9]
1. Object Class ๐
Here's the object class proforma. Every piece of it is literal, so no vibes-only interpretation allowed ๐
OCProforma ::= <ObjectClassName> <BlankLine> <Description> \
<BlankLine> <OCMacro>
ObjectClassName ::= "ObjectClass:" <String> <EOL>
Description ::= "Description:" <DescriptiveText> <EOL>
DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
OCMacro ::= "ASN1OCMacro:" <ObjectClassMacro>
-- The definition of ObjectClassMacro is adapted from
-- that given in X.501
ObjectClassMacro ::= <OCname> "OBJECT-CLASS" <SubclassOf> \
<MandatoryAttributes> <OptionalAttributes>
OCName ::= <lString>
SubclassOf ::= "SUBCLASS OF" Subclasses | <empty>
Subclasses ::= <Subclass> | <Subclass> "," <Subclasses>
Subclass ::= <OCName>
MandatoryAttributes ::= "MUST CONTAIN {" <Attributes> "}" \
| <empty>
OptionalAttributes ::= "MAY CONTAIN {" <Attributes> "}" | <empty>
Attributes ::= <AttributeTerm> | <AttributeTerm> "," <Attributes>
AttributeTerm ::= <Attribute> | <AttributeSet>
Attribute ::= <lString>
AttributeSet ::= <lString>
2. Attribute Type ๐ฆ
And now the attribute type proforma, which is just as picky about its formatting ๐ธ
ATProforma ::= <AttributeTypeName> <BlankLine> <Description> \
<BlankLine> <OCMust> <Blankline> <OCMay> \
<BlankLine> <ATMacro>
AttributeTypeName ::= "Attribute Type:" <String> <EOL>
Description ::= "Description:" <DescriptiveText> <EOL>
DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
OCMust ::= "OCMust:" <OCList> <EOL>
OCList ::= <OCName> | <OCList> "," <OCName> | <empty>
OCMay ::= "OCMay:" <OCList> <EOL>
ATMacro ::= "ASN1ATMacro:" <AttributeTypeMacro>
-- The definition of AttributeTypeMacro is adapted from that
-- given in X.501
AttributeTypeMacro ::= <ATname> "ATTRIBUTE" <AttributeSyntax> \
<Multivalued> | <empty>
ATName ::= <lString>
AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice
SyntaxChoice ::= <Syntax> <Constraint> | <ASN1Type> <MatchTypes>
Syntax ::= <lString>
Constraint ::= "(" ConstraintAlternative ")" | <empty>
ConstraintAlternative ::= StringConstraint | IntegerConstraint
StringConstraint ::= "SIZE" "(" SizeConstraint ")"
SizeConstraint ::= SingleValue | Range
SingleValue ::= <Integer>
Range ::= <Integer> ".." <Integer>
IntegerConstraint ::= Range
ASN1Type ::= <UString>
-- one of ASN.1's base types: e.g. PrintableString,
-- NumericString, etc.
MatchTypes ::= "MATCHES FOR" Matches | <empty>
Matches ::= Match | Matches Match
Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING"
Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | <empty>
APPENDIX B - Format checking tools ๐
Ooh, the format checkers! These are the source for tools that check both proformas. They're written as Bourne shell scripts for UNIX systems, so think zsh-adjacent vibes but older and cooler ๐
1. Object class format checker ๐
sed 's/ *: */:/' |
awk '
BEGIN {
state = "initial"
}
/^$/ {
next
}
/^Object Class:/ {
n = index($0, ":")
if (state != "initial")
{
print "Already got object class " oc
print "Got another object class " substr($0, n+1)
state = "notOK"
exit 1
}
oc = substr($0, n+1)
state = "gotOC"
next
}
/^Description:/ {
n = index($0, ":")
if (state != "gotOC")
{
print "Got Description: " substr($0, n+1)
for (i = 0; i < 2 && getline > 0; i++)
print $0
print "..."
if (state == "initial")
print "Expecting Object Class:"
else
print "Expecting ASN1OCMacro:"
state = "notOK"
exit 1
}
while (getline > 0)
if (length($0) > 0)
continue
else
break
state = "gotDesc"
next
}
/^ASN1OCMacro:/ {
n = index($0, ":")
if (state != "gotDesc")
{
print "Got ASN1Macro: " substr($0, n+1)
for (i = 0; i < 2 && getline > 0; i++)
print $0
print "..."
if (state == "initial")
print "Expecting Object Class:"
else
print "Expecting Description:"
state = "notOK"
exit 1
}
state = "OK"
exit 0
}
{
print "Parsing has got confused on seeing line: " $0
state = "notOK"
exit 1
}
END {
if (state == "OK")
print "Input looks OK"
}
2. Attribute Type format checker ๐
sed 's/ *: */:/' |
awk '
BEGIN {
state = "initial"
}
/^$/ {
next
}
/^Attribute Type:/ {
n = index($0, ":")
if (state != "initial")
{
got = "Attribute Type:"
exit 1
}
state = "gotAT"
next
}
/^Description:/ {
n = index($0, ":")
if (state != "gotAT")
{
got = "Description:"
exit 1
}
while (getline > 0)
if (length($0) > 0)
continue
else
break
state = "gotDesc"
next
}
/^OCMust:/ {
n = index($0, ":")
if (state != "gotDesc")
{
got = "OCMust:"
exit 1
}
state = "gotOCMust"
next
}
/^OCMay:/ {
n = index($0, ":")
if (state != "gotOCMust")
{
got = "OCMay:"
exit 1
}
state = "gotOCMay"
next
}
/^ASN1ATMacro:/ {
n = index($0, ":")
if (state != "gotOCMay")
{
got = "ASN1ATMacro:"
exit 1
}
state = "OK"
exit 0
}
{
print "Parsing has got confused on seeing line: " $0
state = "notOK"
exit 1
}
END {
if (state == "initial")
print "Expecting Attribute Type:"
else if (state == "gotAT")
print "Expecting Description:"
else if (state == "gotDesc")
print "Expecting OCMust:"
else if (state == "gotOCMust")
print "Expecting OCMay:"
else if (state == "gotOCMay")
print "Expecting ASN1ATMacro:"
if (state != "OK")
print "Got " got
else
print "Input looks OK"
}
APPENDIX C - Summary of all Object Classes and Attribute Types ๐
This is the big summary of every object class and attribute type, so let's get into the object identifiers first ๐ง
-- Some Important Object Identifiers
data OBJECT IDENTIFIER ::= {ccitt 9}
pss OBJECT IDENTIFIER ::= {data 2342}
ucl OBJECT IDENTIFIER ::= {pss 19200300}
pilot OBJECT IDENTIFIER ::= {ucl 100}
pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
{pilotAttributeSyntax 5}
-- Standard Object Classes
top OBJECT-CLASS
MUST CONTAIN {
objectClass}
::= {objectClass 0}
alias OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
aliasedObjectName}
::= {objectClass 1}
country OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
countryName}
MAY CONTAIN {
description,
searchGuide}
::= {objectClass 2}
locality OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN {
description,
localityName,
stateOrProvinceName,
searchGuide,
seeAlso,
streetAddress}
::= {objectClass 3}
organization OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
organizationName}
MAY CONTAIN {
organizationalAttributeSet}
::= {objectClass 4}
organizationalUnit OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
organizationalUnitName}
MAY CONTAIN {
organizationalAttributeSet}
::= {objectClass 5}
person OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName,
surname}
MAY CONTAIN {
description,
seeAlso,
telephoneNumber,
userPassword}
::= {objectClass 6}
organizationalPerson OBJECT-CLASS
SUBCLASS OF person
MAY CONTAIN {
localeAttributeSet,
organizationalUnitName,
postalAttributeSet,
telecommunicationAttributeSet,
title}
::= {objectClass 7}
Okay bestie, we're still in the object class and attribute type lineup, and it's giving a whole buffet of schema ๐
organizationalRole OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
description,
localeAttributeSet,
organizationalUnitName,
postalAttributeSet,
preferredDeliveryMethod,
roleOccupant,
seeAlso,
telecommunicationAttributeSet}
::= {objectClass 8}
groupOfNames OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName,
member}
MAY CONTAIN {
description,
organizationName,
organizationalUnitName,
owner,
seeAlso,
businessCategory}
::= {objectClass 9}
residentialPerson OBJECT-CLASS
SUBCLASS OF person
MUST CONTAIN {
localityName}
MAY CONTAIN {
localeAttributeSet,
postalAttributeSet,
preferredDeliveryMethod,
telecommunicationAttributeSet,
businessCategory}
::= {objectClass 10}
applicationProcess OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
description,
localityName,
organizationalUnitName,
seeAlso}
::= {objectClass 11}
applicationEntity OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName,
presentationAddress}
MAY CONTAIN {
description,
localityName,
organizationName,
organizationalUnitName,
seeAlso,
supportedApplicationContext}
::= {objectClass 12}
dSA OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN {
knowledgeInformation}
::= {objectClass 13}
device OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
description,
localityName,
organizationName,
organizationalUnitName,
owner,
seeAlso,
serialNumber}
::= {objectClass 14}
strongAuthenticationUser OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
userCertificate}
::= {objectClass 15}
certificationAuthority OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
cACertificate,
certificateRevocationList,
authorityRevocationList}
MAY CONTAIN {
crossCertificatePair}
::= {objectClass 16}
-- Standard MHS Object Classes
mhsDistributionList OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName,
mhsDLSubmitPermissions,
mhsORAddresses}
MAY CONTAIN {
description,
organizationName,
organizationalUnitName,
owner,
seeAlso,
mhsDeliverableContentTypes,
mhsdeliverableEits,
mhsDLMembers,
mhsPreferredDeliveryMethods}
::= {mhsObjectClass 0}
mhsMessageStore OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN {
description,
owner,
mhsSupportedOptionalAttributes,
mhsSupportedAutomaticActions,
mhsSupportedContentTypes}
::= {mhsObjectClass 1}
mhsMessageTransferAgent OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN {
description,
owner,
mhsDeliverableContentLength}
::= {mhsObjectClass 2}
mhsOrganizationalUser OBJECT-CLASS
SUBCLASS OF organizationalPerson
MUST CONTAIN {
mhsORAddresses}
MAY CONTAIN {
mhsDeliverableContentLength,
mhsDeliverableContentTypes,
mhsDeliverableEits,
mhsMessageStoreName,
mhsPreferredDeliveryMethods }
::= {mhsObjectClass 3}
mhsResidentialUser OBJECT-CLASS
SUBCLASS OF residentialPerson
MUST CONTAIN {
mhsORAddresses}
MAY CONTAIN {
mhsDeliverableContentLength,
mhsDeliverableContentTypes,
mhsDeliverableEits,
mhsMessageStoreName,
mhsPreferredDeliveryMethods }
::= {mhsObjectClass 4}
mhsUserAgent OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN {
mhsDeliverableContentLength,
mhsDeliverableContentTypes,
mhsDeliverableEits,
mhsORAddresses,
owner}
::= {mhsObjectClass 5}
-- Pilot Object Classes
pilotObject OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN {
info,
photo,
manager,
uniqueIdentifier,
lastModifiedTime,
lastModifiedBy,
dITRedirect,
audio}
::= {pilotObjectClass 3}
pilotPerson OBJECT-CLASS
SUBCLASS OF person
MAY CONTAIN {
userid,
textEncodedORAddress,
rfc822Mailbox,
favouriteDrink,
roomNumber,
userClass,
homeTelephoneNumber,
homePostalAddress,
secretary,
personalTitle,
preferredDeliveryMethod,
businessCategory,
janetMailbox,
otherMailbox,
mobileTelephoneNumber,
pagerTelephoneNumber,
organizationalStatus,
mailPreferenceOption,
personalSignature}
::= {pilotObjectClass 4}
account OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
userid}
MAY CONTAIN {
description,
seeAlso,
localityName,
organizationName,
organizationalUnitName,
host}
::= {pilotObjectClass 5}
document OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
documentIdentifier}
MAY CONTAIN {
commonName,
description,
seeAlso,
localityName,
organizationName,
organizationalUnitName,
documentTitle,
documentVersion,
documentAuthor,
documentLocation,
documentPublisher}
::= {pilotObjectClass 6}
room OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
roomNumber,
description,
seeAlso,
telephoneNumber}
::= {pilotObjectClass 7}
documentSeries OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName}
MAY CONTAIN {
description,
seeAlso,
telephoneNumber,
localityName,
organizationName,
organizationalUnitName}
::= {pilotObjectClass 9}
domain OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
domainComponent}
MAY CONTAIN {
associatedName,
organizationName,
organizationalAttributeSet}
::= {pilotObjectClass 13}
rFC822localPart OBJECT-CLASS
SUBCLASS OF domain
MAY CONTAIN {
commonName,
surname,
description,
seeAlso,
telephoneNumber,
postalAttributeSet,
telecommunicationAttributeSet}
::= {pilotObjectClass 14}
dNSDomain OBJECT-CLASS
SUBCLASS OF domain
MAY CONTAIN {
ARecord,
MDRecord,
MXRecord,
NSRecord,
SOARecord,
CNAMERecord}
::= {pilotObjectClass 15}
domainRelatedObject OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
associatedDomain}
::= {pilotObjectClass 17}
friendlyCountry OBJECT-CLASS
SUBCLASS OF country
MUST CONTAIN {
friendlyCountryName}
::= {pilotObjectClass 18}
simpleSecurityObject OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
userPassword }
::= {pilotObjectClass 19}
pilotOrganization OBJECT-CLASS
SUBCLASS OF organization, organizationalUnit
MAY CONTAIN {
buildingName}
::= {pilotObjectClass 20}
pilotDSA OBJECT-CLASS
SUBCLASS OF dsa
MUST CONTAIN {
dSAQuality}
::= {pilotObjectClass 21}
qualityLabelledData OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
dSAQuality}
MAY CONTAIN {
subtreeMinimumQuality,
subtreeMaximumQuality}
::= {pilotObjectClass 22}
-- Standard Attribute Types
objectClass ObjectClass
::= {attributeType 0}
aliasedObjectName AliasedObjectName
::= {attributeType 1}
knowledgeInformation ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreString
::= {attributeType 2}
commonName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-common-name))
::= {attributeType 3}
surname ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-surname))
::= {attributeType 4}
serialNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX printableStringSyntax
(SIZE (1..ub-serial-number))
::= {attributeType 5}
countryName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PrintableString
(SIZE (1..ub-country-code))
SINGLE VALUE
::= {attributeType 6}
localityName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-locality-name))
::= {attributeType 7}
stateOrProvinceName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-state-name))
::= {attributeType 8}
streetAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-street-address))
::= {attributeType 9}
organizationName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-organization-name))
::= {attributeType 10}
organizationalUnitName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-organizational-unit-name))
::= {attributeType 11}
title ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-title))
::= {attributeType 12}
description ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-description))
::= {attributeType 13}
searchGuide ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Guide
::= {attributeType 14}
businessCategory ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-business-category))
::= {attributeType 15}
postalAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PostalAddress
MATCHES FOR EQUALITY
::= {attributeType 16}
postalCode ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-postal-code))
::= {attributeType 17}
postOfficeBox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-post-office-box))
::= {attributeType 18}
Heads up, this chunk is all schema and no prose, so the code is copied exactly, spacing and all ๐ซถ
okay the attribute list keeps going and it's giving โจ here's the next batch, exactly as written ๐
physicalDeliveryOfficeName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-physical-office-name))
::= {attributeType 19}
telephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax
(SIZE (1..ub-telephone-number))
::= {attributeType 20}
telexNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX TelexNumber
(SIZE (1..ub-telex))
::= {attributeType 21}
teletexTerminalIdentifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier
(SIZE (1..ub-teletex-terminal-id))
::= {attributeType 22}
facsimileTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber
::= {attributeType 23}
x121Address ATTRIBUTE
WITH ATTRIBUTE-SYNTAX NumericString
(SIZE (1..ub-x121-address))
::= {attributeType 24}
internationaliSDNNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX NumericString
(SIZE (1..ub-isdn-address))
::= {attributeType 25}
registeredAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PostalAddress
::= {attributeType 26}
destinationIndicator ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PrintableString
(SIZE (1..ub-destination-indicator))
MATCHES FOR EQUALITY SUBSTRINGS
::= {attributeType 27}
preferredDeliveryMethod ATTRIBUTE
WITH ATTRIBUTE-SYNTAX deliveryMethod
::= {attributeType 28}
presentationAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PresentationAddress
MATCHES FOR EQUALITY
::= {attributeType 29}
supportedApplicationContext ATTRIBUTE
WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
::= {attributeType 30}
member ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
::= {attributeType 31}
owner ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
::= {attributeType 32}
roleOccupant ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
::= {attributeType 33}
seeAlso ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
::= {attributeType 34}
userPassword ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Userpassword
::= {attributeType 35}
userCertificate ATTRIBUTE
WITH ATTRIBUTE-SYNTAX UserCertificate
::= {attributeType 36}
cACertificate ATTRIBUTE
WITH ATTRIBUTE-SYNTAX cACertificate
::= {attributeType 37}
authorityRevocationList ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AuthorityRevocationList
::= {attributeType 38}
certificateRevocationList ATTRIBUTE
WITH ATTRIBUTE-SYNTAX CertificateRevocationList
::= {attributeType 39}
crossCertificatePair ATTRIBUTE
WITH ATTRIBUTE-SYNTAX CrossCertificatePair
::= {attributeType 40}
-- Standard MHS Attribute Types
mhsDeliverableContentLength ATTRIBUTE
WITH ATTRIBUTE-SYNTAX integer
::= {mhsAttributeType 0}
mhsDeliverableContentTypes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oID
::= {mhsAttributeType 1}
mhsDeliverableEits ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oID
::= {mhsAttributeType 2}
mhsDLMembers ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oRName
::= {mhsAttributeType 3}
mhsDLSubmitPermissions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX dLSubmitPermission
::= {mhsAttributeType 4}
mhsMessageStoreName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX dN
::= {mhsAttributeType 5}
mhsORAddresses ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oRAddress
::= {mhsAttributeType 6}
mhsPreferredDeliveryMethods ATTRIBUTE
WITH ATTRIBUTE-SYNTAX deliveryMethod
::= {mhsAttributeType 7}
mhsSupportedAutomaticActions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oID
::= {mhsAttributeType 8}
mhsSupportedContentTypes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oID
::= {mhsAttributeType 9}
mhsSupportedOptionalAttributes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX oID
::= {mhsAttributeType 10}
-- Pilot Attribute Types
userid ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-user-identifier))
::= {pilotAttributeType 1}
textEncodedORAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-text-encoded-or-address))
::= {pilotAttributeType 2}
rfc822Mailbox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
(SIZE (1 .. ub-rfc822-mailbox))
::= {pilotAttributeType 3}
info ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-information))
::= {pilotAttributeType 4}
favouriteDrink ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-favourite-drink))
::= {pilotAttributeType 5}
roomNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-room-number))
::= {pilotAttributeType 6}
photo ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
(SIZE (1 .. ub-photo))
::= {pilotAttributeType 7}
userClass ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-user-class))
::= {pilotAttributeType 8}
host ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-host))
::= {pilotAttributeType 9}
manager ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 10}
documentIdentifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-identifier))
::= {pilotAttributeType 11}
documentTitle ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-title))
::= {pilotAttributeType 12}
documentVersion ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-version))
::= {pilotAttributeType 13}
documentAuthor ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 14}
documentLocation ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-document-location))
::= {pilotAttributeType 15}
homeTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
telephoneNumberSyntax
::= {pilotAttributeType 20}
secretary ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 21}
otherMailbox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
SEQUENCE {
mailboxType PrintableString, -- e.g. Telemail
mailbox IA5String -- e.g. X378:Joe
}
::= {pilotAttributeType 22}
lastModifiedTime ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
uTCTimeSyntax
::= {pilotAttributeType 23}
lastModifiedBy ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 24}
domainComponent ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
SINGLE VALUE
::= {pilotAttributeType 25}
aRecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 26}
mXRecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 28}
nSRecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 29}
sOARecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
DNSRecordSyntax
::= {pilotAttributeType 30}
cNAMERecord ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
iA5StringSyntax
::= {pilotAttributeType 31}
associatedDomain ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
::= {pilotAttributeType 37}
associatedName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 38}
homePostalAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
postalAddress
MATCHES FOR EQUALITY
::= {pilotAttributeType 39}
personalTitle ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-personal-title))
::= {pilotAttributeType 40}
mobileTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
telephoneNumberSyntax
::= {pilotAttributeType 41}
pagerTelephoneNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
telephoneNumberSyntax
::= {pilotAttributeType 42}
friendlyCountryName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
::= {pilotAttributeType 43}
uniqueIdentifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-unique-identifier))
::= {pilotAttributeType 44}
organizationalStatus ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-organizational-status))
::= {pilotAttributeType 45}
janetMailbox ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
(SIZE (1 .. ub-janet-mailbox))
::= {pilotAttributeType 46}
mailPreferenceOption ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ENUMERATED {
no-list-inclusion(0),
any-list-inclusion(1), -- may be added to any lists
professional-list-inclusion(2)
-- may be added to lists
-- which the list provider
-- views as related to the
-- users professional inter-
-- ests, perhaps evaluated
-- from the business of the
-- organisation or keywords
-- in the entry.
}
::= {pilotAttributeType 47}
buildingName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
(SIZE (1 .. ub-building-name))
::= {pilotAttributeType 48}
dSAQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
SINGLE VALUE
::= {pilotAttributeType 49}
singleLevelQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DataQualitySyntax
SINGLE VALUE
subtreeMinimumQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DataQualitySyntax
SINGLE VALUE
-- Defaults to singleLevelQuality
::= {pilotAttributeType 51}
subtreeMaximumQuality ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DataQualitySyntax
SINGLE VALUE
-- Defaults to singleLevelQuality
::= {pilotAttributeType 52}
personalSignature ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
(SIZE (1 .. ub-personal-signature))
::= {pilotAttributeType 53}
dITRedirect ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
distinguishedNameSyntax
::= {pilotAttributeType 54}
Security Considerations โจ
okay bestie, the big security question has a very short answer: security issues are not discussed in this memo ๐ no threat models, no mitigations, nothing. so if you're building on top of this, you'll need to think about security somewhere else ๐ซถ๐
10. Authors' Addresses ๐
meet the two brains behind this one ๐ง โจ both of them were at University College London, so here are their contact details, exactly as written:
Paul Barker
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
England
Phone: +44 71-380-7366
EMail: P.Barker@cs.ucl.ac.uk
Steve Kille
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
England
Phone: +44 71-380-7294
EMail: S.Kille@cs.ucl.ac.uk
and if you want to talk about it with other people, the discussion group is osi-ds@cs.ucl.ac.uk ๐ the end, periodt ๐๐
๐ฆ where this page comes from
- ietf: rfc1274 1991-11
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms