From: Stuart Lynne Date: Wed, 28 Oct 1998 02:02:11 +0000 (+0000) Subject: 1. adding LDAP relevant RFC's X-Git-Tag: OPENLDAP_SLAPD_BACK_LDAP~1237 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=6252c1871a6d6d8045ea0aea5fc1f66ecb23142d;p=openldap 1. adding LDAP relevant RFC's --- diff --git a/doc/rfc/rfc1274.txt b/doc/rfc/rfc1274.txt new file mode 100644 index 0000000000..3ae2709258 --- /dev/null +++ b/doc/rfc/rfc1274.txt @@ -0,0 +1,3363 @@ + + + + + + +Network Working Group P. Barker +Request for Comments: 1274 S. Kille + University College London + November 1991 + + + The COSINE and Internet X.500 Schema + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + This document suggests an X.500 Directory Schema, or Naming + Architecture, for use in the COSINE and Internet X.500 pilots. The + schema is independent of any specific implementation. As well as + indicating support for the standard object classes and attributes, a + large number of generally useful object classes and attributes are + also defined. An appendix to this document includes a machine + processable version of the schema. + + This document also proposes a mechanism for allowing the schema to + evolve in line with emerging requirements. Proformas to support this + process are included. + + Corrections and additions to the schema should be sent to na- + update@cs.ucl.ac.uk list, as described within. + +1. Introduction + + Directory Services are a fundamental requirement of both human and + computer communications' systems. Human users need to be able to + look up various details about other people: for example, telephone + numbers, facsimile numbers and paper mail addresses. Computing + systems also need Directory Services for several purposes: for + example, to support address look-ups for a variety of services, and + to support 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]. The standard + provides a good basis for the provision of real services, and a + considerable amount of Directory Service piloting activity is + + + +Barker & Kille [Page 1] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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. + +2. Motivation and aims of this document + + In a number of areas the X.500 standard only provides a basis for + services. One such area 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. These are intended + to be generally useful across a range of directory applications. + However, while these standard definitions are a useful starting + point, they are insufficient as a basis for a large scale pilot + directory. + + While it is possible for directory administrators to define their own + sets of additional attribute types and object classes, this is + undesirable for some common attributes and objects. The same objects + and attribute types would be privately defined many times over. This + would result in the directory's generality being diminished as remote + systems would be unable to determine 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]. + These have been heavily used in early X.500 piloting activities. + Furthermore, both the THORN and Quipu X.500 implementations have made + use of these definitions. + + Since the afore-mentioned note was issued, a number of further + requirements have come to light as the volume and variety of piloting + activity has increased. Yet further requirements seem likely as the + scale of X.500 pilot services increases. Thus, it is argued that it + is not sufficient to merely reissue an updated version of the + original note. 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 attempts to establish procedures to allow for the + + + +Barker & Kille [Page 2] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + continual updating of the schema. Two proformas are set out for this + purpose. In addition, descriptive detail is provided for the + additional object classes and attribute types defined in the schema. + These descriptions follow the style used in X.520 and X.521. + Finally, also following the style adopted in the standards documents, + appendices will include the entire schema. Plain text versions of + the document's appendices are intended to be machine processable to + allow derivation of a system's schema tables. 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 in other words, + the tendency will be for the inclusion, as opposed to the + exclusion, of useful additions to the schema. + + - 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 is 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 which claims + conformance to this specification: + + 1. 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.) + + 2. A DUA shall be able to identify each attribute type and + object class to the user, with an appropriate representation + (e.g., a string). + + 3. 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: + + + +Barker & Kille [Page 3] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 1. For a DSA to match correctly on the basis of all attribute + syntaxes defined + + 2. For a DSA to enforce the Object Class schema implied by + these definitions + + 3. For a DUA to correctly display the attribute values + (syntaxes) defined + + 4. 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, and examples given 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 is anticipated that the schema will evolve + considerably over time. As X.500 is used to support 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. This stipulation will greatly simplify + subsequent revisions of the schema. + + There is one qualification to the above with respect to requests for + modifications to an existing object class. If a modification to an + object class 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, will not 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 is anticipated that most requests for modifications to the schema + will be met without any need for editorial intervention. Sometimes, + however, 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. In + cases such as this where 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. Heed will be paid to any consensus that emerges + + + +Barker & Kille [Page 4] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 facilitate the production of the afore-mentioned proformas, tools + are included in Appendix B which will verify that 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. This will be at most three or four words. + + The Description field should contain some explanatory text about the + intended use of the object class. This 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 above example shows the main + features. There are many more examples which can studied in the + section defining the Pilot Object Classes. + +4.2. Attribute type proforma + + This section gives an example completed proforma for a new attribute + type, hue (one of the attribute types in the alcoholic drink object + + + +Barker & Kille [Page 5] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + class). + + 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 + + An attribute type description consists of five fields, separated by + blank lines. The keywords Attribute Type, Description, OCMust, OCMay + and ASN1ATMacro, and their suffixed colons, must be included exactly + as above. + + The Attribute Type field should be used for a textual description of + the attribute type. This will be at most three or four words. + + The Description field should contain some explanatory text about the + intended use of the attribute type. This can run to a number of + lines. + + The OCMust field should contain a comma-separated list of object + classes for which this attribute is mandatory. + + The OCMay field should contain a comma-separated list of object + classes for which this attribute is optional. + + The ASN1ATMacro field should follow the definition of the attribute + macro as specified in X.501. The above example shows some of the + features. In particular, please note the format for specifying size + constraints. + +5. Integrating groups of object classes and attribute types. + + This section describes two mechanisms that may be employed to allow + the integration of a substantial number of new object classes and + attribute types into the schema. + + + + +Barker & Kille [Page 6] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + The first mechanism allows for the transition of groups of related, + privately defined object classes and attribute types into the schema. + An example of when such a transition might be appropriate is when + some experimental use of the Directory is widely adopted within the + pilot. Such a transition will be made 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. + + A second mechanism allows for the allocation of an object subtree for + a group of new definitions. A pilotGroups object identifier has been + defined for this purpose. This method will be suitable for an + experiment requiring a considerable number of new object identifiers + to be defined. This approach allows for flexibility during + experimentation and should simplify both the management and the + coherence of the pilot's object identifiers. + + In both cases, the object classes, attribute types and syntaxes + should be defined and described in an RFC. It is suggested that such + documents should follow the style used in this document for object + class and attribute type definitions. A reference will be given in + this schema to the document containing the definitions. + +6. Removing "old" object classes and attribute types. + + It is also important that object classes and attribute types which + are no longer used or useful are removed from the schema. Some + object classes and attribute types initially defined as pilot + extensions may be included as standard definitions in future versions + of the standard. In such a case, it is important that there should + be a fairly rapid transition to the standard definitions. Another + possibility is that newer, more specific definitions obviate the + original definitions. + + Two things are essential. First, it is crucial that "old" + definitions are retired as gracefully as possible. The intention to + retire a definition will be sent to the osi-ds@cs.ucl.ac.uk mail + list. In the absence of objections, the definition will be marked + for expiry with a given expiry date. The definition will remain in + the schema until the expiry date. Users of the schema should ensure + that they make the transition to new, alternative definitions in the + interim. + + + + +Barker & Kille [Page 7] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + Second, users of the schema must have the right to argue for the + retention of definitions which they regard as necessary, there being + no other definitions which closely meet their requirements. It is + clearly impossible to lay down hard and fast rules on this point, as + no two instances will ever be quite the same. It is intended that + the refereeing on these matters will be sympathetic! As for requests + for additions, an aggrieved user can "go to arbitration" by + initiating a discussion on the osi-ds@cs.ucl.ac.uk mail list. + +7. Object Identifiers + + Some additional object identifiers are defined for this schema. + These are also reproduced in Appendix C. + + 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. 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. Refer to + X.402 for descriptions of the usage of these object classes. The + ASN.1 for these object classes is reproduced for completeness in + Appendix C. + +8.3. COSINE/Internet object classes + + This section attempts to fuse together the object classes designed + for use in the COSINE and Internet pilot activities. Descriptions + + + +Barker & Kille [Page 8] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + are given of the suggested usage of these object classes. The ASN.1 + for these object classes is also reproduced in Appendix C. + +8.3.1. Pilot Object + + The PilotObject object class is used as a sub-class to allow some + common, useful attributes to be assigned to entries of all 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, to + allow the use of a number of additional attributes to be assigned to + entries of object class person. + + 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, + + + +Barker & Kille [Page 9] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + mailPreferenceOption, + personalSignature} + ::= {pilotObjectClass 4} + +8.3.3. Account + + The Account object class is used to define entries representing + 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 which 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} + + + + + + +Barker & Kille [Page 10] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +8.3.5. Room + + The Room object class is used to define entries representing rooms. + The commonName attribute should be used for naming pentries 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 which + represents a series of documents (e.g., 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 which 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 { + + + +Barker & Kille [Page 11] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + associatedName, + organizationName, + organizationalAttributeSet} + ::= {pilotObjectClass 13} + +8.3.8. RFC822 Local Part + + The RFC822 Local Part object class is used to define entries which + represent the local part of RFC822 mail addresses. This 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 + + The Domain Related Object object class is used to define entries + which represent DNS/NRS domains which are "equivalent" to an X.500 + domain: e.g., an organisation or organisational unit. The usage of + this object class is described in more detail in [3]. + + + + +Barker & Kille [Page 12] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + domainRelatedObject OBJECT-CLASS + SUBCLASS OF top + MUST CONTAIN { + associatedDomain} + ::= {pilotObjectClass 17} + +8.3.11. Friendly Country + + The Friendly Country object class is used to define country entries + in the DIT. The object class is used to allow friendlier naming of + countries than that allowed by the object class country. The naming + attribute of object class country, countryName, has to be a 2 letter + string defined in ISO 3166. + + friendlyCountry OBJECT-CLASS + SUBCLASS OF country + MUST CONTAIN { + friendlyCountryName} + ::= {pilotObjectClass 18} + +8.3.12. Simple Security Object + + The Simple Security Object object class is used to allow an entry to + have a userPassword attribute when an entry's principal object + classes do not allow userPassword as an attribute type. + + simpleSecurityObject OBJECT-CLASS + SUBCLASS OF top + MUST CONTAIN { + userPassword } + ::= {pilotObjectClass 19} + +8.3.13. Pilot Organization + + The PilotOrganization object class is used as a sub-class of + organization and organizationalUnit to allow a number of additional + attributes to be assigned to entries of object classes organization + and organizationalUnit. + + pilotOrganization OBJECT-CLASS + SUBCLASS OF organization, organizationalUnit + MAY CONTAIN { + buildingName} + ::= {pilotObjectClass 20} + + + + + + + +Barker & Kille [Page 13] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +8.3.14. Pilot DSA + + The PilotDSA object class is used as a sub-class of the dsa object + class to allow additional attributes to be assigned to entries for + DSAs. + + pilotDSA OBJECT-CLASS + SUBCLASS OF dsa + MUST CONTAIN { + dSAQuality} + ::= {pilotObjectClass 21} + +8.3.15. Quality Labelled Data + + The Quality Labelled Data object class is used to allow the + assignment of the data quality attributes to subtrees in the DIT. + + See [8] for more details. + + 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 number of generally useful attribute types are defined in X.520, + and these are supported. Refer to that document for descriptions of + the suggested usage of these attribute types. The ASN.1 for these + attribute types is reproduced for completeness in Appendix C. + +9.2. X.400 standard attribute types + + The standard X.400 attribute types are supported. See X.402 for full + details. The ASN.1 for these attribute types is reproduced in + Appendix C. + +9.3. COSINE/Internet attribute types + + This section describes all the attribute types defined for use in the + COSINE and Internet pilots. Descriptions are given as to the + suggested usage of these attribute types. The ASN.1 for these + + + +Barker & Kille [Page 14] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + attribute types is reproduced in Appendix C. + +9.3.1. Userid + + The Userid attribute type specifies a computer system login name. + + userid ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-user-identifier)) + ::= {pilotAttributeType 1} + +9.3.2. Text Encoded O/R Address + + The Text Encoded O/R Address attribute type specifies a text encoding + of an X.400 O/R address, as specified in RFC 987. The use of this + attribute is deprecated as the attribute is intended for interim use + only. 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 + + The RFC822 Mailbox attribute type specifies an electronic mailbox + attribute following the syntax specified in RFC 822. Note that this + attribute should not 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 + + The Information attribute type specifies any general information + pertinent to an object. It is recommended that specific usage of + this attribute type is avoided, and that specific requirements are + met by other (possibly additional) attribute types. + + info ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + + + +Barker & Kille [Page 15] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + caseIgnoreStringSyntax + (SIZE (1 .. ub-information)) + ::= {pilotAttributeType 4} + +9.3.5. Favourite Drink + + The Favourite Drink attribute type specifies the favourite drink of + an object (or person). + + favouriteDrink ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-favourite-drink)) + ::= {pilotAttributeType 5} + +9.3.6. Room Number + + The Room Number attribute type specifies the room number of an + object. Note that 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 + + The Photo attribute type specifies a "photograph" for an object. + This should be encoded in G3 fax as explained in recommendation T.4, + with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as + defined in X.420. + + 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} + + + + + + + +Barker & Kille [Page 16] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +9.3.8. User Class + + The User Class attribute type specifies a category of computer user. + The semantics placed on this attribute are for local interpretation. + Examples of current usage od this attribute in academia are + undergraduate student, researcher, lecturer, etc. Note that the + organizationalStatus attribute may now often be preferred as it makes + no distinction between computer users and others. + + userClass ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-user-class)) + ::= {pilotAttributeType 8} + +9.3.9. Host + + The Host attribute type specifies a host computer. + + host ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-host)) + ::= {pilotAttributeType 9} + +9.3.10. Manager + + The Manager attribute type specifies the manager of an object + represented by an entry. + + manager ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + distinguishedNameSyntax + ::= {pilotAttributeType 10} + +9.3.11. Document Identifier + + The Document Identifier attribute type specifies a unique identifier + for a document. + + documentIdentifier ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-document-identifier)) + ::= {pilotAttributeType 11} + + + + + + +Barker & Kille [Page 17] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +9.3.12. Document Title + + The Document Title attribute type specifies the title of a document. + + documentTitle ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-document-title)) + ::= {pilotAttributeType 12} + +9.3.13. Document Version + + The Document Version attribute type specifies the version number of a + document. + + documentVersion ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-document-version)) + ::= {pilotAttributeType 13} + +9.3.14. Document Author + + The Document Author attribute type specifies the distinguished name + of the author of a document. + + documentAuthor ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + distinguishedNameSyntax + ::= {pilotAttributeType 14} + +9.3.15. Document Location + + The Document Location attribute type specifies the location of the + document original. + + documentLocation ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-document-location)) + ::= {pilotAttributeType 15} + +9.3.16. Home Telephone Number + + The Home Telephone Number attribute type specifies a home telephone + number associated with a person. Attribute values should follow the + agreed format for international telephone numbers: i.e., "+44 71 123 + 4567". + + + +Barker & Kille [Page 18] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + homeTelephoneNumber ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + telephoneNumberSyntax + ::= {pilotAttributeType 20} + +9.3.17. Secretary + + The Secretary attribute type specifies the secretary of a person. + The attribute value for Secretary is a distinguished name. + + secretary ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + distinguishedNameSyntax + ::= {pilotAttributeType 21} + +9.3.18. Other Mailbox + + The Other Mailbox attribute type specifies values for electronic + mailbox types other than X.400 and rfc822. + + 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 + + The Last Modified Time attribute type specifies the last time, in UTC + time, that an entry was modified. Ideally, this attribute should be + maintained by the DSA. + + lastModifiedTime ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + uTCTimeSyntax + ::= {pilotAttributeType 23} + +9.3.20. Last Modified By + + The Last Modified By attribute specifies the distinguished name of + the last user to modify the associated entry. Ideally, this + attribute should be maintained by the DSA. + + lastModifiedBy ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + distinguishedNameSyntax + + + +Barker & Kille [Page 19] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ::= {pilotAttributeType 24} + +9.3.21. Domain Component + + The Domain Component attribute type specifies a DNS/NRS domain. For + example, "uk" or "ac". + + domainComponent ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreIA5StringSyntax + SINGLE VALUE + ::= {pilotAttributeType 25} + + 9.3.22. DNS ARecord + + The A Record attribute type specifies a type A (Address) DNS resource + record [6] [7]. + + aRecord ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + DNSRecordSyntax + ::= {pilotAttributeType 26} + +9.3.23. MX Record + + The MX Record attribute type specifies a type MX (Mail Exchange) DNS + resource record [6] [7]. + + mXRecord ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + DNSRecordSyntax + ::= {pilotAttributeType 28} + +9.3.24. NS Record + + The NS Record attribute type specifies an NS (Name Server) DNS + resource record [6] [7]. + + nSRecord ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + DNSRecordSyntax + ::= {pilotAttributeType 29} + +9.3.25. SOA Record + + The SOA Record attribute type specifies a type SOA (Start of + Authority) DNS resorce record [6] [7]. + + + + +Barker & Kille [Page 20] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + sOARecord ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + DNSRecordSyntax + ::= {pilotAttributeType 30} + +9.3.26. CNAME Record + + The CNAME Record attribute type specifies a type CNAME (Canonical + Name) DNS resource record [6] [7]. + + cNAMERecord ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + iA5StringSyntax + ::= {pilotAttributeType 31} + +9.3.27. Associated Domain + + The Associated Domain attribute type specifies a DNS or NRS domain + which is associated with an object in the DIT. For example, the entry + in the DIT with a distinguished name "C=GB, O=University College + London" would have an associated domain of "UCL.AC.UK. Note that all + domains should be represented in rfc822 order. 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 specifies an entry in the + organisational DIT associated with a DNS/NRS domain. 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 specifies a home postal + address for an object. This should be limited to up to 6 lines of 30 + characters each. + + homePostalAddress ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + + + +Barker & Kille [Page 21] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + postalAddress + MATCHES FOR EQUALITY + ::= {pilotAttributeType 39} + +9.3.30. Personal Title + + The Personal Title attribute type specifies a personal title for a + person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev". + + 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 specifies a mobile + telephone number associated with a person. Attribute values should + follow the agreed format for international telephone numbers: i.e., + "+44 71 123 4567". + + mobileTelephoneNumber ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + telephoneNumberSyntax + ::= {pilotAttributeType 41} + +9.3.32. Pager Telephone Number + + The Pager Telephone Number attribute type specifies a pager telephone + number for an object. Attribute values should follow the agreed + format for international telephone numbers: i.e., "+44 71 123 4567". + + pagerTelephoneNumber ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + telephoneNumberSyntax + ::= {pilotAttributeType 42} + +9.3.33. Friendly Country Name + + The Friendly Country Name attribute type specifies names of countries + in human readable format. The standard attribute country name must + be one of the two-letter codes defined in ISO 3166. + + friendlyCountryName ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + ::= {pilotAttributeType 43} + + + +Barker & Kille [Page 22] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +9.3.34. Unique Identifier + + The Unique Identifier attribute type specifies a "unique identifier" + for an object represented in the Directory. The domain within which + the identifier is unique, and the exact semantics of the identifier, + are for local definition. For a person, this might be an + institution-wide payroll number. 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 specifies a category by + which a person is often referred to in an organisation. Examples of + usage in academia might include undergraduate student, researcher, + lecturer, etc. + + A Directory administrator should probably consider carefully the + distinctions between this and the title and userClass attributes. + + organizationalStatus ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-organizational-status)) + ::= {pilotAttributeType 45} + +9.3.36. Janet Mailbox + + The Janet Mailbox attribute type specifies an electronic mailbox + attribute following the syntax specified in the Grey Book of the + Coloured Book series. This attribute is intended for the convenience + of U.K users unfamiliar with rfc822 and little-endian mail addresses. + Entries using this attribute MUST also include an rfc822Mailbox + attribute. + + janetMailbox ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreIA5StringSyntax + (SIZE (1 .. ub-janet-mailbox)) + ::= {pilotAttributeType 46} + + + + + + +Barker & Kille [Page 23] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +9.3.37. Mail Preference Option + + An attribute to allow users to indicate a preference for inclusion of + their names on mailing lists (electronic or physical). The absence + of such an attribute should be interpreted as if the attribute was + present with value "no-list-inclusion". This attribute should be + interpreted by anyone using the directory to derive mailing lists, + and its value respected. + + 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 specifies the name of the building + where an organisation or organisational unit is based. + + buildingName ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + caseIgnoreStringSyntax + (SIZE (1 .. ub-building-name)) + ::= {pilotAttributeType 48} + +9.3.39. DSA Quality + + The DSA Quality attribute type specifies the purported quality of a + DSA. It allows a DSA manager to indicate 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} + + + + + +Barker & Kille [Page 24] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +9.3.40. Single Level Quality + + The Single Level Quality attribute type specifies the purported data + quality at the level immediately below 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 specifies 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 specifies 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 allows for a representation of + a person's signature. This should be encoded in G3 fax as explained + in recommendation T.4, with an ASN.1 wrapper to make it compatible + with an X.400 BodyPart as defined in X.420. + + IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules + information-objects } + + personalSignature ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + CHOICE { + + + +Barker & Kille [Page 25] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + g3-facsimile [3] G3FacsimileBodyPart + } + (SIZE (1 .. ub-personal-signature)) + ::= {pilotAttributeType 53} + +9.3.44. DIT Redirect + + The DIT Redirect attribute type is used to indicate that the object + described by one entry now has a newer entry in the DIT. The entry + containing the redirection attribute should be expired after a + suitable grace period. This attribute may be used when an individual + changes his/her place of work, and thus acquires a new organisational + DN. + + dITRedirect ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + distinguishedNameSyntax + ::= {pilotAttributeType 54} + +9.3.45. Audio + + The Audio attribute type allows the storing of sounds in the + Directory. The attribute uses a u-law encoded sound file as used by + the "play" utility on a Sun 4. This is an interim format. + + 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. + + documentPublisher ATTRIBUTE + WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax + ::= {pilotAttributeType 56} + +9.4. Generally useful syntaxes + + caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX + IA5String + MATCHES FOR EQUALITY SUBSTRINGS + + + + + +Barker & Kille [Page 26] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 + + + +Barker & Kille [Page 27] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 + + + +Barker & Kille [Page 28] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + Directory," publication in process, March 1991. + +APPENDIX A - Object Class and Attribute Type proformas + + These are specified in BNF. First some useful definitions, common to + both proformas. + + EOL ::= -- the end of line character(s) + + BlankLine ::= -- a line consisting solely of an EOL character + + String ::= | + + anychar ::= --any character occurring in general text, excluding + -- the end of line character + + lString ::= + + lowercase ::= [a-z] + + UString ::= + + uppercase ::= [A-Z] + + otherstring ::= | + + otherchar ::= | | + + Integer ::= | + + digit ::= [0-9] + +1. Object Class + + + OCProforma ::= \ + + + ObjectClassName ::= "ObjectClass:" + + Description ::= "Description:" + + DescriptiveText ::= | + + OCMacro ::= "ASN1OCMacro:" + + -- The definition of ObjectClassMacro is adapted from + -- that given in X.501 + + + +Barker & Kille [Page 29] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ObjectClassMacro ::= "OBJECT-CLASS" \ + + + OCName ::= + + SubclassOf ::= "SUBCLASS OF" Subclasses | + + Subclasses ::= | "," + + Subclass ::= + + MandatoryAttributes ::= "MUST CONTAIN {" "}" \ + | + OptionalAttributes ::= "MAY CONTAIN {" "}" | + + Attributes ::= | "," + + AttributeTerm ::= | + + Attribute ::= + + AttributeSet ::= + +2. Attribute Type + + + ATProforma ::= \ + \ + + + AttributeTypeName ::= "Attribute Type:" + + Description ::= "Description:" + + DescriptiveText ::= | + + OCMust ::= "OCMust:" + + OCList ::= | "," | + + OCMay ::= "OCMay:" + + ATMacro ::= "ASN1ATMacro:" + + -- The definition of AttributeTypeMacro is adapted from that + -- given in X.501 + + AttributeTypeMacro ::= "ATTRIBUTE" \ + + + +Barker & Kille [Page 30] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + | + + ATName ::= + + AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice + + SyntaxChoice ::= | + + Syntax ::= + + Constraint ::= "(" ConstraintAlternative ")" | + + ConstraintAlternative ::= StringConstraint | IntegerConstraint + + StringConstraint ::= "SIZE" "(" SizeConstraint ")" + + SizeConstraint ::= SingleValue | Range + + SingleValue ::= + + Range ::= ".." + + IntegerConstraint ::= Range + + ASN1Type ::= + -- one of ASN.1's base types: e.g. PrintableString, + -- NumericString, etc. + + MatchTypes ::= "MATCHES FOR" Matches | + + Matches ::= Match | Matches Match + + Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING" + + Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | + +APPENDIX B - Format checking tools + + This section includes the source for format checking tools for the + two proformas. The tools are written as Bourne shell scripts for + UNIX systems. + +1. Object class format checker + + + sed 's/ *: */:/' | + awk ' + BEGIN { + + + +Barker & Kille [Page 31] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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") + + + +Barker & Kille [Page 32] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + { + 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 + } + + + +Barker & Kille [Page 33] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 + + + +Barker & Kille [Page 34] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + } + 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 + + -- 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} + + + + + +Barker & Kille [Page 35] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + -- 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} + + + + + + + +Barker & Kille [Page 36] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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} + + + organizationalRole OBJECT-CLASS + SUBCLASS OF top + MUST CONTAIN { + commonName} + MAY CONTAIN { + description, + localeAttributeSet, + organizationalUnitName, + postalAttributeSet, + preferredDeliveryMethod, + roleOccupant, + seeAlso, + telecommunicationAttributeSet} + ::= {objectClass 8} + + + + +Barker & Kille [Page 37] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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, + + + +Barker & Kille [Page 38] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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} + + + + + + +Barker & Kille [Page 39] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + -- 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, + + + +Barker & Kille [Page 40] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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} + + + + + +Barker & Kille [Page 41] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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, + + + +Barker & Kille [Page 42] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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} + + + + + + +Barker & Kille [Page 43] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 + + + +Barker & Kille [Page 44] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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)) + + + +Barker & Kille [Page 45] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ::= {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 + + + +Barker & Kille [Page 46] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + (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} + + + 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)) + + + +Barker & Kille [Page 47] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ::= {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} + + + + +Barker & Kille [Page 48] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 + + + +Barker & Kille [Page 49] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ::= {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} + + + + + + +Barker & Kille [Page 50] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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)) + + + +Barker & Kille [Page 51] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ::= {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} + + + + + + +Barker & Kille [Page 52] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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 + + + +Barker & Kille [Page 53] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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} + + + +Barker & Kille [Page 54] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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} + + + +Barker & Kille [Page 55] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + 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)) + + + +Barker & Kille [Page 56] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + ::= {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} + + + audio ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + Audio + (SIZE (1 .. ub-audio)) + ::= {pilotAttributeType 55} + + + +Barker & Kille [Page 57] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + documentPublisher ATTRIBUTE + WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax + ::= {pilotAttributeType 56} + + + + -- 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 } + } + + + + + + + + + + + + + +Barker & Kille [Page 58] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + + -- 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 + + + + + + + + + +Barker & Kille [Page 59] + +RFC 1274 COSINE and Internet X.500 Schema November 1991 + + +Security Considerations + + Security issues are not discussed in this memo. + +10. Authors' Addresses + + 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 + + Or send comments to the discussion group: . + + + + + + + + + + + + + + + + + + + + + + + +Barker & Kille [Page 60] + \ No newline at end of file diff --git a/doc/rfc/rfc1275.txt b/doc/rfc/rfc1275.txt new file mode 100644 index 0000000000..488b3a0f24 --- /dev/null +++ b/doc/rfc/rfc1275.txt @@ -0,0 +1,202 @@ + + + + + + +Network Working Group S.E. Hardcastle-Kille +Requests for Comments 1275 University College London + November 1991 + + + + + + + + +Replication Requirements to provide an Internet Directory using X.500 + + + + + + + + + + +Status of this Memo + This memo provides information for the Internet community. It + does not specify an Internet standard. Distribution of this memo + is unlimited. +Abstract + + This RFCconsiders certain deficiencies of the 1988 X.500 + standard, which need to be addressed before an effective open + Internet Directory can be established using these protocols and + services [CCI88]. The only areas considered are primary + problems, to which solutions must be found before a pilot can be + deployed. This RFCconcerns itself with deficiencies which can + only be addressed by use of additional protocol or procedures for + distributed operation. + + + + +RFC 1275 Replication Requirements November 1991 + + +1 Distributed Operation Extensions + +The Internet Directory will operate DSAs over TCP/IP using RFC 1006 +[RC87], and DSAs over the an ISO Network Service. Distributed +operation procedures should not require full connectivity. + + +2 Knowledge Replication + +Knowledge information is critical to resolution of names, and +performing searches. Knowledge information high up the tree needs to +be widely available. Consider resolving a name below ``Country=US''. +To do this, a DSA needs to have full knowledge at this point. Many +DSAs need to be able to do this, in order to give reasonable response +and availability. It would be an unacceptable bottleneck to force +such resolution to a single or small number of DSAs. To replicate +this knowledge widely, a systematic approach to replication is needed. + + +3 Data Replication + +Searches are often made at the root and country level, and this is a +vital service (e.g., an approximate match of an organisation name). +Data needs to be collected in such a way that this sort of searching +is reasonably efficient. The usual X.500 approach of subordinate +references militates against this. At a node in the DIT, subordinate +references to the entries below are held. These entries will be in +many DSAs, each of which needs to be accessed in order to perform the +single level search. It is suggested that replication of data is +necessary to achieve this. + +The major requirement for this replication is high up the DIT, where +information must be replicated between different implementations. At +lower levels of the DIT, it is reasonable for DSAs to be of the same +implementation and to use implementation specific techniques in order +to achieve performance and availability. + + +4 Alternate DSAs + +When a DSA Referral is returned, only the master DSA is indicated. +This will lead to a single point of failure. It seems important to +allow for additional references to slave copies, in order to get + + +Hardcastle-Kille Page 1 + + + + +RFC 1275 Replication Requirements November 1991 + + +better availability. This needs to be solved in conjunction with the +problem described in the previous section. + + +5 Guidelines for use of Replication + +To be effective, the replication specification needs to provide +guidelines for deployment in the pilot, in order to meet the desired +service criteria. + + +6 Some scaling targets + +Most techniques for replication have scaling limits. It is important +that mechanisms used do not stress the limits of the mechanism. The +order of magnitude envisioned in the pilot is 100 000 non-leaf entries +and several million leaf entries. + + +References + +[CCI88] The Directory --- overview of concepts, models and services, + December 1988. CCITT X.500 Series Recommendations. + +[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services + on top of the TCP. Request for Comments 1006, Northrop + Corporation Technology Center, May 1987. + + +7 Security Considerations + +Security considerations are not discussed in this memo. + + +8 Author's Address + + Steve Hardcastle-Kille + Department of Computer Science + University College London + Gower Street + WC1E 6BT + England + + + +Hardcastle-Kille Page 2 + + + + +RFC 1275 Replication Requirements November 1991 + + + Phone: +44-71-380-7294 + + EMail: S.Kille@CS.UCL.AC.UK + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardcastle-Kille Page 3 + diff --git a/doc/rfc/rfc1279.txt b/doc/rfc/rfc1279.txt new file mode 100644 index 0000000000..e389bd2ac3 --- /dev/null +++ b/doc/rfc/rfc1279.txt @@ -0,0 +1,839 @@ + + + + + + +Network Working Group S.E. Hardcastle-Kille +Requests for Comments 1279 University College London + November 1991 + + + + + + + + X.500 and Domains + + + + + + + + + +Status of this Memo + This memo defines an Experimental Protocol for the Internet + community. Discussion and suggestions for improvement are + requested. Please refer to the current edition of the ``IAB + Official Protocol Standards'' for the standardization state and + status of this protocol. Distribution of this memo is unlimited. +Abstract + + This RFCconsiders X.500 in relation to Internet and UK Domains. + A basic model of X.500 providing a higher level and more + descriptive naming structure is emphasised. In addition, a + mapping of domains onto X.500 is proposed, which gives a range of + new management and user facilities over and above those currently + available. This specification proposes an experimental new + mechanism to access and manage domain information on the Internet + and in the UK Academic Community. There is no current intention + to provide an operational replacement for DNS. + + + + +RFC 1279 X.500 and Domains November 1991 + + +1 The Domain Name System + +The Domain (Nameserver) System (DNS) provides a hierarchical resource +labelling system [Moc87a] [Moc87b] [Lar83]. Example domains are: + +MIT.EDU +VENERA.ISI.EDU +CS.UCL.AC.UK + + +Entries usually have a single name, although pointers to entries (not +subtrees) may be provided by CNAME records. Information (resource +records) is associated with each entry. Name components are typically +chosen to be shortish (e.g., ``CS''). +RFC 822 mailbox names are closely related [Cro82]. For example: + + + + +The local-part of the RFC 822 mailbox can be considered as one level +lower in the domain hierarchy. + + +2 X.500 + +The OSI Directory, usually known as X.500, provides a very general +naming framework [CCI88]. A basic usage of X.500 is to provide +Organisationally Structured Names. A Schema for this is defined +within the standard. Name components will typically have longish +values. This is an example directory name represented in Tabular +form: + + + Country GB + Organisation University College London + Organisational Unit Computer Science + Common Name Stephen E. Hardcastle-Kille + +This can also be written in the ``User Friendly Name'' notation +defined in [HK91]. This syntax is used for names in the rest of this +document: + + + Stephen E. Hardcastle-Kille, Computer Science, + +Hardcastle-Kille Page 1 + + + + +RFC 1279 X.500 and Domains November 1991 + + + University College London, GB + +This type of structure is termed ``organisational X.500''. This is a +subset of the general capabilities. + + +3 The basic model + + X.500 has as much relation to the DNS as DNS has to ARP. Paul + Mockapetris + + +This is, essentially, the position adopted here. The basic model is +that organisational X.500 is providing a layer of naming at the level +above domain names. These structured names can be considered to form +a naming layer above domain names. There are the following key +differences: + + o Organisational X.500 tends to use longer and more descriptive + values + + o The organisational X.500 DIT is slightly shallower than the DNS + tree + + o X.500 has a richer information framework than DNS + + +These differences suggest that the following should NOT be done: + + o Represent X.500 information in the DNS + + o Have an algorithmic mapping between the two hierarchies + +This note proposes to represent DNS information in the DIT, and to +provide for a loose coupling between the two trees. This note does +not propose an equivalencing of X.500 and Domains. + +The proposed model is illustrated in Figure 1. Both an organisational +and domain structure is represented in the DIT, by use of appropriate +object classes and attribute types. A weak linkage is provided +between the two parts of the tree by use of special attributes. Here, +the linkage is 1:1, but it may be more complex for some parts of the +organisational DIT or domain namespace. The linkage is achieved by +use of special attributes, as described in Section 11. + +Hardcastle-Kille Page 2 + + + + +RFC 1279 X.500 and Domains November 1991 + + + + + + + + + + + j jZ Z + + j j ZZ + jj Z Z + jjj ZZ + +Domain Component=UK Country Name=GB + | + | + | +Domain Component=AC Organisation Name=Univeristy College London + + * BB + ss BBB + +Domain Component=UCL Org Unit Name=Computer Science + | * + + || ss +Domain Component=CS Common Name=Steve Kille + + | * + | ss + +Domain Component=S.Kille + Figure 1: Example X.500 tree + + + + + + + + + + + +Hardcastle-Kille Page 3 + + + + +RFC 1279 X.500 and Domains November 1991 + + +4 Representing Domains in X.500 + +Domains are at the level below X.500 names of the form illustrated in +the previous section. However, it is also possible to use X.500 in +other ways. In particular, there are benefits from representing +Domains in X.500. Note that this is very different to equivalencing, +as no attempt is made to represent X.500 information within the domain +scheme. There are the following potential advantages: + + + o Domain Services (DNS and NRS) could be replaced with an OSI + service (some may not view this as an advantage). This is + particularly attractive for OSI services, where use of a non-OSI + directory may be inappropriate. + + o For Internet sites, access to domain information (beyond MX + records) could be provided for systems registered remotely. For + UK Academic Community sites, access to domain information for + domains not registered in the NRS could be given. For sites + neither on the Internet nor in the UK Academic Community there + will usually be even more of an advantage, as they usually have + very limited information on domains. + + o Assuming that information is downloaded from an X.500 database + into a DNS or NRS system, the remote management facilities of + X.500 could be used. This is possible because of the extra + security features of X.500. + + Note: For initial work, the converse situation of information + being mastered in Domain Databases and uploaded into the X.500 + DIT is more likely. + + o User access to the domain data, and in particular searching, could + be provided. This would allow users to browse the domain + namespace, and to determine information associated with the + domains. + + o The X.500 framework would allow for additional management + information to be stored, and to relate the domain names into a + more complex structure of information. For example, this might + allow for the managers of a system to be identified, and + information on how to contact the manager. + + + +Hardcastle-Kille Page 4 + + + + +RFC 1279 X.500 and Domains November 1991 + + + o A facility to map RFC 822 mailbox into a Directory Name (and thus + access other user information on the basis of this key) could be + provided. This may be useful for the user to determine + information about a message originator. + + o This technique may be useful to facilitate introduction of + security, as it will enable certificates to be associated with + domains and mailboxes. This may be very useful for the privacy + enchanced mail work [Lin89]. + + +5 Representing Domain Names + +A new attribute syntax is defined: + + +CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX + IA5String + MATCHES FOR EQUALITY SUBSTRINGS ORDERING + + +A new attribute and two new object classes are defined: + + +DomainComponent ATTRIBUTE + WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax + SINGLE VALUE + +Domain OBJECT-CLASS + SUBCLASS OF top + MUST CONTAIN -DomainComponent" + MAY CONTAIN -AssociatedName, + organizationName, + organizationalAttributeSet, + manager" + +RFC822Mailbox OBJECT-CLASS + SUBCLASS OF Domain + MAY CONTAIN -commonName, + surname, + description, + telephoneNumber, + postalAttributeSet, + telecommunicationAttributeSet " + +Hardcastle-Kille Page 5 + + + + +RFC 1279 X.500 and Domains November 1991 + + +Note that the attribute AssociatedName is defined in Section 11. The +manager attribute is defined in the COSINE and Internet naming +architecture [BHK91]. It allows a manager to be associated with the +domain, which is useful where the manager of the domain is different +to the manager of the object defined by the AssociatedName. This will +allow any domain to be represented in an X.500 hierarchy. The local +part of an RFC 822 mailbox is treated as a special sort of domain +component, and so these can be represented in the tree as a natural +extension of the hierarchy. +For example, consider the mailbox S.Kille@cs.ucl.ac.uk. This will +lead to the following structure in the DIT: + + ___________________________________________ + |_Object_Class__|RDN_Type________|RDN_Value_| + | Domain |DomainComponent |UK | + | Domain |DomainComponent |AC | + | Domain |DomainComponent |UCL | + | Domain |DomainComponent |CS | + |_RFC822Mailbox_|DomainComponent_|S.Kille__ | + +This can be represented in User Friendly Name format as: + + +DomainComponent=S.Kille, DomainComponent=CS, DomainComponent=UCL, +DomainComponent=AC, DomainComponent=UK + +Note that the RFC822Mailbox Object Class is a subclass of Domain. +Some attributes are allowed to be associated with these objects. +There may be other additional management attributes which it is useful +to define (e.g., Machine Type, Owner, Location etc.). This allows +some information which truly belongs to the domain to be represented +there. It also allows for further information to be associated with +the domain/mailbox when there is not a relevant part of the +organisationally structure DIT to be pointed at. When there is an +associated part of the DIT, information from that part of the DIT +should not be duplicated in the domain entry. + + +6 Wildcards + + +Wildcards are supported by having "*" as a special domain component +name. If there is a need to emulate wildcard matching using the +directory, the following algorithm must be employed. For example, the + +Hardcastle-Kille Page 6 + + + + +RFC 1279 X.500 and Domains November 1991 + + +wildcard entry for *.*.PODUNK.COM would be represented in the DIT as: + + DomainComponent=*, DomainComponent=*, + DomainComponent=MIT, DomainComponent=COM + + +If A.B.PODUNK.COM is looked up in the directory, the query will fail +and indicate that two components are matched. A substitution should +be made, and *.*.PODUNK.COM looked up explicitly to identify the +associated information. + + +7 DNS Information + +DNS information can be associated with an entry in the DIT. It is +important that this is done in a manner which is exactly equivalent to +the information stored in the DNS. This will allow the DIT to have +information loaded from the DNS or vice versa. All (authoritative) +records associated with a domain will be stored in the DIT. There is +no attempt made by the OSI Directory to emulate DNS caching or TTL +handling. It is assumed that the master entries are maintained by use +of DNS Zone Transfer (or equivalent), and that they can be treated as +authoritative. There is a need to define an attribute syntax which +represents a DNS record. This then allows DNS records to be stored in +the DIT. There are three possible encodings of this record: + +ASN.1 Encoded This is the most natural approach in terms of X.500. + However, it would require all users of this service to handle the + new syntax, which would be awkward. There is a problem with + handling the resource format in a general manner. + +DNS Binary Encoded Use the formally defined record syntax. This + would be convenient for access to the data by DNS related + software, but would be an awkward encoding for independent X.500 + DUAs. + +Text encoded Use of a text encoding derived from the DNS + specifications. This is straightforward to map onto DNS protocol, + and easy to support in a naive X.500 DUA. This approach is chosen. + + +The syntax is defined in IA5 characters. The BNF of the record uses +the definitions of section 5.1 of RFC 1035. It is + + +Hardcastle-Kille Page 7 + + + + +RFC 1279 X.500 and Domains November 1991 + + + [ ";" ] + +Three examples of this (for domain C.ISI.EDU) might be: + + +500 A 10.1.0.52 ; Basic address record +IN 600 MX 10 VENERA.ISI.EDU. ; MX record +600 IN MX 10 VENERA.ISI.EDU. ; MX record - other order + +Note that: + + + o The class and TTL may be in either order (following RFC 1035) + + o The class defaults to IN + + o Domains must always be fully specified (i.e., master file + abbreviate rules are not used). + + o The TTL for a record must always be present (this saves looking at + the parent entry to find the SOA record). + + o Records (e.g., SOA) may be multiline. Lines should be separated + with the two IA5 characters . + +CNAME records are mapped symmetrically onto Directory Aliases. + +This is now defined in terms of attribute and object class +definitions. A single record type is defined, as opposed to one +attribute type per record type. This allows the definition to not +require extension when new DNS Record types are define. However, +there is some loss of efficiency if only a single record type is +needed, as filtering must be done by the DUA. +Similarly, no distinction is made on the basis of DNS class. This +means that if there are two class hierarchies, that they must be +represented in a single DIT, and that information for different +classes must be separated by DUA filtering. + + +DNSDomain OBJECT-CLASS + SUBCLASS OF Domain + MAY CONTAIN - + DNSRecord " + + +Hardcastle-Kille Page 8 + + + + +RFC 1279 X.500 and Domains November 1991 + + +DNSRecord ATTRIBUTE + ATTRIBUTE-SYNTAX IA5String + MATCHES FOR EQUALITY + + +Lookup of a domain is achieved by translating it algorithmically to a +Distinguished Name (DN), and reading back attributes desired. This +information can be managed and searched in a straightforward fashion. + +The information may also be downloaded into a DNS database. This +should be done by use of zone transfer. A tool to perform zone +transfer (in both directions) between a DNS Server and a DSA would +seem to be both straightforward and useful. This would be a key tool +in a transition to X.500 based management of the DNS. It would also +allow a large part of the DNS namespace to be rapidly made available +in an X.500 pilot. +Inverse information can be derived by the usual IN-ADDR domain, which +will be represented in the same manner in the DIT. + + +8 NRS Information + +Information associated with the UK NRS (Name Registration Scheme) can +be handled in a similar manner [Lar83]. This is being developed in a +separate document by Alan Turland. + + +9 Application Entity Titles + +In many cases, Application entities will be closely related to +domains. In some cases, it may be appropriate to give Application +Entities names which are related to the DNS part of the DIT. In this +case, the Domain Name will be used to identify the application, and +the entry for the domain will also be of object class Application +Process. The children of this entry will identify Application +Entities, with names such as ``FTAM Service''. + + +10 Networks + + +It is clearly useful to represent networks within the DIT. A short +note on how to do this is given here. It is likely that this +specification will later be evolved in a separate document. This + +Hardcastle-Kille Page 9 + + + + +RFC 1279 X.500 and Domains November 1991 + + +defines an Object Class for a general network, and shows how it can be +subclassed to define technology specific networks. + +Network OBJECT-CLASS + SUBCLASS OF TOP + MAY CONTAIN - + Manager, + Locality, + Description " + +IPNetwork OBJECT-CLASS + SUBCLASS OF Network + MUST CONTAIN -AssociatedDomain" + + +The Network Object Class allows networks to be defined, and for useful +attributes to be associated with the entry. A network will often +appear in more than one organisational structure, and this linkage +should be achieved by use of aliases. This grouping can facilitate +management of networks. +The subclass IPNetwork mandates linkage into the DNS part of the DIT. +This will be represented in the DIT using the structures of RFC 1101 +[Moc89]. Both of the domains which identify the network should be +represented in the Object Class. For example, a network might have +the (user friendly) name: + + UCL-Ethernet, University College London, GB + + +This would have associated domains 0.0.40.128.IN-ADDR.ARPA and +UCL-ETHERNET.UCL.AC.UK. These would both have the analogous DIT +representations. For example: + +DomainComponent=0, DomainComponent=0, DomainComponent=40, +DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=ARPA + + +11 Linkage + + +There is a need to associate the organisational X.500 DIT and the DNS +tree. The objects represented are different (Domain 6= Organisation; +Person 6= RFC 822 Mailbox). Therefore aliasing is not an appropriate +linkage. However, in many cases, there is a linkage which is rather + +Hardcastle-Kille Page 10 + + + + +RFC 1279 X.500 and Domains November 1991 + + +stronger than that implied by the seeAlso attribute. Therefore, we +define new attributes, which represent this stronger cross-linkage. +The same mechanism can be used to link a domains with an Application +Entity or an Application Process. +Links from the organisational X.500 DIT to the DNS tree are provided +by a new attribute, which could be present in Organisation or +Organisational Unit entries. + + +ObjectWithAssociatedDomain OBJECT-CLASS + SUBCLASS OF top + MUST CONTAIN -AssociatedDomain" + +AssociatedDomain ATTRIBUTE + WITH ATTRIBUTE-SYNTAX ia5StringSyntax + +For example, the organisational entry: + + University College London, GB + + +would have an attribute: + + AssociatedDomain = UCL.AC.UK + + +Similarly, an RFC 822 mailbox attribute is used to link entries of +Person Object Class to their associated DNS entry. This attribute is +defined in the Cosine and Internet Naming Architecture [BHK91]. +Conversely, there are pointers from the DNS represented tree into the +organisational X.500 DIT: + + +AssociatedName ATTRIBUTE + WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax + +This attribute is associated with the Domain object class. + +This entry is used to provide linkage from the DNS X.500 Hierarchy +into the organisational X.500 hierarchy. Where such entries do not +exist, attributes in the DNS entry (such as phone number) may be used. +It is recommended that information is not duplicated. The preferred +setup is for the DNS attributes to be rather skeletal, with pointers +into the organisational X.500 DIT. + +Hardcastle-Kille Page 11 + + + + +RFC 1279 X.500 and Domains November 1991 + + +For example, the domain UCL.AC.UK would be represented in the DIT as: + + DomainComponent=UCL, DomainComponent=AC, + DomainComponent=UK + + +This entry would have in it an AssociatedName attribute with value: + + University College London, GB + + +This example shows a simple case with 1:1 linkage. There are cases +where a domain might be associated with multiple organisations, or an +organisation with multiple domains. + + +12 Conclusions and proposals for evaluation + +Experiments should be undertaken to determine the practicality and +utility of this scheme, in a pilot environment. A possible approach +to this experimentation is described in Appendix A. +Object Identifiers have been assigned for this purpose in the Cosine +and Internet Naming Architecture [BHK91]. + + +References + +[BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet + X.500 schema. Request for Comments RFC 1274, Department of + Computer Science, University College London, November 1991. + +[CCI88] The Directory --- overview of concepts, models and services, + December 1988. CCITT X.500 Series Recommendations. + +[Cro82] D.H. Crocker. Standard of the format of ARPA internet text + messages. Request for Comments 822, University of Delaware, + August 1982. + +[HK91] S.E. Hardcastle-Kille. Using the OSI directory to achieve + user friendly naming. Request for Comments in preparation, + Department of Computer Science, University College London, + November 1991. + + + +Hardcastle-Kille Page 12 + + + + +RFC 1279 X.500 and Domains November 1991 + + +[Lar83] J. Larmouth. JNT name registration technical guide, April + 1983. + +[Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail: + Part 1 --- Message Encipherment and Authentication + Procedures. Request for Comments 1113, Bolt, Beranek, and + Newman, August 1989. + +[Moc87a] P. Mockapetris. Domain names - concepts and facilities. + Request for Comments RFC 1034, USC/Information Sciences + Institute, November 1987. + +[Moc87b] P. Mockapetris. Domain names - implementation and + specification. Request for Comments RFC 1035, + USC/Information Sciences Institute, November 1987. + +[Moc89] P. Mockapetris. DNS encoding of network names and other + types. Request for Comments RFC 1101, USC/Information + Sciences Institute, April 1989. + + +13 Security Considerations + +This memo does not directly address security issues. However, due to +the facilities of X.500, this proposal could lead to a more secure way +to access and manage domain information. + + +14 Author's Address + + Steve Hardcastle-Kille + Department of Computer Science + University College London + Gower Street + WC1E 6BT + England + + Phone: +44-71-380-7294 + + + EMail: S.Kille@CS.UCL.AC.UK + + + + +Hardcastle-Kille Page 13 + + + + +RFC 1279 X.500 and Domains November 1991 + + +A Possible Deployment Approach + +This appendix notes a possible approach to deploying an experiment to +evaluate this mechanism. The following components of a possible +experiment are noted. + + +1. User tool. This will take a domain or mailbox as input. This + will be looked up in the DIT. This tool should be capable of: + + o Attempting to correct user input + + o Helping browsing + + o Looking up information associated with the domain (or mailbox) + and associated name, in particular the manager (of both domain + and associated name) and information on the manager (e.g., + phone number and mailbox). + + o Supply DNS records + + o Handle IN-ADDR.ARPA inverse lookups if supplied with an IP + Address + + o Look up networks + +2. A procedural library to allow user interfaces to make easy use of + these facilities. + +3. Zone transfer tool. This will use the zone transfer protocol to + transfer information between a DSA and Domain Nameserver. When + writing to the DSA, attributes in an entry which are not DNS + records should remain untouched. + +4. Linkage patching tool. When the organisational DIT is + established, associated domain pointers are usually inserted. A + tool can be written to search the DIT and insert the reverse + pointers. + +5. DNS Manager Tool. This will allow user addition of additional + information into the DNS part of the DIT. A standard DUA can + probably be used for this. + + + +Hardcastle-Kille Page 14 + + + + +RFC 1279 X.500 and Domains November 1991 + + +6. Mailbox download tool. This will allow download of local + mailboxes, with pointers to the user entries. + +7. Emulation DNS Server, using the Directory as a database. The + server should maintain a permanent connection to its local DSA. As + there is no OSI bind, the response of this server can be at least + as fast as a normal DNS server. There can be two variants of this + server. + + (a) Using a local DSA as a local database but using DNS + distributed operations. + + (b) Do all lookups in the directory (using Directory Distributed + Operations). + +An initial experiment is straightforward. The Zone Transfer Tool (3) +can be used to download a large part of the DNS space into a single +DSA (there will be some restrictions, as parts of the DNS hierarchy do +not permit zone transfer). This can be used repeatedly to maintain +the information. The linkage patching tool (4) can be used to put in +pointers to parts of the DIT. The user tool can then be used (by all +sites participation the the directory pilot) to look up domain +information. This will allow the utility of the approach to be +evaluated. The manager tool (5) will allow extra information to be +added to parts of the DNS tree. + +The next stage will be to distribute the DNS part of the DIT over +multiple DSAs using Directory distribution techniques. +The emulation DNS Server (7) will be useful to ensure that equivalent +functionality is being offered by the Directory. It can also be used +to examine performance differences. +A final step is to master some parts of the DNS hierarchy in the DIT. +Because of the zone transfer technique, this will be entirely +transparent to the DNS user. Management benefits can then be +examined. + + + + + + + + + + +Hardcastle-Kille Page 15 + diff --git a/doc/rfc/rfc1308.txt b/doc/rfc/rfc1308.txt new file mode 100644 index 0000000000..88ac866a47 --- /dev/null +++ b/doc/rfc/rfc1308.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group C. Weider +Request for Comments: 1308 ANS +FYI: 13 J. Reynolds + ISI + March 1992 + + + Executive Introduction to Directory Services + Using the X.500 Protocol + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + This document is an Executive Introduction to Directory Services + using the X.500 protocol. It briefly discusses the deficiencies in + currently deployed Internet Directory Services, and then illustrates + the solutions provided by X.500. + + This FYI RFC is a product of the Directory Information Services + (pilot) Infrastructure Working Group (DISI). A combined effort of + the User Services and the OSI Integration Areas of the Internet + Engineering Task Force (IETF). + +1. INTRODUCTION + + The Internet is growing at a phenomenal rate, with no deceleration in + sight. Every month thousands of new users are added. New networks + are added literally almost every day. In fact, it is entirely + conceivable that in the future every human with access to a computer + will be able to interact with every other over the Internet and her + sister networks. However, the ability to interact with everyone is + only useful if one can locate the people with whom they need to work. + Thus, as the Internet grows, one of the limitations imposed on the + effective use of the network will be determined by the quality and + coverage of Directory Services available. + + Directory Services in this paper refers not only to the types of + services provided by the telephone companies' White Pages, but to + resource location, Yellow Pages services, mail address lookup, etc. + We will take a brief look at the services available today, and at the + problems they have, and then we will show how the X.500 standard + solves those problems. + + + + +DISI Working Group [Page 1] + +RFC 1308 Executive Intro to X.500 March 1992 + + +2. CURRENT SERVICES AND THEIR LIMITATIONS + + In the interests of brevity, we will only look at the WHOIS service, + and at the DNS. Each will illustrate a particular philosophy, if you + will, of Directory Services. + + The WHOIS service is maintained by the Defense Data Network Network + Information Center, or DDN NIC. It is currently maintained at GSI + for the IP portion of the Internet. It contains information about IP + networks, IP network managers, a scattering of well-known personages + in the Internet, and a large amount of information related + specifically to the MILNET systems. As the NIC is responsible for + assigning new networks out of the pool of IP addresses, it is very + easily able to collect this information when a new network is + registered. However, the WHOIS database is big enough and + comprehensive enough to exhibit many of the flaws of a large + centralized database. First, centralized location of the WHOIS + database causes slow response during times of peak querying activity, + storage limitations, and also causes the entire service to be + unavailable if the link to GSI is broken. Second, centralized + administration of the database, where any changes to the database + have to be mailed off to GSI for human transcription into the + database, increases the turnaround time before the changes are + propagated, and also introduces another source of potential error in + the accuracy of the information. These particular problems affect to + different degrees any system which attempts to provide Directory + Services through a centralized database. + + The Domain Name Service, or DNS, contains information about the + mapping of host and domain names, such as, "home.ans.net", to IP + addresses. This is done so that humans can use easily remembered + names for machines rather than strings of numbers. It is maintained + in a distributed fashion, with each DNS server providing nameservice + for a limited number of domains. Also, secondary nameservers can be + identified for each domain, so that one unreachable network will not + necessarily cut off nameservice. However, even though the DNS is + superlative at providing these services, there are some problems when + we attempt to provide other Directory Services in the DNS. First, the + DNS has very limited search capabilities. Second, the DNS supports + only a small number of data types. Adding new data types, such as + photographs, would involve very extensive implementation changes. + +3. THE X.500 SOLUTION + + X.500 is a CCITT protocol which is designed to build a distributed, + global directory. It offers the following features: + + * Decentralized Maintenance: + + + +DISI Working Group [Page 2] + +RFC 1308 Executive Intro to X.500 March 1992 + + + Each site running X.500 is responsible ONLY for its local part of + the Directory, so updates and maintenance can be done instantly. + + * Powerful Searching Capabilities: + X.500 provides powerful searching facilities that allow users to + construct arbitrarily complex queries. + + * Single Global Namespace: + Much like the DNS, X.500 provides a single homogeneous namespace + to users. The X.500 namespace is more flexible and expandable + than the DNS. + + * Structured Information Framework: + X.500 defines the information framework used in the Directory, + allowing local extensions. + + * Standards-Based Directory Services: + As X.500 can be used to build a standards-based directory, + applications which require directory information (e-mail, + automated resources locators, special-purpose directory tools) + can access a planet's worth of information in a uniform manner, + no matter where they are based or currently running. + + With these features alone, X.500 is being used today to provide the + backbone of a global White Pages service. There is almost 3 years of + operational experience with X.500, and it is being used widely in + Europe and Australia in addition to North America. In addition, the + various X.500 implementations add some other features, such as + photographs in G3-FAX format, and color photos in JPEG format. + However, as X.500 is standards based, there are very few + incompatibilities between the various versions of X.500, and as the + namespace is consistent, the information in the Directory can be + accessed by any implementation. Also, work is being done in providing + Yellow Pages services and other information resource location tasks + in the Directory. + + However, there are some limitations to the X.500 technology as it is + currently implemented. One price that is paid for the flexibility in + searching is a decline in the speed of the searching. This is because + a) searches over a part of the distributed namespace may have to + traverse the network, and some implementations cache all the + responses before giving them to the user, and b) some early + implementations performed search slowly anyway. A second problem with + the implementations is that for security reasons only a limited + amount of information is returned to the user; for example, if a + search turns up 1000 hits, only 20 or so are returned to the user. + Although this number is tunable, it does mean that someone with a big + search will have to do a lot of work. The performance of the + + + +DISI Working Group [Page 3] + +RFC 1308 Executive Intro to X.500 March 1992 + + + Directory, while increasing rapidly in the last two years, is still + not able to provide real-time directory services for such things as + routing protocols. However, work is being done to speed up service. + + The X.500 Directory is taking us closer to the day when we will + indeed have the entire world on our desktops, and X.500 will help + insure that we can find whom and what we need. + +4: FOR FURTHER INFORMATION + + For a more detailed technical introduction to X.500 and an extensive + bibliography, see "Technical Overview of Directory Services Using the + X.500 Protocol", by Weider, Reynolds, and Heker. This is available + from the NIC as FYI 14, RFC 1309. For a catalogue of X.500 + implementations, see "A Catalog of Available X.500 Implementations", + ed. Lang and Wright. This is available from the NIC as FYI 11, RFC + 1292. + +5: SECURITY CONSIDERATIONS + + Security issues are not discussed in this paper. + +6: AUTHORS' ADDRESSES + + Chris Weider + Advanced Network and Services, Inc. + 2901 Hubbard, G-1 + Ann Arbor, MI 48105-2437 + + Phone (313) 663-2482 + E-mail: weider@ans.net + + Joyce K. Reynolds + Information Sciences Institute + University of Southern California + 4676 Admirality Way + Marina del Rey, CA 90292 + + Phone: (310) 822-1511 + E-Mail: jkrey@isi.edu + + + + + + + + + + + +DISI Working Group [Page 4] + \ No newline at end of file diff --git a/doc/rfc/rfc1309.txt b/doc/rfc/rfc1309.txt new file mode 100644 index 0000000000..123eb26ef7 --- /dev/null +++ b/doc/rfc/rfc1309.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group C. Weider +Request for Comments: 1309 ANS +FYI: 14 J. Reynolds + ISI + S. Heker + JvNC + March 1992 + + + Technical Overview of Directory Services + Using the X.500 Protocol + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + This document is an overview of the X.500 standard for people not + familiar with the technology. It compares and contrasts Directory + Services based on X.500 with several of the other Directory services + currently in use in the Internet. This paper also describes the + status of the standard and provides references for further + information on X.500 implementations and technical information. + + A primary purpose of this paper is to illustrate the vast + functionality of the X.500 protocol and to show how it can be used to + provide a global directory for human use, and can support other + applications which would benefit from directory services, such as + main programs. + + This FYI RFC is a product of the Directory Information Services + (pilot) Infrastructure Working Group (DISI). A combined effort of + the User Services and the OSI Integration Areas of the Internet + Engineering Task Force (IETF). + +1. INTRODUCTION + + As the pace of industry, science, and technological development + quickened over the past century, it became increasingly probable that + someone in a geographically distant location would be trying to solve + the same problems you were trying to solve, or that someone in a + geographically distant location would have some vital information + which impinged on your research or business. The stupendous growth + in the telecommunications industry, from telegraphs to telephones to + computer networks, has alleviated the problem of being able to + + + +DISI Working Group [Page 1] + +RFC 1309 Technical Overview of X.500 March 1992 + + + communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH + THEM. + + Thus, along with the expansion of the telecommunications + infrastructure came the development of Directory Services. In this + paper, we will discuss various models of directory services, the + limitations of current models, and some solutions provided by the + X.500 standard to these limitations. + +2 MODELS OF DIRECTORY SERVICES + +2.1 The telephone company's directory services. + + A model many people think of when they hear the words "Directory + Services" is the directory service provided by the local telephone + company. A local telephone company keeps an on-line list of the names + of people with phone service, along with their phone numbers and + their address. This information is available by calling up Directory + Assistance, giving the name and address of the party whose number you + are seeking, and waiting for the operator to search his database. It + is additionally available by looking in a phone book published yearly + on paper. + + The phone companies are able to offer this invaluable service because + they administer the pool of phone numbers. However, this service has + some limitations. For instance, you can find someone's number only if + you know their name and the city or location in which they live. If + two or more people have listings for the same name in the same + locality, there is no additional information which with to select the + correct number. In addition, the printed phone book can have + information which is as much as a year out of date, and the phone + company's internal directory can be as much as two weeks out of date. + A third problem is that one actually has to call Directory assistance + in a given area code to get information for that area; one cannot + call a single number consistently. + + For businesses which advertise in the Yellow Pages, there is some + additional information stored for each business; unfortunately, that + information is unavailable through Directory Assistance and must be + gleaned from the phone book. + +2.2 Some currently available directory services on the Internet. + + As the Internet is comprised of a vast conglomeration of different + people, computers, and computer networks, with none of the hierarchy + imposed by the phone system on the area codes and exchange prefixes, + any directory service must be able to deal with the fact that the + Internet is not structured; for example, the hosts foo.com and + + + +DISI Working Group [Page 2] + +RFC 1309 Technical Overview of X.500 March 1992 + + + v2.foo.com may be on opposite sides of the world, the .edu domain + maps onto an enormous number of organizations, etc. Let's look at a + few of the services currently available on the Internet for directory + type services. + +2.2.1 The finger protocol. + + The finger protocol, which has been implemented for UNIX systems and + a small number of other machines, allows one to "finger" a specific + person or username to a host running the protocol. This is invoked by + typing, for example, "finger clw@mazatzal.merit.edu". A certain set + of information is returned, as this example from a UNIX system finger + operation shows, although the output format is not specified by the + protocol: + + Login name: clw In real life: Chris Weider + Directory: /usr/clw Shell: /bin/csh + On since Jul 25 09:43:42 4 hours 52 minutes Idle Time + Plan: + Home: 971-5581 + + where the first three lines of information are taken from the UNIX + operating systems information and the line(s) of information + following the "Plan:" line are taken from a file named .plan which + each user modifies. Limitations of the fingerd program include: a) + One must already know which host to finger to find a specific person, + b) since primarily UNIX machines run fingerd, people who reside on + other types of operating systems are not locateable by this method, + c) fingerd is often disabled on UNIX systems for security purposes, + d) if one wishes to be found on more than one system, one must make + sure that all the .plan files are consistent, and e) there is no way + to search the .plan files on a given host to (for example) find + everyone on mazatzal.merit.edu who works on X.500. Thus, fingerd has + a limited usefulness as a piece of the Internet Directory. + +2.2.2 whois + + The whois utility, which is available on a wide of variety of + systems, works by querying a centralized database maintained at the + DDN NIC, which was for many years located at SRI International in + Menlo Park, California, and is now located at GSI. This database + contains a large amount of information which primarily deals with + people and equipment which is used to build the Internet. SRI (and + now GSI) has been able to collect the information in the WHOIS + database as part of its role as the Network Information Center for + the TCP/IP portion of the Internet. + + The whois utility is ubiquitous, and has a very simple interface. A + + + +DISI Working Group [Page 3] + +RFC 1309 Technical Overview of X.500 March 1992 + + + typical whois query look like: + + whois Reynolds + + and returns information like: + + Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL + (702) 426-2604 (DSN) 830-2604 + Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL + (908) 532-3817 (DSN) 992-3817 + Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL + (DSN) 723-3358 + Reynolds, Joseph T. (JTR10) JREYNOLDS@PAXRV-NES.NAVY.MIL + 011-63-47-885-3194 (DSN) 885-3194 + Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU (213) 822-1511 + Reynolds, Keith (KR35) keithr@SCO.CO (408) 425-7222 + Reynolds, Kenneth (KR94) (502) 454-2950 + Reynolds, Kevin A. (KR39) REYNOLDS@DUGWAY-EMH1.ARMY.MIL + (801) 831-5441 (DSN) 789-5441 + Reynolds, Lee B. (LBR9) reynolds@TECHNET.NM.ORG (505) 345-6555 + + a further lookup on Joyce Reynolds with this command line: + + whois JKR1 + + returns: + + Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU + University of Southern California + Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + (310) 822-1511 + + Record last updated on 07-Jan-91. + + The whois database also contains information about Domain Name System + (DNS) and has some information about hosts, major regional networks, + and large parts of the MILNET system. + + The WHOIS database is large enough and comprehensive enough to + exhibit many of the flaws of a large centralized database: a) As the + database is maintained on one machine, a processor bottleneck forces + slow response during times of peak querying activity, even if many of + these queries are unrelated, b) as the database is maintained on one + machine, a storage bottleneck forces the database administrators to + severely limit the amount of information which can be kept on each + entry in the database, c) all changes to the database have to be + + + +DISI Working Group [Page 4] + +RFC 1309 Technical Overview of X.500 March 1992 + + + mailed to a "hostmaster" and then physically reentered into the + database, increasing both the turnaround time and the likelihood for + a mistake in transcription. + +2.2.3 The Domain Name System + + The Domain Name System is used in the Internet to keep track of host + to IP address mapping. The basic mechanism is that each domain, such + as merit.edu or k-12.edu, is registered with the NIC, and at time of + registration, a primary and (perhaps) some secondary nameservers are + identified for that domain. Each of these nameservers must provide + host name to IP address mapping for each host in the domain. Thus, + the nameservice is supplied in a distributed fashion. It is also + possible to split a domain into subdomains, with a different + nameserver for each subdomain. + + Although in many cases one uses the DNS without being aware of it, + because humans prefer to remember names and not IP addresses, it is + possible to interactively query the DNS with the nslookup utility. A + sample session using the nslookup utility: + + home.merit.edu(1): nslookup + Default Server: merit.edu + Address: 35.42.1.42 + + > scanf.merit.edu + Server: merit.edu + Address: 35.42.1.42 + + Name: scanf.merit.edu + Address: 35.42.1.92 + + > 35.42.1.92 + Server: merit.edu + Address: 35.42.1.42 + + Name: [35.42.1.92] + Address: 35.42.1.92 + + Thus, we can explicitly determine the address associated with a given + host. Reverse name mapping is also possible with the DNS, as in this + example: + + + + + + + + + +DISI Working Group [Page 5] + +RFC 1309 Technical Overview of X.500 March 1992 + + + home.merit.edu(2): traceroute ans.net + traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets + 1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms + 2 enss (35.1.1.1) 6 ms 6 ms 6 ms + ................. + 9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms + 10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms + + At each hop of the traceroute, the program attempts to do a reverse + lookup through the DNS and displays the results when successful. + + Although the DNS has served superlatively for the purpose it was + developed, i.e. to allow maintenance of the namespace in a + distributed fashion, and to provide very rapid lookups in the + namespace, there are, of course, some limitations. Although there has + been some discussion of including other types of information in the + DNS, to find a given person at this time, assuming you know where she + works, you have to use a combination of the DNS and finger to even + make a stab at finding her. Also, the DNS has very limited search + capabilities right now. The lack of search capabilities alone shows + that we cannot provide a rich Directory Service through the DNS. + +3: THE X.500 MODEL OF DIRECTORY SERVICE + + X.500 is a CCITT protocol which is designed to build a distributed, + global directory. It offers the following features: + + * Decentralized Maintenance: + Each site running X.500 is responsible ONLY for its local part + of the Directory, so updates and maintenance can be done instantly. + + * Powerful Searching Capabilities: + X.500 provides powerful searching facilities that allow users to + construct arbitrarily complex queries. + + * Single Global Namespace: + Much like the DNS, X.500 provides a single homogeneous namespace + to users. The X.500 namespace is more flexible and expandable + than the DNS. + + * Structured Information Framework: + X.500 defines the information framework used in the directory, + allowing local extensions. + + + + + + + + +DISI Working Group [Page 6] + +RFC 1309 Technical Overview of X.500 March 1992 + + + * Standards-Based Directory: + As X.500 can be used to build a standards-based directory, + applications which require directory information (e-mail, + automated resource locators, special-purpose directory tools) + can access a planet's worth of information in a uniform manner, + no matter where they are based or currently running. + +3.1 Acronym City, or How X.500 Works + + The '88 version of the X.500 standard talks about 3 models required + to build the X.500 Directory Service: the Directory Model, the + Information Model, and the Security Model. In this section, we will + provide a brief overview of the Directory and Information Models + sufficient to explain the vast functionality of X.500. + +3.1.1 The Information Model + + To illustrate the Information Model, we will first show how + information is held in the Directory, then we will show what types of + information can be held in the Directory, and then we will see how + the information is arranged so that we can retrieve the desired + pieces from the Directory. + +3.1.1.1 Entries + + The primary construct holding information in the Directory is the + "entry". Each Directory entry contains information about one object; + for example, a person, a computer network, or an organization. Each + entry is built from a collection of "attributes", each of which holds + a single piece of information about the object. Some attributes which + might be used to build an entry for a person would be "surname", + "telephonenumber", "postaladdress", etc. Each attribute has an + associated "attribute syntax", which describes the type of data that + attribute contains, for example, photo data, a time code, or a string + of letters and numbers. As an example, let's look at part of an entry + for a person. + + Entry for John Smith contains: + + attribute ---> surName= Smith <--- attribute value + |---> telephoneNumber= 999-9999 <--- attribute value + |---> title= Janitor <--- attribute value + ... + + The attribute syntax for the surName attribute would be + CaseIgnoreString, which would tell X.500 that surName could contain + any string, and case would not matter; the attribute syntax for the + telephoneNumber attribute would be TelephoneNumber, which would + + + +DISI Working Group [Page 7] + +RFC 1309 Technical Overview of X.500 March 1992 + + + specify that telephoneNumber could contain a string composed of + digits, dashes, parenthesis, and a plus sign. The attribute syntax + for the title attribute would also be CaseIgnoreString. A good + analogy in database terms for what we've seen so far might be to + think of a Directory entry as a database record, an attribute as a + field in that record, and an attribute syntax as a field type + (decimal number, string) for a field in a record. + +3.1.1.2 Object Classes + + At this point in our description of the information model, we have no + way of knowing what type of object a given entry represents. X.500 + uses the concept of an "object class" to specify that information, + and an attribute named "objectClass" which each entry contains to + specify to which object class(es) the entry belongs. + + Each object class in X.500 has a definition which lists the set of + mandatory attributes, which must be present, and a set of optional + attributes, which may be present, in an entry of that class. An given + object class A may be a subclass of another class B, in which case + object class A inherits all the mandatory and optional attributes of + B in addition to its own. + + The object classes in X.500 are arranged in a hierarchical manner + according to class inheritance; the following diagram shows a part of + the object class hierarchy. + + + + + + + + + + + + + + + + + + + + + + + + + +DISI Working Group [Page 8] + +RFC 1309 Technical Overview of X.500 March 1992 + + + _____________ + | | "top" has one mandatory + | top | attribute "objectClass", + |_____________| and nooptional attributes. + | | | + | | | every other object class is a + ________________| | | subclass of "top"... + | | ... + ______|________ _____|_______ + | | | |"organization" inherits one + | country | | organization |mandatory attribute from + |_______________| |_______________|"top", "objectClass"; adds one + more mandatory attribute "O" + "country" inherits one (for organization), and has + mandatory attribute from "top", many optional attributes. Any + "objectClass", adds one more subclass of "organization" + mandatory attribute "c" (for would inherit all of the + country), and has two optional mandatory and optional + attributes, "description" and attributes from "organization" + "searchGuide". Any subclass of including the attribute which + "country" would inherit all of the "organization" inherited + mandatory and optional attributes from "top". + of the "country" class, including + the attribute which "country" + inherited from "top". + + Figure 1. + + One major benefit of the object class concept is that it is in many + cases very easy to create a new object class which is only a slight + modification or extension of a previous class. For example, if I have + already defined an object class for "person" which contains a + person's name, phone number, address, and fax number, I can easily + define an "Internet person" object class by defining "Internet + person" as a subclass of "person", with the additional optional + attribute of "e-mail address". Thus in my definition of the "Internet + Person" object class, all my "person" type attributes are inherited + from "person". There are other benefits which are beyond the scope of + this paper. + +3.1.1.3 X.500's namespace. + + X.500 hierarchically organizes the namespace in the Directory + Information Base (DIB); recall that this hierarchical organization is + called the Directory Information Tree (DIT). Each entry in the DIB + occupies a certain location in the DIT. An entry which has no + children is called a leaf entry, an entry which has children is + called a non-leaf node. Each entry in the DIT contains one or more + + + +DISI Working Group [Page 9] + +RFC 1309 Technical Overview of X.500 March 1992 + + + attributes which together comprise the Relative Distinguished Name + (RDN) of that entry, there is a "root" entry (which has no + attributes, a special case) which forms the base node of the DIT. The + Distinguished Name of a specific entry is the sequence of RDNs of the + entries on the path from the root entry to the entry in question. A + diagram here will help to clarify this: + +Level of DIT Root RDN Distinguished Name + +root * nothing { } + / | \ +country (other / | \ +things at this / | \ c=us {c=us} +level) c=gb c=us c=ca + / | \ + / | \ + / | \ +organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit} +(other things / | \ +at this level) / | \ + / | \ +Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit, + cn=Chris Weider} + + Figure 2: Building a DN from RDNs (adapted from a + diagram in the X.500 (88) Blue Book) + + Each entry in this tree contains more attributes than have been shown + here, but in each case only one attribute for each entry has been + used for that entry's RDN. As noted above, any entry in the tree + could use more than one attribute to build its RDN. X.500 also allows + the use of alias names, so that the entry {c=us, o=Merit, cn=Chris + Weider} could be also found through an alias entry such as {c=us, + o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first + entry. + +3.1.2 The Directory Model + + Now that we've seen what kinds of information can be kept in the + Directory, we should look at how the Directory stores this + information and how a Directory users accesses the information. There + are two components of this model: a Directory User Agent (DUA), which + accesses the Directory on behalf of a user, and the Directory System + Agent, which can be viewed as holding a particular subset of the DIB, + and can also provide an access point to the Directory for a DUA. + + Now, the entire DIB is distributed through the world-wide collection + of DSAs which form the Directory, and the DSAs employ two techniques + + + +DISI Working Group [Page 10] + +RFC 1309 Technical Overview of X.500 March 1992 + + + to allow this distribution to be transparent to the user, called + "chaining" and "referral". The details of these two techniques would + take up another page, so it suffices to say that to each user, it + appears that the entire global directory is on her desktop. (Of + course, if the information requested is on the other side of the + world, it may seem that the desktop directory is a bit slow for that + request...) + +3.2 The functionality of X.500 + + To describe the functionality of X.500, we will need to separate + three stages in the evolution of X.500: 1) the 1988 standard, 2) + X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard. + We will list some of the features described in the 1988 standard, + show how they were implemented in QUIPU, and discuss where the 1992 + standard will take us. The QUIPU implementation was chosen because + a) it is widely used in the U.S. and European Directory Services + Pilot projects, and b) it works well. For a survey of other X.500 + implementations and a catalogue of DUAs, see [Lang]. + +3.2.1 Functionality in X.500 (88) + + There are a number of advantages that the X.500 Directory accrues + simply by virtue of the fact that it is distributed, not limited to a + single machine. Among these are: + + * An enormously large potential namespace. + Since the Directory is not limited to a single machine, many + hundreds of machines can be used to store Directory entries. + + * The ability to allow local administration of local data. + An organization or group can run a local DSA to master their + information, facilitating much more accurate data throughout + the Directory. + + The functionality built into the X.500(88) standard includes: + + * Advanced searching capabilities. + The Directory supports arbitrarily complex searches at an + attribute level. As the object classes a specific entry + belongs to is maintained in the objectClass attribute, this + also allows Directory searches for specific types of objects. + Thus, one could search the c=US subtree for anyone with a last + name beginning with S, who also has either a fax number in the + (313) area code or an e-mail address ending in umich.edu. + This feature of X.500 also helps to provide the basic + functionality for a Yellow Pages service. + + + + +DISI Working Group [Page 11] + +RFC 1309 Technical Overview of X.500 March 1992 + + + * A uniform namespace with local extensibility. + The Directory provides a uniform namespace, but local + specialized directories can also be implemented. Locally + defined extensions can include new object classes, new + attributes, and new attribute types. + + * Security issues. + The X.500 (88) standards define two types of security for + Directory data: Simple Authentication (which uses passwords), + and Strong Authentication (which uses cryptographic keys). + Simple authentication has been widely implemented, strong + authentication has been less widely implemented. Each of + these authentication techniques are invoked when a user or + process attempts a Directory operation through a DUA. + + In addition to the global benefits of the X.500 standard, there are + many local benefits. One can use their local DSA for company or + campus wide directory services; for example, the University of + Michigan is providing all the campus directory services through + X.500. The DUAs are available for a wide range of platforms, + including X-Windows systems and Macintoshes. + +3.2.2 Functionality added by QUIPU. + + Functionality beyond the X.500 (88) standard implemented by QUIPU + includes: + + * Access control lists. + An access control list is a way to provide security for each + attribute of an entry. For example, each attribute in a given + entry can be permitted for detect, compare, read, and modify + permissions based on the reader's membership in various groups. + For example, one can specify that some information in a given + entry is public, some can be read only by members of the + organization, and some can only be modified by the owner of + the entry. + + * Replication. + Replication provides a method whereby frequently accessed + information in a DSA other than the local one can be kept by + the local DSA on a "slave" basis, with updates of the "slave" + data provided automatically by QUIPU from the "master" data + residing on the foreign DSA. This provides alternate access + points to that data, and can make searches and retrievals + more rapid as there is much less overhead in the form or + network transport. + + + + + +DISI Working Group [Page 12] + +RFC 1309 Technical Overview of X.500 March 1992 + + +3.3 Current limitations of the X.500 standard and implementations. + + As flexible and forward looking as X.500 is, it certainly was not + designed to solve everyone's needs for all time to come. X.500 is not + a general purpose database, nor is it a Data Base Management System + (DBMS). X.500 defines no standards for output formats, and it + certainly doesn't have a report generation capability. The technical + mechanisms are not yet in place for the Directory to contain + information about itself, thus new attributes and new attribute types + are rather slowly distributed (by hand). + + Searches can be slow, for two reasons: a) searches across a widely + distributed portion of the namespace (c=US, for example) has a delay + which is partially caused by network transmission times, and can be + compounded by implementations that cache the partial search returns + until everyone has reported back, and b) some implementations are + slow at searching anyway, and this is very sensitive to such things + as processor speed and available swap space. Another implementation + "problem" is a tradeoff with security for the Directory: most + implementations have an administrative limit on the amount of + information which can be returned for a specific search. For + example, if a search returns 1000 hits, 20 of those might be + displayed, with the rest lost. Thus a person performing a large + search might have to perform a number of small searches. This was + implemented because an organization might want to make it hard to + "troll" for the organization's entire database. + + Also, there is at the moment no clear consensus on the ideal shape of + the DIT, or on the idea structure of the object tree. This can make + it hard to add to the current corpus of X.500 work, and the number of + RFCs on various aspects of the X.500 deployment is growing monthly. + + Despite this, however, X.500 is very good at what it was designed to + do; i.e., to provide primary directory services and "resource + location" for a wide band oftypes of information. + +3.4 Things to be added in X.500 (92). + + The 1988 version of the X.500 standard proved to be quite sufficient + to start building a Directory Service. However, many of the new + functions implemented in QUIPU were necessary if the Directory were + to function in a reasonable manner. X.500 (92) will include + formalized and standardized versions of those advances, including + + * A formalized replication procedure. + + * Enhanced searching capacities. + + + + +DISI Working Group [Page 13] + +RFC 1309 Technical Overview of X.500 March 1992 + + + * Formalization of access control mechanisms, including access + control lists. + + Each of these will provide a richer Directory, but you don't have to + wait for them! You can become part of the Directory today! + +4: WHAT X.500 CAN DO FOR YOU TODAY + +4.1 Current applications of X.500 + + X.500 is filling Directory Services needs in a large number of + countries. As a directory to locate people, it is provided in the + U.S. as the White Pages Pilot Project, run by PSI, and in Europe + under the PARADISE Project as a series of nation-wide pilots. It is + also being used by the FOX Project in the United States to provide + WHOIS services for people and networks, and to provide directories of + objects as disparate as NIC Profiles and a pilot K-12 Educators + directory. It is also being investigated for its ability to provide + resource location facilities and to provide source location for WAIS + servers. In fact, in almost every area where one could imagine + needing a directory service (particularly for distributed directory + services), X.500 is either providing those services or being expanded + to provide those services. + + In particular, X.500 was envisioned by its creators as providing + directory services for electronic mail, specifically for X.400. It is + being used in this fashion today at the University of Michigan: + everyone at the University has a unified mail address, e.g. + Chris.Weider@umich.edu. An X.500 server then reroutes that mail to + the appropriate user's real mail address in a transparent fashion. + Similarly, Sprint is using X.500 to administrate the address space + for its internal X.400 mail systems. + + Those of us working on X.500 feel that X.500's strengths lie in + providing directory services for people and objects, and for + providing primary resource location for a large number of online + services. We think that X.500 is a major component (though not the + only one) of a global Yellow Pages service. We would also like to + encourage each of you to join your national pilot projects; the more + coverage we can get, the easier you will be able to find the people + you need to contact. + + + + + + + + + + +DISI Working Group [Page 14] + +RFC 1309 Technical Overview of X.500 March 1992 + + +5. For Further Information + + For further information, the authors recommend the following + documents: + + Weider, C., and J. Reynolds, "Executive Introduction to Directory + Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI, + March 1992. + + Lang, R., and R. Wright, Editors, "A Catalog of Available X.500 + Implementations", FYI 11, RFC 1292, SRI International, Lawrence + Berkeley Laboratory, January 1992. + + Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet + X.500 Schema", RFC 1274, University College London, November 1991. + + Hardcastle-Kille, S., "Replication Requirements to provide an + Internet Directory using X.500", RFC 1275, University College + London, November, 1991. + + Hardcastle-Kille, S., "Replication and Distributed Operations + extensions to provide an Internet Directory using X.500", RFC + 1276, University College London, November 1991. + + Hardcastle-Kille, S., "Encoding Network Addresses to support + operation over non-OSI lower layers", RFC 1277, University College + London, November 1991. + + Hardcastle-Kille, S., " A string encoding of Presentation + Address", RFC 1278, University College London, November 1991. + + Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University + College London, November 1991. + +6. Security Considerations + + Security issues are discussed in section 3. + + + + + + + + + + + + + + +DISI Working Group [Page 15] + +RFC 1309 Technical Overview of X.500 March 1992 + + +7. Authors' Addresses + + Chris Weider + Advanced Network and Services, Inc. + 2901 Hubbard G-1 + Ann Arbor, MI 48105-2437 + + Phone (313) 663-2482 + E-mail: weider@ans.net + + + Joyce K. Reynolds + Information Sciences Institute + University of Southern California + 4676 Admirality Way + Marina del Rey, CA 90292 + + Phone: (310) 822-1511 + EMail: jkrey@isi.edu + + + Sergio Heker + JvNCnet + Princeton University + 6 von Neumann Hall + Princeton, NJ 08544 + + Phone: (609) 258-2400 + Email: heker@nisc.jvnc.net + + + + + + + + + + + + + + + + + + + + + + +DISI Working Group [Page 16] + \ No newline at end of file diff --git a/doc/rfc/rfc1430.txt b/doc/rfc/rfc1430.txt new file mode 100644 index 0000000000..a5d9f6077c --- /dev/null +++ b/doc/rfc/rfc1430.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group S. Hardcastle-Kille +Request for Comments: 1430 ISODE-Consortium + E. Huizer + SURFnet bv + V. Cerf + Corporation for National Research Initiatives + R. Hobby + University of California, Davis + S. Kent + Bolt, Beranek and Newman + February 1993 + + + A Strategic Plan for Deploying an + Internet X.500 Directory Service + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + There are a number of reasons why a new Internet Directory Service is + required. This document describes an overall strategy for deploying + a Directory Service on the Internet, based on the OSI X.500 Directory + Service. It then describes in more detail the initial steps which + need to be taken in order to achieve these goals, and how work + already undertaken by Internet Engineering Task Force Working Groups + (IETF WGs) is working towards these goals. + +Table of Contents + + 1. REQUIREMENTS 2 + 2. SUMMARY OF SOLUTION 3 + 3. INFORMATION FRAMEWORK 3 + 3.1 The Technical Model 3 + 3.2 Extending the Technical Model 4 + 3.3 The Operational Model 5 + 4. NAME ASSIGNMENT 5 + 5. DIRECTORY INFRASTRUCTURE 6 + 5.1 Short Term Requirements 7 + 5.2 Medium Term Requirements 9 + 5.3 Long Term Requirements 9 + 6. DATAMANAGEMENT 9 + 6.1 Legal Issues 10 + 7. TECHNICAL ISSUES 10 + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 1] + +RFC 1430 X.500 Strategy February 1993 + + + 7.1 Schema 11 + 7.2 Use on the Internet 11 + 7.3 Replication of Knowledge and Data 12 + 7.4 Presentation of Directory Names 13 + 7.5 DSA Naming and MD Structure 13 + 8. SECURITY 13 + 8.1 Directory Provision of Authentication 14 + 8.2 Directory Security 15 + 9. RELATION TO DNS 16 + 10. EXTERNAL CONNECTIONS 16 + 11. REFERENCES 17 + 12. Security Considerations 19 + 13. Authors' Addresses 20 + +1. REQUIREMENTS + + There is substantial interest in establishing a new Directory Service + on the Internet. In the short term, there is pressure to establish + two new services: + + - White Pages lookup of users; + + - Support for X.509 Authentication for a range of applications in + particular for Privacy Enhanced mail [Lin89]. + + In the medium term, there are likely to be many requirements for + Directory Services, including: + + - General resource lookup, for information ranging from committee + structures to bibliographic data; + + - Support of management of the Internet infrastructure, and + integration of configuration information into the higher level + directory; + + - Support of applications on the Internet. For example: + + o Electronic distribution lists; + o Capability information on advanced user agents; + o Location of files and archive services. + + - Support for Mail Handling Systems; Be they RFC-822 based or X.400 + based (IETF MHS-DS WG), e.g.,: + + o Support for routing; + o Info on User agent capabilities; essential for a usage of + Multimedia mail like MIME (Multipurpose Internet Mail + Extensions). + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 2] + +RFC 1430 X.500 Strategy February 1993 + + + For the longer term, more sophisticated usages of X.500 are possible + extending it into a useful and fast yellow pages service. + +2. SUMMARY OF SOLUTION + + In principle, the current Internet Domain Name System (DNS) could be + used for many of these functions, with appropriate extensions. + However, it is suggested that a higher level of directory service is + needed. It is proposed to establish an Internet Directory Service + based on X.500. This provides appropriate functionality for the + services envisaged and gives flexibility for future extension. This + extension could be achieved either by tracking the evolution of the + OSI Standard or by work specific to the Internet. In practice, it is + likely to be a mixture of both. + + By deploying X.500 in some form on the Internet, a truly global and + universal Directory Service can be built that will provide Internet + users with fast access to all kinds of data. The X.500 Directory + Service in this case may range from a simple white pages service + (information on people and services) to coupling various existing + databases and information repositories in a universal way. + + Currently, several different but cooperating X.500 Directory Services + pilots are taking place on the Internet. These pilots form an + important base for experimenting with this new service. Starting with + these pilots, with the X.500 products arriving on the market today, + and given sufficient funding for the central services described in + this paper an operational X.500 Directory Service can be deployed. + + The final goal of the strategy described in this paper is to deploy a + fully operational Directory Service on the Internet, providing the + functions mentioned in the previous section. + +3. INFORMATION FRAMEWORK + + The most critical aspect of the Directory Service is to establish an + Internet Information Framework. When establishing a sophisticated + distributed directory with a coherent information framework, it + involves substantial effort to map data onto this framework. This + effort is an operational effort and far outweighs the technical + effort of establishing servers and user agents. + +3.1 The Technical Model + + By choosing the X.500 model as a basis for the information framework, + it will also be part of a (future) global information framework. The + key aspects of this model are: + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 3] + +RFC 1430 X.500 Strategy February 1993 + + + - A hierarchical navigational system that couples distributed + databases (of various kinds), which allows for management of the + data by the organization/person responsible for the data; + + - Each object in this information structure (called the Directory + Information Tree, DIT) is represented as an entry; + + - Objects are typed by an "object class", which permits multiple + inheritance; + + - An object is described by a set of attributes; + + - Each attribute is typed. Attribute types are hierarchical; + + - Each attribute type has an associated attribute syntax, which may + be generic or shared with other attributes (e.g., Integer Syntax; + Distinguished name Syntax); This allows for representation of + simple attributes (e.g., strings or bitmaps) or complex ones with + detailed structures. + + - Each entry has an unambiguous and unique global name; + + - Alternate hierarchies may be built by use of aliases or pointers of + distinguished name syntax. + + This framework allows for representation of basic objects such as + users within organizations. It is also highly extensible, and so can + be used for a range of other applications. + +3.2 Extending the Technical Model + + In the longer term, the model could be extended to deal with a number + of other requirements which potentially must be met by an Internet + Directory Service. Possible extensions include: + + - Support of ordered attributes (needed by some applications such as + message storage); + + - Extensions to allow unification with management information, + associated with SNMP (Simple Network Management Protocol) [CFSD90] + or other management protocols; + + - Handling of non-hierarchical data in a better manner for searching + and retrieval, whilst retaining the basic hierarchy for management + purposes. This is essentially building a general purpose resource + location service on top of the basic infrastructure. It will need + work on the information model, and not just the access protocols. + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 4] + +RFC 1430 X.500 Strategy February 1993 + + + It is noted that although X.500 may not provide the ultimate solution + to information retrieval, it has good potential for solving a lot of + information service related problems. + +3.3 The Operational Model + + To make the Directory Service with a coherent information framework + really operational requires a lot of effort. The most probable + operational model is one where larger organizations on the Internet + maintain their part of the DIT on their own DSA (Directory System + Agent). Smaller organizations will "rent" DSA space from regional + networks or other service providers. Together these DSAs will form + the Internet Directory Service Infrastructure. To couple the various + parts of the DIT that are contained on these Internet DSAs, a special + DSA containing the Root for the naming hierarchy within the DIT has + to be established and maintained. + + The following tasks can be foreseen: + + - Defining the naming hierarchy; See section 4. + - Creating the Directory Infrastructure; See section 5. + - Getting the Data into the directory; and + - Managing the data in the Directory. See section 6. + +4. NAME ASSIGNMENT + + In order to deploy the Internet Directory Service, it is important to + define how the naming hierarchy will be structured. Although the + basic model suggests a simple monolithic "database" containing all of + the Internet's information infrastructure, with a namespace divided + along geographic boundaries, this may not be the definite model that + turns out to be the most appropriate to the Internet. Different + models may evolve according to the needs of the Internet and the + applications used on the Internet (i.e., some parts of the DIT may be + assigned at the root for the Internet). Below this one can envisage + several loosely coupled namespaces each with their own area of + applicability. This should be handled as a part of the general + operation of a directory service. An example of this might be + assignment of a representation of the Domain Namespace under the root + of the DIT. This is further discussed in [BHK91a]. + + However, the core DIT information will be nationally assigned. The + parts of the DIT below country level will be managed differently in + each country. In many countries, registration authorities will be + established according to the OSI Standard [ISO]. This has been done + in some countries by the national ISO member body representative (for + example in the UK by BSI). + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 5] + +RFC 1430 X.500 Strategy February 1993 + + + The lower parts of the hierarchy will, in general, be delegated to + organizations who will have control over Name Assignment in that part + of the tree. There is no reason to mandate how to assign this + hierarchy, although it is appropriate to give guidelines. Proposed + solutions to assignment of namespace are given in [BHK92]. + + In North America, there is an alternative approach being developed by + the North American Directory Forum (NADF), which leverages existing + registration mechanisms [For91]. It is not yet clear what form a + final North American Directory Service will take. It is expected that + similar initiatives will be taken in other places, such as Europe. + For the Internet, the Internet Society (ISOC) has been suggested as a + possible Naming Authority. + + A discussion of the main issues involved with representing the Real + World in the Directory Service is part of the work undertaken by the + IETF OSI DS Working Group. + + The core of the Internet Directory will therefore come to exist of a + country based structure with different national naming schemes below + the countries. It is clearly desirable that the Internet Directory + Service follows any evolving national and international hierarchies. + However, this should not be allowed to cause undue delay. The + strategy proposed is to proceed with name assignment as needed, and + to establish interim registration authorities where necessary, taking + practical steps to be aligned with emerging national authorities + wherever possible. + + It is suggested that the Internet Directory Service does two things: + + First, each national part of the Internet DIT namespace should be + delegated to an appropriate organization, which will usually be in + the country of question. Second, the delegated organization should + assign names for that country as part of the Internet Directory + Service. This should be done in a manner which is appropriately + aligned with any emerging local or national service, but does not + unduly delay the deployment of the Internet Directory Service. For + most countries, this will fit in as a natural evolution of the early + directory piloting, where operators of pilots have acted as interim + name registration authorities. + +5. DIRECTORY INFRASTRUCTURE + + To provide access to the Internet Directory Service, an + infrastructure has to be built. Although the technical components of + an X.500 infrastructure are clear: DSAs (that hold the actual data) + and DUAs (that allow users and applications to access the data), a + lot more is needed for deployment of an Internet Directory Service. + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 6] + +RFC 1430 X.500 Strategy February 1993 + + + The Integrated Directory Services (IDS) Working Group of the IETF is + playing a key role in solving most of the issues that are related to + the building of an appropriate infrastructure. + + Many of the issues cited in this section have come forward out of + interim pilots that have been established on the Internet: + + PSI White Pages Pilot + This is a pilot service which is operating X.500 on the Internet. + In many ways it is operating as an Internet wide pilot. + + FOX + Fielding Operational X.500, a project to explore the development + and interoperability of X.500 implementations. + + Paradise (Piloting A ReseArch DIrectory Service in Europe) + This project has been providing the necessary glue to hold the + various national activities together [Par91]. + +5.1 Short Term Requirements + + - Central Operations. There is a need for a number of operations + to be managed as a service for the whole Internet. These services + are: + + o A root DSA; containing the top-level of the DIT, has to be + provided. Currently, this root DSA is managed by the Paradise + project. + + o Name assignment; Inserting names into the Directory, this has + been discussed in section 4. This could be done in conjunction + with the appropriate Registration Authority or by the + Registration Authority. In most cases it is likely to be the + former, and mechanisms will need to be set up to allow + organizations to get their names installed into the directory, + either direct or through the registration authority. + + o Knowledge management; i.e., the information on "which DSA holds + what part of the DIT, and how can that DSA be accessed". DSAs + will be established by Organizations. There will be a need to + centrally coordinate the management of the knowledge information + associated with these DSAs. This is likely to be coupled to the + name assignment. + + o Knowledge and Data replication; For the Directory to perform + well, knowledge and data high up in the DIT must be + significantly replicated. A service must be provided to make + replicated information available to DSAs that need it. + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 7] + +RFC 1430 X.500 Strategy February 1993 + + + It is suggested that for the time being, Paradise should be used + as the initial basis for handling the top-level of the DIT and for + provision of the central services. However, the services mentioned + above need to be provided at a national level for every + participating country in the Internet Directory Service. Whenever + an organization starts a new country branch of the DIT in the + Internet Directory Service the central operations will have to + help out to make sure that these services will be properly + installed on a national level. + + - An effective service will need to have sufficient implementations, + in order to give full coverage over different hardware and software + platforms, and to demonstrate openness. The recent Directory + Information Services (pilot) Infrastructure Working Group's (DISI) + Survey of Directory Implementations suggests that there will not be + a problem here. This provides a list of available X.500 + implementations and their capabilities [LW91]. + + - An executive summary, necessary to convince the management of + computer centers to invest manpower into setting up a X.500 + Directory Service. This is provided by DISI [WR92]. + + - Due to the possible different and rather independent structured + namespaces that can be envisaged in the DIT for different purposes, + DUAs will have to be "tuned intelligently" for the applications that + they are used for. + + - To allow users easy access to the Internet Directory Service even + from low powered workstations, a lightweight protocol has to be + developed over TCP/IP. Already two private protocols that do this + have been developed: The Michigan DIXIE protocol [HSB91] and the PSI + Directory Assistance Service [Ros91]. The IETF OSI Directory + Services Working Group (OSI-DS WG) is currently working on a + standard lightweight protocol called LDAP. + + - Although the Internet Directory Service does not have to make any + mandatory requirements about the use of lower layers, it is noted + that the use of STD 35, RFC 1006 to allow use of OSI applications on + top of TCP/IP is essential for deployment in the Internet. Other + stacks like the ones using CLNS, CONS and X.25(80) will probably + also be deployed in parts of the Internet. DSAs with different + stacks will be linked through use of either application level relays + (chaining) or Transport Service bridges. + + - There are multiple issues that are not dealt with (properly) in the + X.500 standard and thus prevent the building of an Internet + Directory service. Intermediate solutions for these issues have to + be established in an "open" way. The results will have to be + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 8] + +RFC 1430 X.500 Strategy February 1993 + + + deployed as well as to be fed back into the relevant standard + committees. The IETF OSI-DS WG deals with these issues. Section 7 + describes several of these issues. + + - Site support. The IETF IDS WG is looking at providing the necessary + documentation to help with the provision of support for Directory + users at participating sites. + +5.2 Medium Term Requirements + + - Enhanced performance is necessary to allow for a real global usage; + + - The schema has to be extended to allow for various kinds of data, + e.g.,: + + o NIC data; + o Resource location; + + - Support for Internet Message Handling services (RFC-822, MIME and + X.400). This work is already undertaken by the IETF MHS-DS WG. + +5.3 Long Term Requirements + + - To make sure that X.500 evolves into an operational service, it is + essential to track its evolution, and to feed back into the + evolution process. + + - Interface existing RDBMS into the Directory Service. + + - To increase the performance of the directory, and thereby making it + useful for an even wider range of applications (e.g., policy based + routing), a lightweight protocol for access and system usage is + needed. + +6. DATAMANAGEMENT + + The whole of the Directory Infrastructure won't stand much chance + without proper datamanagement of the data contained within the DIT. + Procedures need to be established to assure a certain Level of + Quality of the data contained in the DIT. + + Due to the very nature of X.500, the management of the data is + distributed over various sources. This has the obvious advantage that + the data will be maintained by the owner of the data. It does + however, make it quite impossible to describe one single procedure + for datamanagement. + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 9] + +RFC 1430 X.500 Strategy February 1993 + + + For the Internet Directory Service, guidelines will have to be + developed (by the IETF IDS WG), to help organizations that start with + deployment of X.500 on how to manage data in their part of the DIT. + The guidelines should describe a minimum level of quality that has to + be supplied to make the service operational. The IETF OSI-DS WG will + initiate a pilot on Quality of Service parameters in the Directory, + that will be of use. + + Pilot datamanagement projects will have to be done (e.g., existing + databases should be connected to the Internet Directory Service). + Tools that are developed to achieve this should be made available to + the Internet community for possible future use. + +6.1 Legal Issues + + Most countries connected to the Internet have some sort of law that + dictates how data on people can and cannot be made available. These + laws deal with privacy and registration issues, and will differ from + country to country. It is suggested that each of the national + organizations within the Internet that manages the Internet Directory + Services master for that country, undertake some research as to the + applicability of laws within that country on data made public through + use of X.500. + + In the mean time, a general "User Bill of Rights" should be + established to indicate what the proper use of the Internet Directory + Service is. This "Bill of Rights" could be drafted by the IETF IDS + WG. As a basis, the NADF "User Bill of Rights" [For92] can be used. + +7. TECHNICAL ISSUES + + The IETF has established the OSI-DS WG. The major component of the + initial work of this group is to establish a technical framework for + deploying a Directory Service on the Internet, making use of the + X.500 protocols and services [CCI88b]. This section describes the + work already done by this working group, which has been implicitly + focused on the technical infrastructure needed to deploy the Internet + Directory service. + + The OSI Directory Standards do not yet contain sufficient specifics + to enable the Internet Directory Service to be built. Full openness + and interoperability are a key goal, so we may need Internet specific + agreements, at least until the ISO standards are more complete. This + section notes areas where the standards do not have sufficient + coverage, and indicates the RFCs which have been written to overcome + these problems. + + The work is being limited to (reasonably well) understood issues. + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 10] + +RFC 1430 X.500 Strategy February 1993 + + + This means that whilst we will attempt to solve a wider range of + problems, not all potential requirements will necessarily be met. + + The technical work is done in conjunction with the RARE WG on Network + Application Support WG (formerly RARE WG3). The IETF WGs and the RARE + WG have a common technical mailing list. It is intended that this + will lead to a common European and North American technical approach. + +7.1 Schema + + A Directory needs to be used in the context of an Information + Framework. The standard directory provides a number of a attributes + and object classes to enable basic operation. It is certain that the + Internet community will have requirements for additional attributes + and object classes. There is a need to establish a mechanism to + register such information. + + Pilots in the European RARE Community and the US PSI White Pages + Pilot have based their information framework on the THORN and RARE + Naming Architecture. This architecture should be used for the + Internet Directory Service, in conjunction with COSINE based services + in Europe. A revised version of the Naming Architecture, with a + mechanism for registration of new attributes and object classes, has + been released as RFC 1274 [BHK91a]. + +7.2 Use on the Internet + + It is a recognized policy on the Internet to deploy OSI Applications + over non-OSI lower layers (such as STD 35, RFC 1006) [RC87]. This + policy allows deployment of OSI Applications before an OSI lower + layer infrastructure has been deployed. Thus, the Internet Directory + Service will decouple deployment of the OSI Directory from deployment + of the OSI lower layers. As the Internet Directory service will + extend into the far corners of the Internet namespace, where the + underlying technology is not always TCP/IP, the Internet Directory + Service will not make any mandatory requirements about use of lower + layers. When configuring the Internet Directory Services, variations + in the lower layers must be considered. The following options are + possible: + + - Operation on top of TCP/IP using a lightweight protocol. + + - Operation over TCP/IP using STD 35, RFC 1006. This is a practical + requirement of deployment at very many Internet sites, and is the + basis of the existing services. It is highly recommended that all + participating DSAs support this stack. + + - Use of OSI Network Service (Connection Oriented or Connectionless). + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 11] + +RFC 1430 X.500 Strategy February 1993 + + + - X.25(80) will probably not be used in the core infrastructure of + the Internet Directory Service, but is the basis of some European + activities. It may be needed later to interconnect with US + commercial systems not on the Internet. There will be a practical + need to interwork with DSAs which only support this stack. + + This approach has the following implications: + + 1. There is a need to represent TCP/IP addresses within OSI Network + Addresses. This is specified in RFC 1277 [HK91a]. + + 2. It will be desirable to have a uniform method to present Network + Addresses of this style. Therefore, a string representation of + presentation addresses is specified in RFC 1278 [HK91d]. + + 3. This approach leads to the situation where not all DSAs can + communicate directly due the different choice of lower layers. + This is already a practical result of many European sites operating + DSAs over X.25. When the Internet Directory Service is deployed, + the issue of which DSAs operate which stacks must be considered in + order to achieve a coherent service. In particular, there may be a + need to require DSAs that serve parts higher up in the DIT to serve + multiple stacks. This will be tackled as an operational issue. + + 4. There may be a requirement to extend the distributed operations, so + that there is no requirement for full connectivity (i.e., each DSA + supports each stack). A solution to this problem, by defining + "relay DSAs" is specified in RFC 1276 [HK91b]. + +7.3 Replication of Knowledge and Data + + There are a number of requirements on replication, both of data (the + actual information on objects in the directory) and knowledge (the + information on where do I find what data) information, which must be + met before an Internet Directory can be deployed. The 1988 standard + cannot be used as is, because it does not deal with replication or + caching. This leads to serious problems with performance. There is a + partial solution available in the 1992 version of the standard, + however there are no products available yet that implement this + solution. These issues are discussed in more detail in RFC 1275 + [HK91c]. + + As it took too long for 1992 implementations to arrive to be of any + help to the already rapidly growing pilot that urgently needed a + solution, an option was chosen to use a simple interim approach as + defined in RFC 1276. It will be clearly emphasized that this is an + interim approach, which will be phased out as soon as the appropriate + standards are available and stable implementations are deployed. The + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 12] + +RFC 1430 X.500 Strategy February 1993 + + + interim approach is based on the approach used in the QUIPU + Implementation and it is widely deployed in the existing pilots. + +7.4 Presentation of Directory Names + + The standard does not specify a means to present directory names to + the user. This is seen as a serious deficiency, and a standard for + presenting directory names is required. For Distinguished Names, a + string representation is defined in [HK92a]. However, as the + distinguished name is not very friendly for the user, a more user + oriented specification of a standard format for representing names, + and procedures to resolve them is chosen on the Internet, and is + specified in [HK92b]. + +7.5 DSA Naming and MD Structure + + There are some critical issues related to naming of DSAs and the + structure of Directory Management Domains. The main issues are: + + - It is hard to achieve very high replication of knowledge + information as this is very widely spread; + + - There is a need to give DSAs more reasonable names, which will + contain an indication on the role of the DSA; This is necessary for + DSAs high up the DIT. + + - There is too much DIT clutter in the current pilots; + + - There is no real concept of a DMD (Directory Management Domain) + authority. + + These will be significant as the directory increases in size by + orders of magnitude. The IETF OSI-DS WG is working to develop a + solution in this area. + +8. SECURITY + + A Directory can be an important component in the overall provision of + security in a distributed system environment, especially when + public-key cryptographic technology is employed. The directory can + serve as a repository for authentication information, which, in turn, + forms the basis of a number of OSI Authentication Services (e.g., + X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM). The + directory may also use this and other stored authentication + information to provide a wide range of security Services used by the + Directory system itself. + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 13] + +RFC 1430 X.500 Strategy February 1993 + + +8.1 Directory Provision of Authentication + + The directory will be used to provide X.509 strong authentication. + This places minimal requirements on the directory. To use this + infrastructure, users of authentication services must have access to + the directory. In practice, this type of authentication can be + deployed only on a limited scale without use of a directory, and so + this provision is critical for applications such as Privacy Enhanced + Mail [Lin93]. The PEM development is considering issues relating to + deploying Certification Authorities, and this discussion is not + duplicated here. + + PEM defines a key management architecture based on the use of + public-key certificates, in support of the message encipherment and + authentication procedures defined in [Lin93]. The PEM certificate + management design [Ken93] makes use of the authentication framework + defined by X.509. In this framework, as adopted by PEM, a + "certification authority" representing an organization applies a + digital signature to a collection of data consisting of a user's + public component, various information that serves to identify the + user, and the identity of the organization whose signature is + affixed. This establishes a binding between these user credentials, + the user's public component and the organization which vouches for + this binding. The resulting, signed, data item is called a + certificate. The organization identified as the certifying authority + for the certificate is the "issuer" of that certificate. The format + of the certificate is defined in X.509. + + In signing the certificate, the certification authority vouches for + the user's identification, in the context specified by the identity + of the issuer. Various types of organization may issue certificates, + including corporate, educational, professional, or governmental + entities. Moreover, these issuers may operate under different + certification policies, so that not all certificates may be equally + credible (i.e., some certificates may be more trustworthy as accurate + identifiers of users, organizations, mailing lists, etc). The PEM + certificate management design allows for this diversity of + certification policies, while ensuring that any certificate can be + traced unambiguously to the policy under which it was issued. + + The digital signature is affixed on behalf of that organization and + is in a form which can be recognized by all members of the privacy- + enhanced electronic mail community. This ability to universally + verify any PEM certificate results because the PEM certification + design is a singly rooted tree, in which the Internet Society acts as + the root. Once generated, certificates can be stored in directory + servers, transmitted via unsecure message exchanges, or distributed + via any other means that make certificates easily accessible to + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 14] + +RFC 1430 X.500 Strategy February 1993 + + + message originators, without regard for the security of the + transmission medium. + +8.2 Directory Security + + A number of security services are possible with the directory: + + Peer Authentication at Bind + Authentication (one or two way) between DUA/DSA and DSA/DSA, + established during the bind operation. This authentication may be + provided using simple passwords (not recommended), one-way hashed + passwords (more secure), or via public key cryptography (most + secure). The various authentication options are specified in + X.500(88), but most existent implementations implement only simple + password authentication. + + Per-operation Authentication and Integrity + This is usually used to identify the DUA originating an operation + to the Directory (e.g., to authenticate prior to data + modification). It may also be used to verify the identity of the + DSA which provided data in a response to the user. In both + examples, the integrity of the data also is ensured through the + use of digital signatures. This is specified in X.500(88), but not + yet widely implemented. + + Single Entry Access Control + This is used to control which users (DUAs) can access and modify + data within an entry. This is specified in X.500(92) and most DSA + implementations provide this function. + + Multiple Entry Access Control + This is used to control search and list operations, in order to + allow location of information by searching, but to deter + "trawling" of information and organizational structure. Usually, + these access controls are limited in their ability to prevent + trawling because of the conflicting goal of allowing a certain + level of legitimate browsing in support of "white pages" + functionality. + + Service Authorization + This allows DSAs to control service in a data independent manner, + based on peer authentication. For example, one might prevent + students from making non-local queries, while permitting such + queries by faculty and staff. + + + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 15] + +RFC 1430 X.500 Strategy February 1993 + + + Security Policy + This term encompasses the security goals for which data access + control, service authorization, and authentication mechanisms are + used to implement. For example, a local security policy might + require that all directory database modifications employ strong + authentication and originate from a computer at a known (local) + location. + + Data Confidentiality + The directory does not include explicit features to protect the + confidentiality of data while in transit (e.g., between a DUA and + DSA or between DSAs). Instead, it is assured that lower layer + security protocols or other local security facilities will be + employed to provide this security service. Ongoing work on + adaptation of the Network Layer Security Protocol (NLSP) is a + candidate for provision of this security service with directories. + + There is no specification of any Internet-wide security policy for + directories, nor are there currently any security mechanisms required + of all directories. Deployment of a directory could be based on a + variety of policies: + + - Read only system, containing only public data and restricted to + local modification. + + - Use of X.509 authentication, and private access control mechanisms + (this will not allow open access control management, but this is not + seen as a fundamental problem). + + It will be important to understand if global Internet requirements + for minimum essential directory security mechanisms will be required + to promote widespread use of directories. We recommend that an + informational RFC be written to analyze this issue, with an + operational policy guidelines or applicability statement RFC to + follow. + +9. RELATION TO DNS + + It is important to establish the relationship between the proposed + Internet Directory, and the existing Domain Name System. An + Experimental Protocol RFC (RFC 1279) proposes a mapping of DNS + information onto the Directory. Experiments should be conducted in + this area [HK91e]. + +10. EXTERNAL CONNECTIONS + + It will be important for this activity to maintain suitable external + liaisons. In particular to: + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 16] + +RFC 1430 X.500 Strategy February 1993 + + + Other Directory Services and Directory Pilots + + To ensure a service which is coherent with other groups building + X.500 services. e.g.,: + + - Paradise + - NADF + - FOX + - PSI White Pages + + Standards Bodies + + To feed back experience gained from this activity, so that the + next round of standards meets as many of the Internet requirements + as possible. e.g.,: + + - CCITT/ISO + - RARE WG-NAS + - EWOS/OIW + - ETSI + +11. REFERENCES + + + [BHK91a] Barker, P., and S. Hardcastle-Kille, "The COSINE and + Internet X.500 Schema", RFC 1274, Department of Computer + Science, University College London, November 1991. + + [BHK92] Barker, P., and S. Hardcastle-Kille, "Naming Guidelines for + Directory Pilots", RFC 1384, Department of Computer Science, + University College London, ISODE Consortium, January 1993. + + [CCI88a] The Directory --- authentication framework, December 1988. + CCITT Recommendation X.509. + + [CCI88b] The Directory --- overview of concepts, models and services, + December 1988. CCITT X.500 Series Recommendations. + + [CCI90] The Directory --- part 9 --- replication, October 1990. + ISO/IEC CD 9594-9 Ottawa output. + + [CFSD90] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A + Simple Network Management Protocol", STD 15, RFC 1157, + SNMP Research, Performance Systems International, MIT + Laboratory for Computer Science, May 1990. + + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 17] + +RFC 1430 X.500 Strategy February 1993 + + + [For91] The North American Directory Forum, "A Naming Scheme + for C=US", RFC 1255, NADF, September 1991. + Also NADF-175. (See also RFC 1417.) + + [For92] The North American directory Forum, "User Bill of Rights + for Entries and Listing in the Public Directory", RFC 1295, + NADF, January 1992. (See also RFC 1417.) + + [HK91a] Hardcastle-Kille, S., "Encoding network addresses to + support operation over non-OSI lower layers", RFC 1277, + Department of Computer Science, University College London, + November 1991. + + [HK91b] Hardcastle-Kille, S., "Replication and distributed + operations extensions to provide an internet directory + using X.500", RFC 1276, Department of Computer Science, + University College London, November 1991. + + [HK91c] Hardcastle-Kille, S., "Replication requirement to + provide an internet directory using X.500", RFC 1275, + Department of Computer Science, University College + London, November 1991. + + [HK91d] Hardcastle-Kille, S., "A string encoding of presentation + address", RFC 1278, Department of Computer Science, + University College London, November 1991. + + [HK91e] Hardcastle-Kille, S., "X.500 and domains", RFC 1279, + Department of Computer Science, University College + London, November 1991. + + [HK92a] Hardcastle-Kille, S., "A string representation of + Distinguished Names", Department of Computer Science, + University College London, Work in Progress. + + [HK92b] Hardcastle-Kille, S., "Using the OSI directory to achieve + user friendly naming", Department of Computer Science, + University College London, Work in Progress. + + [HSB91] Howes, R., Smith, M., and B. Beecher, "DIXIE Protocol + Specification", RFC 1249, University of Michigan, + July 1991. + + [ISO] Procedures for the operation of OSI registration + authorities --- part 1: general procedures. ISO/IEC 9834-1. + + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 18] + +RFC 1430 X.500 Strategy February 1993 + + + [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic + Mail: Part II - Certificate-based Key Management, RFC 1422, + BBN, February 1993. + + [Kil88] Kille, S., "The QUIPU Directory Service", In IFIP WG 6.5 + Conference on Message Handling Systems and Distributed + Applications, pages 173--186. North Holland Publishing, + October 1988. + + [Kil89] Kille, S., "The THORN and RARE Naming Architecture", + Technical report, Department of Computer Science, + University College London, June 1989. THORN Report UCL-64 + (version 2). + + [Lin93] Linn, J., "Privacy Enhancement for Internet Electronic + Mail: Part I - Message Encryption and Authentication + Procedures", RFC 1421, February 1993. + + [LW91] Lang, R., and R. Wright, "A Catalog of Available X.500 + Implementations", FYI 11, RFC 1292, SRI International, + Lawrence Berkeley Laboratory, January 1992. + + [Lyn91] Lynch, C., "The Z39.50 information retrieval protocol: An + overview and status report", Computer Communication Review, + 21(1):58--70, January 1991. + + [Par91] Paradise International Report, Cosine. Paradise project, + Department of Computer Science, University College London. + November 1991. + + [RC87] Rose, M., and D. Cass, "ISO Transport Services on + top of the TCP", STD 35, RFC 1006, Northrop Corporation + Technology Center, May 1987. + + [Ros91] Rose, M., "Directory Assistance Service", RFC 1202, + Performance Systems International, February 1991. + + [WR92] Weider, C., and J. Reynolds, "Executive Introduction to + Directory Services Using the X.500 Protocol", FYI 13, + RFC 1308, ANS, ISI, March 1992. + +12. Security Considerations + + Security issues are discussed in Section 8. + + + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 19] + +RFC 1430 X.500 Strategy February 1993 + + +13. Authors' Addresses + + Steve Hardcastle-Kille + ISODE Consortium + PO box 505 + SW11 1DX London + England + Phone: +44-71-223-4062 + EMail: S.Kille@isode.com + + + Erik Huizer + SURFnet bv + PO box 19035 + 3501 DA Utrecht + The Netherlands + Phone: +31-30 310290 + Email: Erik.Huizer@SURFnet.nl + + + Vinton Cerf + Corporation for National Research Initiatives + 1895 Preston White Drive, Suite 100 + Reston, VA 22091 + Phone: (703) 620-8990 + EMail: vcerf@cnri.reston.va.us + + + Russ Hobby + University of California, Davis + Computing Services + Surge II Room 1400 + Davis, CA 95616 + Phone: (916) 752-0236 + EMail: rdhobby@ucdavis.edu + + + Steve Kent + Bolt, Beranek, and Newman + 50 Moulton Street + Cambridge, MA 02138 + Phone: (617) 873-3988 + EMail: skent@bbn.com + + + + + + + + +Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 20] + \ No newline at end of file diff --git a/doc/rfc/rfc1617.txt b/doc/rfc/rfc1617.txt new file mode 100644 index 0000000000..ce57779844 --- /dev/null +++ b/doc/rfc/rfc1617.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group P. Barker +Request for Comments: 1617 University College London +RARE Technical Report: 11 S. Kille +Obsoletes: 1384 ISODE Consortium +Category: Informational T. Lenggenhager + SWITCH + May 1994 + + + Naming and Structuring Guidelines for X.500 Directory Pilots + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + Deployment of a Directory will benefit from following certain + guidelines. This document defines a number of naming and structuring + guidelines focused on White Pages usage. Alignment to these + guidelines is recommended for directory pilots. The final version of + this document will replace RFC 1384. + +Table of Contents + + 1. Introduction 2 + 2. DIT Structure 3 + 2.1. Structure Rules 3 + 2.2. The Top Level of the DIT 3 + 2.3. Countries 4 + 2.4. Organisations 5 + 2.4.1. Directory Manager, Postmaster & Secretary 5 + 2.4.2. Depth of tree 6 + 2.4.3. Real World Organisational Structure 7 + 2.5. Multi-National Organisations 7 + 2.5.1. The Multi-National as a Single Entity 7 + 2.5.2. The Multi-National as a Loose Confederation 8 + 2.5.3. Loosely Linked DIT Sub-Trees 9 + 2.5.4. Summary of Advantages and Disadvantages of the + Above Approaches 9 + 3. Naming Style 10 + 3.1. Multi-Component Relative Distinguished Names 11 + 3.2. National Guidelines for Naming 11 + 3.3. Naming Organisation and Organisational Unit Names 11 + 3.4. Naming Human Users 12 + 3.5. Application Entities 13 + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 1] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 4. Attribute Values 13 + 4.1. Basic Attribute Syntaxes 13 + 4.1.1. Printable String 14 + 4.1.2. IA5 String - T.50 14 + 4.1.3. Teletex String - T.61 14 + 4.1.4. Case Ignore String 14 + 4.1.5. Distinguished Name 14 + 4.2. Languages & Transliteration 14 + 4.2.1. Languages other than English 15 + 4.2.2. Transliteration 15 + 4.3. Access control 15 + 4.4. Selected Attributes 16 + 4.4.1. Personal Attributes 16 + 4.4.2. Organisational Attributes 18 + 4.4.3. Local Attributes 19 + 4.4.4. Miscellaneous Attributes 20 + 4.4.5. MHS Attributes 21 + 4.4.6. Postal Attributes 21 + 4.4.7. Telecom Attributes 22 + 5. Miscellany 22 + 5.1. Schema consistency of aliases 22 + 5.2. Organisational Units 23 + 6. References 23 + 7. Security Considerations 23 + 8. Authors' Addresses 24 + 9. Appendix - Example Entries 25 + +1. Introduction + + The intended audience for this document are mainly data managers + using X.500 Directory Services. With the help of these guidelines it + should be easier for them to define the structure for the part of the + Directory Information Tree they want to model, e.g., the + representation of their organisation in the Directory. In addition, + decisions like which data elements to store for each kind of entry + shall be supported. + + These guidelines concentrate mainly on the White Pages use of the + Directory, the X.500 application with most operational experience + today, nonetheless many recommendations are also valid for other + applications of the Directory. + + As a pre-requisite to this document, it is assumed that the COSINE + and Internet X.500 Schema is followed [1]. + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 2] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +2. DIT Structure + + The majority of this document is concerned with DIT structure, naming + and the usage of attributes for organisations, organisational units + and personal entries. + + This section briefly notes five other key issues. + +2.1 Structure Rules + + A DIT structure is suggested in Annex B of X.521 [2], and it is + recommended that Directory Pilots for White Pages services should + follow these guidelines. Some simple restrictions should be applied, + as described below. For further usage of the Directory like e-mail + routing with the Directory or storage of network information in the + Directory it will be necessary to follow the guidelines specified in + the respective documents. + + One of the few exceptions to the basic DIT structure is, that + international organisations will be stored immediately under the root + of the tree. Multi-national organisations will be stored within the + framework outlined, but with some use of aliases and attributes such + as seeAlso to help bind together the constituent parts of these + organisations. This is discussed in more detail in section 2.5. + + A general rule for the depth of a subtree is as follows: When a + subtree is mainly accessed via searching, it should be as flat as + possible to improve the performance, when the access will be mainly + through read operations, the depth of the subtree is not a + significant parameter for performance. + +2.2 The Top Level of the DIT + + The following information will be present at the top level of the + DIT: + + Participating Countries + + According to the standard the RDN is the ISO 3166 country code. In + addition, the entries should contain suitable values of the + friendlyCountryName attribute specified in RFC 1274. Use of this + attribute is described in more detail in section 4.4.4. + + International Organisations + + An international organisation is an organisation, such as the + United Nations, which inherently has a brief and scope covering + many nations. Such organisations might be considered to be + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 3] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + supra-national and this, indeed, is the raison-d'etre of such + organisations. Such organisations will almost all be governmental + or quasi-governmental. A multi-national organisation is an + organisation which operates in more than one country, but is not + supra-national. This classification includes the large commercial + organisations whose production and sales are spread throughout a + large number of countries. + + International organisations may be registered at the top level. + This will not be done for multi-national organisations. Currently + three organisations are registered so far: Inmarsat, Internet and + North Atlantic Treaty Organization. + + Localities + + A few localities will be registered under the root. The chief + purpose of these locality entries is to provide a "natural" parent + node for organisations which are supra-national, and yet which do + not have global authority in their particular field. Such + organisations will usually be governmental or quasi-governmental. + Example localities might include: Europe, Africa, West Indies. + Example organisations within Europe might include: European Court + of Justice, European Space Agency, European Commission. + + DSA Information + + Some information on DSAs may be needed at the top level. This + should be kept to a minimum. + + The only directory information for which there is a recognised top + level registration authority is countries. Registration of other + information at the top level may potentially cause problems. At this + stage, it is argued that the benefit of limiting additional top level + registrations outweighs these problems. However, this potential + problem should be noted by anyone making use of such a registration. + +2.3 Countries + + The national standardisation bodies will define national guidelines + for the structure of the national part of the DIT. In the interim, + the following simple structure should suffice. The country entry will + appear immediately beneath the root of the tree. Organisations which + have national significance should have entries immediately beneath + their respective country entries. Smaller organisations which are + only known in a particular locality should be placed underneath + locality entries representing states or similar geographical + divisions. Entry for private persons will be listed under the + locality entries. An example plan evolving for the US is the work of + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 4] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + the North American Directory Forum [3]. Another example is the + organisation of the X.500 namespace as standardized in Australia [4]. + +2.4 Organisations + + Large organisations will probably need to be sub-divided by + organisational units to help in the disambiguation of entries for + people with common names. Entries for people and roles will be stored + beneath organisations or organisational units. + + The organisation entry itself shall contain the information necessary + to contact the organisation: for example, postal address, telephone + and fax numbers. + + Although the structure of organisations often changes considerably + over time, the aim should be to minimise the number of changes to the + DIT. Note that renaming a superior, department entry has the effect + of changing the DN of all subordinate entries. This has an + undesirable impact on the service for several reasons. Alias entries + and certain attributes or ordinary entries such as seeAlso, secretary + and roleOccupant use DNs to maintain links with other entries. These + references are one-way only and the Directory standard offers no + support to automatically update all references to an entry once its + DN changes. + +2.4.1 Directory Manager, Postmaster & Secretary + + Similar to messaging, where every domain has its postmaster address + it is highly recommended that each organisation in the X.500 + Directory has two entries: Postmaster and Directory Manager. In + addition, Secretary entries for an organisation and its units should + be listed. If this guidance is followed, users will benefit because + it will be straightforward to find the right contacts for questions + or problems with the service. + + These entries should use the object class organizationalRole with the + roleOccupant attributes containing the distinguished names of the + persons in charge of this role. The values + + CN=Directory Manager + + CN=Postmaster + + CN=Secretary + + should be added as additional values whenever another language than + English is used for the name of the entries. + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 5] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +2.4.2 Depth of tree + + The broad recommendation for White Pages is that the DIT should be as + flat as possible. A flat tree means that Directory names will be + relatively short, and probably somewhat similar in length and + component structure to paper mail addresses. A deep DIT would imply + long Directory names, with somewhat arbitrary component parts, with a + result which it is argued seems less natural. Any artificiality in + the choice of names militates against successful querying. + + A presumption behind this style of naming is that most querying will + be supported by the user specifying convenient strings of characters + which will be mapped onto powerful search operations. The + alternative approach of the user browsing their way down the tree and + selecting names from large numbers of possibilities may be more + appropriate in some cases, and a deeper tree facilitates this. + However, these guidelines recommend a shallow tree, and implicitly a + search oriented approach. + + It may be considered that there are two determinants of DIT depth: + first, how far down the DIT an organisation is placed; second, the + structure of the DIT within organisations. + + The structure of the upper levels of the tree will be determined in + due course by various registration authorities, and the pilot will + have to work within the given structure. However, it is important + that the various pilots are cognisant of what the structures are + likely to be, and move early to adopt these structures. + + The other principal determinant of DIT depth is whether an + organisation splits its entries over a number of organisational + units, and if so, the number of levels. The recommendation here is + that this sub-division of organisations is kept to a minimum. A + maximum of two levels of organisational unit should suffice even for + large organisations. Organisations with only a few tens or hundreds + of employees should strongly consider not using organisational units + at all. It is noted that there may be some problems with choice of + unique RDNs when using a flat DIT structure. Multi-component RDNs can + alleviate this problem: see section 3.1. The standard X.521 + recommends that an organizationalUnitName attribute can also be used + as a naming attribute to disambiguate entries [2]. Further + disambiguation may be achieved by the use of a personalTitle or + userId attribute in the RDN. + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 6] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +2.4.3 Real World Organisational Structure + + Another aspect on designing the DIT structure for an organisation is + the administrative structure within a company. Using the same + structure in the DIT might help in distributing maintenance authority + to the different units. Please note comments on the stability of the + DIT structure in section 2.4. + +2.5 Multi-National Organisations + + The standard says that only international organisations may be placed + under the root of the DIT. This implies that multi-national + organisations must be represented as a number of separate entries + underneath country or locality entries. This structure makes it more + awkward to use X.500 within a multi-national to provide an internal + organisational directory, as the data is now spread widely throughout + the DIT, rather than all being grouped within a single sub-tree. + + Many people have expressed the view that this restriction is a severe + limitation of X.500, and argue that the intentions of the standard + should be ignored in this respect. This note argues, though, that the + standard should be followed. + + No attempt to precisely define multinational organisation is essayed + here. Instead, the observation is made that the term is applied to a + variety of organisational structures, where an organisation operates + in more than one country. This suggests that a variety of DIT + structures may be appropriate to accommodate these different + organisational structures. This document suggests three approaches, + and notes some of the characteristics associated with each of these + approaches. + + Before considering the approaches, it is worth bearing in mind again + that a major aim in the choice of a DIT structure is to facilitate + querying, and that approaches which militate against this should be + avoided wherever possible. + +2.5.1 The Multi-National as a Single Entity + + In many cases, a multi-national organisation will operate with a + highly centralised structure. While the organisation may have large + operations in a number of countries, the organisation is strongly + controlled from the centre and the disparate parts of the + organisation exist only as limbs of the main organisation. In such a + situation, the model shown in figure 1 may be the best choice. + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 7] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + ROOT + + / | \ + / | \ + + C=GB C=FR C=US + + / | \ + / | \ + + O=MultiNat---->O=MultiNat<----O=MultiNat + + / | \ + / | \ + / | \ + + l=abc ou=def l=fgi + + ---> means "alias to" + + Figure 1: The multi-national as a single entity + + The organisation's entries all exist under a single sub-tree. The + organisational structure beneath the organisation entry should + reflect the perceived structure of the organisation, and so no + recommendations on this matter can be made here. To assist the person + querying the directory, alias entries should be created under all + countries where the organisation operates. + +2.5.2 The Multi-National as a Loose Confederation + + Another common model of organisational structure is that where a + multi-national consists of a number of national entities, which are + in large part independent of both sibling national entities, and of + any central entity. In such cases, the model shown in Figure 2 may be + a better choice. Organisational entries exist within each country, + and only that country's localities and organisational units appear + directly beneath the appropriate organisational entry. + + + + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 8] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + ROOT + + / | \ + / | \ + C=GB C=FR C=US + + / | \ + / | \ + O=MultiNat O=MultiNat O=MultiNat + + / | / | \ | \ + / | / | \ | \ + + L=FR L=GB<---L=GB | L=US--->L=US L=FR + \ | / + ------------------->L=FR<---------------- + + ---> means "alias to" + + Figure 2: The multi-national as a loose confederation + + Some binding together of the various parts of the organisation can be + achieved by the use of aliases for localities and organisational + units, and this can be done in a highly flexible fashion. In some + cases, the national view might not contain all branches of the + company, as illustrated in Figure 2. + +2.5.3 Loosely Linked DIT Sub-Trees + + A third approach is to avoid aliasing altogether, and to use the + looser binding provided by an attribute such as seeAlso. This + approach treats all parts of an organisation as essentially separate. + + A unified view of the organisation can only be achieved by user + interfaces choosing to follow the seeAlso links. This is a key + difference with aliasing, where decisions to follow links may be + specified within the protocol. (Note that it may be better to specify + another attribute for this purpose, as seeAlso is likely to be used + for a wide variety of purposes.) + +2.5.4 Summary of Advantages and Disadvantages of the Above Approaches + + Providing an internal directory + + All the above methods can be used to provide an internal + directory. In the first two cases, the linkage to other parts of + the organisation can be followed by the protocol and thus + organisation-wide searches can be achieved by single X.500 + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 9] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + operations. In the last case, interfaces would have to "know" to + follow the soft links indicated by the seeAlso attribute. + + Impact on naming + + In the single-entity model, all DNs within the organisation will + be under one country. It could be argued that this will often + result in rather "unnatural" naming. In the loose- confederation + model, DNs are more natural, although the need to disambiguate + between organisational units and localities on an international, + rather than just a national, basis may have some impact on the + choice of names. For example, it may be necessary to add in an + extra level of organisational unit or locality information. In the + loosely-linked model, there is no impact on naming at all. + + Views of the organisation + + The first method provides a unique view of the organisation. The + loose confederacy allows for a variety of views of the + organisation. The view from the centre of the organisation may + well be that all constituent organisations should be seen as part + of the main organisation, whereas other parts of the organisation + may only be interested in the organisation's centre and a few of + its sibling organisations. The third model gives an equally + flexible view of organisational structures. + + Lookup performance + + All methods should perform reasonably well, providing information + is either held within a single DSA or it is replicated to the + other DSAs. + +3. Naming Style + + The first goal of naming is to provide unique identifiers for + entries. Once this is achieved, the next major goal in naming entries + should be to facilitate querying of the Directory. In particular, + support for a naming structure which facilitates use of user friendly + naming [5] is desirable. Other considerations, such as accurately + reflecting the organisational structure of an organisation, should be + disregarded if this has an adverse effect on normal querying. Early + experience in the pilot has shown that a consistent approach to + structure and naming is an aid to querying using a wide range of user + interfaces, as interfaces are often optimised for DIT structures + which appear prevalent. In addition, the X.501 standard notes that + "RDNs are intended to be long-lived so that the users of the + Directory can store the distinguished names of objects..." and "It is + preferable that distinguished names of objects which humans have to + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 10] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + deal with be user-friendly." [2] + + Naming is dependent on a number of factors and these are now + considered in turn. + +3.1 Multi-Component Relative Distinguished Names + + According to the standard, relative distinguished names may have more + than one component selected from the set of the attributes of the + entry to be named. This is useful when there are, for example, two + "John Smiths" in one department. The use of multi-component relative + distinguished names allows one to avoid artificial naming values such + as "John Smith 1" or "John Smith-2". Attributes which could be used + as the additional naming attribute include: personalTitle, + roomNumber, telephoneNumber, and userId. + +3.2 National Guidelines for Naming + + Where naming is being done in a country which has established + guidelines for naming, these guidelines should in general be + followed. These guidelines might be based on an established + registration authority, or may make use of an existing registration + mechanism (e.g., company name registration). + + Where an organisation has a name which is nationally registered in an + existing registry, this name is likely to be appropriate for use in + the Directory, even in cases where there are no national guidelines. + +3.3 Naming Organisation and Organisational Unit Names + + The naming of organisations in the Directory will ultimately come + under the jurisdiction of official naming authorities. In the + interim, it is recommended that pilots and organisations follow these + guidelines. An organisation's RDN should usually be the full name of + the organisation, rather than just a set of initials. This means that + University College London should be preferred over UCL. An example + of the problems which a short name might cause is given by the + proposed registration of AA for the Automobile Association. This + seems reasonable at first glance, as the Automobile Association is + well known by this acronym. However, it seems less reasonable in a + broader perspective when you consider that organisations such as + Alcoholics Anonymous and American Airlines use the same acronym. + + Just as initials should usually be avoided for organisational RDNs, + so should formal names which, for example, exist only on official + charters and are not generally well known. There are two reasons for + this approach: + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 11] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 1. The names should be meaningful. + + 2. The names should uniquely identify the organisation, and be + a name which is unlikely to be challenged in an open + registration process. For example, UCL might well be + challenged by United Carriers Ltd. + + The same arguments on naming style can be applied with even greater + force to the choice of RDNs for organisational units. While + abbreviated names will be in common parlance within an organisation, + they will almost always be meaningless outside of that organisation. + While many people in academic computing habitually refer to CS when + thinking of Computer Science, CS may be given several different + interpretations. It could equally be interpreted as Computing + Services, Cognitive Science, Clinical Science or even Counselling + Services. + + For both organisations and organisational units, extra naming + information should be stored in the directory as alternative values + of the naming attribute. Thus, for University College London, UCL + should be stored as an alternative organizationName attribute value. + Similarly CS could be stored as an alternative organizationalUnitName + value for Computer Science and any of the other departments cited + earlier. In general, entries will be located by searching, and so it + is not essential to have RDNs which are either the most memorable or + guessable, although names should be recognisable. The need for users + not to type long names may be achieved by use of carefully selected + alternative values. + +3.4 Naming Human Users + + A reasonably consistent approach to naming people is particularly + critical as a large percentage of directory usage will be looking up + information about people. User interfaces will be better able to + assist users if entries have names conforming to a common format, or + small group of formats. It is suggested that the RDN should follow + such a format. Alternative values of the common name attribute should + be used to store extra naming information. It seems sensible to try + to ensure that the RDN commonName value is genuinely the most common + name for a person as it is likely that user interfaces may choose to + place greater weight on matches on the RDN than on matches on one of + the alternative names. + + The choice of RDN for humans will be influenced by cultural + considerations. In many countries the best choice will be of the form + familiar-first-name surname. Thus, Steve Kille is preferred as the + RDN choice for one of this document's co-authors, while Stephen E. + Kille is stored as an alternative commonName value. Pragmatic choices + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 12] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + will have to be made for other cultures. The common name attribute + should not be used to hold other attribute information such as + telephone numbers, room numbers, or local codes. Such information + should be stored within the appropriate attributes as defined in the + COSINE and Internet X.500 Schema. Section 3.1 on multi-component RDNs + shows how clashing names can be made unique. + + The choice of a naming strategy should not be made on the basis of + the possibilities of the currently available user interface + implementations. For example, it is inappropriate to use common names + of the form 'surname firstname' merely because a user interface + presents results in a more satisfactory order by so doing. Use the + best structure for human names, and fix the user interface! + + More details on the use of commonName in section 4.4.1. + +3.5 Application Entities + + The guidelines of X.521 should be followed, in that the application + entity should always be named relative to an Organisation or + Organisational Unit. The application process will often correspond to + a system or host. In this case, the application entities should be + named by Common Names which identify the service (e.g., "FTAM + Service"). In cases where there is no useful distinction between + application process and application entity, the application process + may be omitted (This is often done for DSAs in the current pilot). + +4. Attribute Values + + In general the attribute values should be used as documented in the + standards. Sometimes the standard is not very precise about which + attribute to use and how to represent a value. + + The following sections give recommendations how to use them in X.500 + pilot projects. + +4.1 Basic Attribute Syntaxes + + Every attribute type has a definition of the attribute syntaxes its + values may be use. Most attribute types make use the basic attribute + syntaxes only. + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 13] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +4.1.1 Printable String + + This most simple syntax uses a subset of characters from ISO 646 IRV. + + A-Z a-z 0-9 ' ( ) + + + , - . / : ? space + + Tab 1: Characters in PrintableString + +4.1.2 IA5 String - T.50 + + The International Alphabet No. 5 (IA5) is known from the X.400 + message handling service. It covers a wider range of characters than + the printable string. The international reference version of IA5 + offers the same set of characters as ISO 646 IRV. + +4.1.3 Teletex String - T.61 + + The Teletex character set is a very unusual one in the computing + environment because it uses mixed one and two octet character codes + which are more difficult to handle than single octet codes. Most of + the characters can be mapped to the more often supported 8-bit + character set standard ISO 8859-1 (ISO Latin-1). + +4.1.4 Case Ignore String + + Many attributes use this case insensitive syntax. It allows attribute + values to be represented using a mixture of upper and lower case + letters, as appropriate. Matching of attribute values, however, is + performed such that no significance is given to case. + +4.1.5 Distinguished Name + + A Distinguished Name should currently never contain a value in T.61 + string syntax because most users would not be able to view or type it + correctly by lack of appropriate hardware/software configuration. + Therefore, only the characters defined in printable string syntax + should be used as part of a RDN. The correct representation of the + name should be added as additional attribute value to match for + search operations. + +4.2 Languages & Transliteration + + The standard as available has no support at all for the use of + different languages in the Directory. It is e.g., not possible to add + a language qualifier to a description attribute nor is it possible to + use characters beyond the Teletex character set. + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 14] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +4.2.1 Languages other than English + + Many countries have more than one national language and a world-wide + Directory must be able to support non-English-speaking users. + + Until the standard provides a solution for this problem it is + possible to make use of multi-valued attributes to specify a value + not only in the local languages but also in English. + + In particular the friendlyCountryName, stateOrProvinceName and + localityName attributes should use the most often used translations + of its original value to increase the chance for successful searches + also for users with a foreign language. Other attributes like + description, organizationName and organizationalUnitName attributes + should provide multi-lingual values where appropriate. + + The drawback of this solution is, that the user interfaces present + much redundant information because they are not able to know the + language of the values and make an automatic selection. + + Note: The sequence of multi-valued attribute values in an entry + cannot be defined. It is always up to the DSA to decide on + which order to store them and return them as results, and + to the DUA to decide on which order to display them. + +4.2.2 Transliteration + + What measures can be taken to make sure all users are able to read an + attribute, when a value uses one of the special characters from the + T.61 character set? An interim solution is transliteration as used in + earlier days with the typewriters, where e.g., the German 'a' with + umlaut is written as 'ae'. Transliteration is not necessarily unique + since it is dependent on the language, English speakers transliterate + the 'a' with umlaut just to an 'a'. However, it is an improvement + over just using the T.61 value since it may not be possible to + display such a value at all. Whenever an attribute needs a character + not in PrintableString and the attribute syntax allows the use of the + T.61 character set, it is recommended that the attribute should be + supplied as multi-valued attribute both in T.61 string and in a + transliterated PrintableString notation. + +4.3 Access control + + An entry's object class attribute, and any attribute(s) used for + naming an entry are of special significance and may be considered to + be "structural". Any inability to access these attributes will often + militate against successful querying of the Directory. For example, + user interfaces typically limit the scope of their searches by + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 15] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + searching for entries of a particular type, where the type of entry + is indicated by its object class. Thus, unless the intention is to + bar public access to an entry or set of entries, the object class and + naming attributes should be publicly readable. + +4.4 Selected Attributes + + The section lists attributes together with a short description what + they should be used for and some examples. [6] The source of the + attributes is given in brackets. + + Note that due to national legal restrictions on privacy issues it + might be forbidden to use certain attributes or that the search on + them is restricted. [7] + +4.4.1 Personal Attributes + + commonName [X.520] + + It is proposed that pilots should ignore the standard's + recommendations on storing personal titles, and letters indicating + academic and professional qualifications within the commonName + attribute, as this overloads the commonName attribute. A + personalTitle attribute has already been specified in the COSINE + and Internet Schema, and another attribute could be specified for + information about qualifications. + + The choice of a name depends on the culture as discussed in + section 3.4. When a commonName is selected as (part of) a RDN the + most often used form of the name should be selected. A firstname + should never be supplied only as an initial (unless, of course, + the source data does not include forenames). It is very important + to have its full value in order to be able to distinguish between + two similar entries. Sets of initials should not be concatenated + into a single "word", but be separated by spaces and/or "." + characters. + + + Format: Firstname [Initials] Lastname + + Example: Steve Kille + + Stephen E. Kille + + S.E. Kille + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 16] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + The use of 'Lastname Firstname' is deprecated as explained in + section 3.4. + + favouriteDrink [RFC 1274] + + The intention of this attribute is that it provides at least one + benign attribute which any user can create or modify, given a + suitable user interface, without having the unfortunate impact on + the directory service that follows from modifying an attribute + such as an e-mail address or telephone number. + + Example: Pure Crystal Water + + organizationalStatus [RFC 1274] + + The Organisational Status attribute type specifies a category by + which a person is often referred to in an organisation. Examples + of usage in academia might include undergraduate student, + researcher, lecturer, etc. + + A Directory administrator should consider carefully the + distinctions between this and the title and description + attributes. + + Example: undergraduate student + + personalTitle [RFC 1274] + + The usually used titles, especially academic ones. Excessive use + should be avoided. + + Example: Prof. Dr. + + roomNumber [RFC 1274] + + The room where the person works, it will mostly be locally defined + how to write the room number, e.g., Building Floor Room. + + Example: HLW B12 + + secretary [RFC 1274] + + The secretary of the person. This is the Distinguished Name (DN) + of the secretary. + + Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 17] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + surname [X.520] + + Like with commonName it is a matter of culture what to use for + surname in case of a noble name, e.g., de Stefani, von Gunten. + + Example: Kille + + title [X.520] + + Title describing the position, job title or function of an + organisational person. + + Example: Manager - International Sales + + userId [RFC 1274] + + When an organisation has centrally managed user ids, it might make + sense to include it into the entry. It might also be used to form + a unique RDN for the person. + + Example: skille + + userPassword [X.520] + + The password of the entry which allows the modification of the + entry, provided that the access control permits it. The password + should not be the same as any system password, unless it is sure + that nobody can read it. With the current implementations this is + mostly not guaranteed. + + Example: 8kiu8z7e + +4.4.2 Organisational Attributes + + associatedDomain [RFC 1274] + + The Internet domain name for an organisation or one of its units. + + Example: isode.com + + businessCategory [X.520] + + Type of business an organisation, an organisational unit or + organisational person is involved in. The values could be chosen + from a thesaurus. + + Example: Software Development + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 18] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + organizationName [X.520] + + The name of the organisation. The value for the RDN should be + chosen according to section 3.3. Additional names like + abbreviations should be used for better search results. + + Example: Uni Lausanne + Universite de Lausanne + Universit\c2e Lausanne (with a T.61 encoded umlaut) + University of Lausanne + unil + + organizationalUnitName [X.520] + + The name of a part of the organisation. The value for the RDN + should be chosen according to section 3.3. Additional names like + abbreviations should be provided for better search results. + + Example: Institut fuer Angewandte Mathematik + Mathematik + iam + + roleOccupant [X.520] + + The person(s) in that role. This is the Distinguished Name of the + entry of the person(s). + + Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB + + searchGuide [X.520] + + The currently available DUAs make no use this attribute. It seems + that it is not powerful enough for real usage. Experience is + needed before being able to give recommendations on how to + configure it. + +4.4.3 Local Attributes + + localityName [X.520] + + Name of the place, village or town with values in local and other + languages as useful. + + Example: Bale + B\c3ale (with a T.61 encoded accented character) Basel + Basilea + Basle + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 19] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + stateOrProvinceName [X.520] + + Name of the canton, county, department, province or state with + values in local and other languages as useful. If official and + commonly used abbreviations exist for the states, they should be + supplied as additional values + + Example: Ticino + Tessin + TI + +4.4.4 Miscellaneous Attributes + + audio [RFC 1274] + + The audio attribute uses a u-law encoded sound file as used by the + "play" utility on a Sun 4. According to RFC 1274 it is an interim + format. It may be useful to listen to the pronunciation of a name + which is otherwise unknown. + + description [X.520] + + A short informal explanation of special interests of a person or + organisation. Overlap with businessCategory, organizationalStatus + and title should be avoided. + + Example: Networking, distributed systems, OSI, implementation. + + friendlyCountryName [RFC 1274] + + The friendlyCountryName attribute type specifies names of + countries in human readable format. Especially the country name as + used in the major languages should be included as additional + values to help foreign users. + + jpegPhoto [RFC 1488] [8] + + A colour or grayscale picture encoded according to JPEG File + Interchange Format (JFIF). Thanks to compression the size of the + pictures is moderate. For persons it may show a portrait, for + organisations the company logo or a map on how to get there. + + photo [RFC 1274] + + The photo attribute is a b/w G3 fax encoded picture of an object. + The size of the photo should be in a sensible relation to the + informational value of it. This attribute will be replaced by + jpegPhoto. + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 20] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + seeAlso [X.520] + + Reference to another closely related entry in the DIT, e.g., from + a room to the person using that room. It is the Distinguished Name + of the entry. + + Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB + +4.4.5 MHS Attributes + + mhsORAddresses [X.411] + + The attribute uses internally an ASN.1 structure. The string + notation used for display purposes is implementation dependent. + This attribute is especially useful for an integrated X.400 user + agent since it gets the address in a directly usable format. + + rfc822mailbox [RFC 1274] + + E-Mail address in RFC 822 notation + + Example: s.kille@isode.com + + textEncodedORAddress [RFC 1274] + + X.400 e-mail address in string notation. The F.401 notation should + be used. This attribute shall disappear once the majority of the + DUAs support the mhsORAddresses attribute. The advantage of the + latter attribute is, that a configurable DUA could adjust the + syntax to the one needed by the local mailer, where + textencodedORAddress is just a string which will mostly have a + different syntax than the mailer expects. + + Example: G=thomas; S=lenggenhager; OU1=gate; O=switch; \ + P=switch; A=arcom; C=ch; + +4.4.6 Postal Attributes + + postalAddress [X.520] + + The full postal address (but not including the name) in + international notation, with up to 6 lines with 30 characters + each. + + Example: SWITCH + Limmatquai 13 + CH-8001 Zurich + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 21] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + postalCode [X.520] + + The postalCode will be the same as used in the postalAddress (in + international notation). + + Example: CH-8001 + + streetAddress [X.520] + + It shall be the street where the person has its office. Mostly, it + will be the street part of the postalAddress. + + Example: Limmatquai 138 + +4.4.7 Telecom Attributes + + telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520] + + The phone number in the international notation according to CCITT + E.123. The separator '-' instead of space may be used according to + the local habit, it should be used consistently within a country. + + Format: "+" ["x" ] + Example: +41 1 268 1540 + + telexNumber [X.520] + + The telex number in the international notation + + Example: 817379, ch, ehhg + +5. Miscellany + + This section draws attention to two areas which frequently provoke + questions, and where it is felt that a consistent approach will be + useful. + +5.1 Schema consistency of aliases + + According to the letter of the standard, an alias may point at any + entry. It is beneficial for aliases to be 'schema consistent'. + + The following two checks should be made: + + 1. The Relative Distinguished Name of the alias should use an + attribute type normally used for naming entries of the + object class of the main entry. + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 22] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 2. If the entry (aliased object) were placed where the alias + is, there should be no schema violation. + +5.2 Organisational Units + + There is a problem that many organisations can be either + organisations or organisational units, dependent on the location in + the DIT (with aliases giving the alternate names). For example, an + organisation may be an independent national organisation and also an + organisational unit of a parent organisation. To achieve this, it is + important to allow an entry to be of both object class organisation + and of object class organisational unit. + +6. References + + [1] Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet + X.500 schema", RFC 1274, Department of Computer Science, + University College London, November 1991. + + [2] "The Directory --- Overview of concepts, models and services", + CCITT X.500 Series Recommendations, December 1988. + + [3] The North American Directory Forum. "A Naming Scheme for C=US", + RFC 1255, NADF-175, NADF, September 1991. + + [4] Michaelson, G., and M. Prior, "Naming Guidelines for the AARNet + X.500 Directory Service", RFC 1562, AEN-001, The University of + Queensland, The University of Adelaide, December 1993. + + [5] Hardcastle-Kille, S., "Using the OSI Directory to achieve user + friendly naming", RFC 1484, Department of Computer Science, + University College London, July 1993. + + [6] Barker, P., "Preparing data for inclusion in an X.500 Directory", + Research Note RN/92/41, Department of Computer Science, + University College London, May 1992. + + [7] Jeunink, E., and E. Huizer, "Directory Services and Privacy + Issues", RARE WG-DATMAN, TF-LEGAL, Work in Progress, May 1993. + + [8] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The X.500 + String Representation of Standard Attribute Syntaxes", RFC 1488, + University of Michigan, ISODE Consortium, Performance Systems + International, NeXor Ltd., July 1993. + +7. Security Considerations + + Security issues are not substantially discussed in this memo. + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 23] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +8. Authors' Addresses + + 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 + + DN: CN=Paul Barker, OU=Computer Science, O=University College + London, C=GB + + UFN: Paul Barker, Computer Science, UCL, GB + + + Steve Kille + ISODE Consortium + The Dome + The Square + Richmond TW9 1DT + England + + Phone: +44 81 332 9091 + EMail: s.kille@isode.com + + DN: CN=Steve Kille, O=ISODE Consortium, C=GB + + UFN: S. Kille, ISODE Consortium, GB + + + Thomas Lenggenhager + SWITCH + Limmatquai 138 + CH-8001 Zurich + Switzerland + + Phone: +41 1 268 1540 + EMail: lenggenhager@switch.ch + + DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH + + UFN: Thomas Lenggenhager, SWITCH, CH + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 24] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +9. Appendix - Example Entries + +9.1 Country + + DN: C=CH + + objectClass=top & country & domainRelatedObject & friendlyCountry + country=CH + associatedDomain=ch + friendlyCountryName=CH + friendlyCountryName=Confoederatio Helvetica + friendlyCountryName=Schweiz + friendlyCountryName=Suisse + friendlyCountryName=Svizzera + friendlyCountryName=Switzerland + +9.2 Organisation + + DN: O=SWITCH, C=CH + + objectClass=top & organization & mhsUser & domainRelatedObject + description=Swiss Academic and Research Network + organizationName=SWIss TeleCommunication system for Higher + education\and research + organizationName=Swiss Academic and Research Network + organizationName=SWITCH + localityName=Zuerich + localityName=Zurich + localityName={T.61}Z\c8urich + stateOrProvinceName=ZH + stateOrProvinceName=Zuerich + stateOrProvinceName=Zurich + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1515 + facsimileTelephoneNumber=+41 1 268 1568 + seeAlso=CN=Postmaster, O=SWITCH, C=CH + mhsORAddresses=S=postmaster, O=switch; P=switch; A=arcom; C=ch; + associatedDomain=switch.ch + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 25] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +9.3 Organisation Unit + + DN: OU=SWITCHdirectory, O=SWITCH, C=CH + + objectClass=top & organizationalUnit + description=The SWITCH X.500 pilot project + organizationalUnitName=SWITCHdirectory + localityName=Zurich + localityName=Zuerich + localityName={T.61}Z\c8urich + stateOrProvinceName=Zurich + stateOrProvinceName=Zuerich + stateOrProvinceName=ZH + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCHdirectory + SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1540 + facsimileTelephoneNumber=+41 1 268 1568 + +9.4 Organizational Role + + DN: CN=Directory Manager, O=SWITCH, C=CH + + objectClass=top & organizationalRole & mhsUser + commonName=Directory Manager + description=SWITCH Directory Managers + roleOccupant=CN=Martin Berli, O=SWITCH, C=CH + roleOccupant=CN=Thomas Lenggenhager, O=SWITCH, C=CH + localityName=Zuerich + localityName=Zurich + localityName={T.61}Z\c8urich + stateOrProvinceName=Zurich + stateOrProvinceName=Zuerich + stateOrProvinceName=ZH + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCHdirectory + SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1540 + facsimileTelephoneNumber=+41 1 268 1568 + mhsORAddresses=S=switchinfo; O=switch; P=switch; A=arcom; C=ch; + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 26] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + DN: CN=Postmaster, O=SWITCH, C=CH + + objectClass=top & organizationalRole & mhsUser + commonName=Postmaster + commonName=Helpdesk + roleOccupant=CN=Christoph Graf, O=SWITCH, C=CH + roleOccupant=CN=Felix Kugler, O=SWITCH, C=CH + roleOccupant=CN=Marcel Parodi, O=SWITCH, C=CH + roleOccupant=CN=Marcel Schneider, O=SWITCH, C=CH + telephoneNumber=+41 1 268 1520 + facsimileTelephoneNumber=+41 1 268 1568 + mhsORAddresses=S=postmaster; O=switch; P=switch; A=arcom; C=ch; + + DN: CN=Secretary, O=SWITCH, C=CH + + objectClass=top & organizationalRole & quipuObject + commonName=Secretary + roleOccupant=CN=Franziska Remund, O=SWITCH, C=CH + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 27] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +9.5 Person + + DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH + + objectClass=top & person & organizationalPerson & mhsUser & + pilotObject & newPilotPerson + commonName=Thomas Lenggenhager + commonName=T. Lenggenhager + surname=Lenggenhager + description=SWITCHinfo, Project Leader + localityName=Zuerich + localityName=Zurich + localityName={T.61}Z\c8urich + stateOrProvinceName=ZH + stateOrProvinceName=Zuerich + stateOrProvinceName=Zurich + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1540 + facsimileTelephoneNumber=+41 1 268 1568 + mhsORAddresses=S=lenggenhager; O=switch; P=switch; A=arcom; C=ch; + userPassword=secret + textEncodedORaddress={T.61}S=lenggenhager; O=switch; P=switch; \ + A=arcom; C=ch; + rfc822mailbox=lenggenhager@switch.ch + secretary=CN=Franziska Remund, O=SWITCH, C=CH + + + + + + + + + + + + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 28] + diff --git a/doc/rfc/rfc1781.txt b/doc/rfc/rfc1781.txt new file mode 100644 index 0000000000..864698edd7 --- /dev/null +++ b/doc/rfc/rfc1781.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group S. Kille +Request for Comments: 1781 ISODE Consortium +Obsoletes: 1484 March 1995 +Category: Standards Track + + + Using the OSI Directory to Achieve User Friendly Naming + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The OSI Directory has user friendly naming as a goal. A simple + minded usage of the directory does not achieve this. Two aspects not + achieved are: + + o A user oriented notation + + o Guessability + + This proposal sets out some conventions for representing names in a + friendly manner, and shows how this can be used to achieve really + friendly naming. This then leads to a specification of a standard + format for representing names, and to procedures to resolve them. + This leads to a specification which allows directory names to be + communicated between humans. The format in this specification is + identical to that defined in [5], and it is intended that these + specifications are compatible. + +Table of Contents + + 1. Why a notation is needed ................................... 2 + 2. The Notation ............................................... 3 + 3. Communicating Directory Names .............................. 7 + 4. Matching a purported name .................................. 9 + 4.1 Environment .......................................... 9 + 4.2 Matching ............................................. 10 + 4.3 Top Level ............................................ 12 + 4.4 Intermediate Level ................................... 13 + 4.5 Bottom Level ......................................... 14 + 5. Examples ................................................... 14 + 6. Support required from the standard ......................... 15 + + + +Kille [Page 1] + +RFC 1781 User Friendly Naming March 1995 + + + 7. Support of OSI Services .................................... 15 + 8. Experience ................................................. 16 + 9. Relationship to other work ................................. 17 + 10. Issues ..................................................... 19 + 11. References ................................................. 20 + 12. Security Considerations .................................... 21 + 13. Author's Address ........................................... 21 + A. Pseudo-code for the matching algorithm ..................... 22 + List of Figures + 1. Example usage of User Friendly Naming ................ 18 + 2. Matching Algorithm ................................... 22 + List of Tables + 1. Local environment for private DUA .................... 10 + 2. Local environment for US Public DUA .................. 11 + +1. Why a notation is needed + + Many OSI Applications make use of Distinguished Names (DN) as defined + in the OSI Directory [1]. The main reason for having a notation for + name format is to interact with a user interface. This specification + is coming dangerously close to the sin of standardising interfaces. + However, there are aspects of presentation which it is desirable to + standardise. + + It is important to have a common format to be able to conveniently + refer to names. This might be done to represent a directory name on + a business card or in an email message. There is a need for a format + to support human to human communication, which must be string based + (not ASN.1) and user oriented. + + In very many cases, a user will be required to input a name. This + notation is designed to allow this to happen in a uniform manner + across many user interfaces. The intention is that the name can just + be typed in. There should not be any need to engage in form filling + or complex dialogue. It should be possible to take the "human" + description given at the meeting, and use it directly. The means in + which this happens will become clear later. + + This approach uses the syntax defined in [5] for representing + distinguished names. By relaxing some of the constraints on this + specification, it is argued that a more user oriented specification + is produced. However, this syntax cannot be mapped algorithmically + onto a distinguished name without the use of a directory. + + This notation is targeted towards a general user oriented system, and + in particular to represent the names of humans. Other syntaxes may + be more appropriate for other uses of the directory. For example, + the OSF Syntax may be more appropriate for some system oriented uses. + + + +Kille [Page 2] + +RFC 1781 User Friendly Naming March 1995 + + + (The OSF Syntax uses "/" as a separator, and forms names in a manner + intended to resemble UNIX filenames). + + This notation is targeted towards names which follow a particular DIT + structure: organisationally oriented. This may make it + inappropriate for some types of application. There may be a + requirement to extend this notation to deal more cleanly with fully + geographical names. + + This approach effectively defines a definition of descriptive names + on top of the primitive names defined by the OSI Directory. + +2. The Notation + + The notation used in this specification is defined in [5]. This + notation defines an unambiguous representation of distinguished name, + and this specification is designed to be used in conjunction with + this format. Both specifications arise from the same piece of + research work [4]. Some examples of the specification are given + here. The author's User Friendly Name (UFN) might be written: + + Steve Kille, Computer Science, University College London, GB + + or + + S. Kille, Computer Science, University College London, GB + + This may be folded, perhaps to display in multi-column format. For + example: + + Steve Kille, + Computer Science, + University College London, + GB + + Another UFN might be: + + Christian Huitema, INRIA, FR + + or + James Hacker, + Basingstoke, + Widget Inc, + GB + + The final example shows quoting of a comma in an Organisation name: + + L. Eagle, "Sue, Grabbit and Runn", GB + + + +Kille [Page 3] + +RFC 1781 User Friendly Naming March 1995 + + + A purported name is what a user supplies to an interface for + resolution into one or more distinguished names. A system should + almost always store a name as a distinguished name. This will be + more efficient, and avoid problems with purported names which become + ambiguous when a new name appears. A user interface may display a + distinguished name, using the distinguished name notation. However, + it may display a purported name in cases where this will be more + pleasing to the user. Examples of this might be: + + o Omission of the higher components of the distinguished name are + not displayed (abbreviation). + + o Omission of attribute types, where the type is unlikely to be + needed to resolve ambiguity. + + The ways in which a purported name may vary from a distinguished name + are now described: + + Type Omission + + There are two cases of this. + + o Schema defaulting. In this case, although the type is not + present, a schema defaulting is used to deduce the type. The + first two types of schema defaulting may be used to deduce a + distinguished name without the use of the directory. The use + of schema defaulting may be useful to improve the performance + of UFN resolution. The types of schema defaulting are: + + -- Default Schema + + -- Context Dependent Default Schema + + -- Data Dependent Default Schema + + o Omission of the type to be resolved by searching. + + Default Schema + + The attribute type of an attribute may always be present. This may + be done to emphasise the type structure of a name. In some cases, + the typing may be omitted. This is done in a way so that in many + common cases, no attribute types are needed. The following type + hierarchy (schema) is assumed: + + + + + + + +Kille [Page 4] + +RFC 1781 User Friendly Naming March 1995 + + + Common Name, (((Organisational Unit)*, Organisation,) Country). + + Explicitly typed RDNs may be inserted into this hierarchy at any + point. The least significant component is always of type Common + Name. Other types follow the defined organisational hierarchy. + The following are equivalent: + + Filestore Access, Bells, Computer Science, + University College London, GB + + and + + CN=Filestore Access, OU=Bells, OU=Computer Science, + O=University College London, C=GB + + To interpet a distinguished name presented in this format, with some + or all of the attributes with the type not specified, the types are + derived according to the type hierarchy by the following algorithm: + + 1. If the first attribute type is not specified, it is + CommonName. + + 2. If the last attribute type is not specified, it is Country. + + 3. If there is no organisation explicitly specified, the last + attribute with type not specified is of type Organisation. + + 4. Any remaining attribute with type unspecified must be before + an Organisation or OrganisationalUnit attribute, and is of + type OrganisationalUnit. + + To take a distinguished name, and generate a name of this format with + attribute types omitted, the following steps are followed. + + 1. If the first attribute is of type CommonName, the type may be + omitted. + + 2. If the last attribute is of type Country, the type may be + omitted. + + 3. If the last attribute is of type Country, the last + Organisation attribute may have the type omitted. + + 4. All attributes of type OrganisationalUnit may have the type + omitted, unless they are after an Organisation attribute or + the first attribute is of type OrganisationalUnit. + + + + + +Kille [Page 5] + +RFC 1781 User Friendly Naming March 1995 + + + Context Dependent Default Schema + + The distinguished name notation defines a fixed schema for type + defaulting. It may be useful to have different defaults in different + contexts. For example, the defaulting convention may be applied in a + modified fashion to objects which are known not to be common name + objects. This will always be followed if the least significant + component is explicitly typed. In this case, the following hierarchy + is followed: + + ((Organisational Unit)*, Organisation,) Country + + Data Dependent Defaulting + + There are cases where it would be optimal + to default according to the data. For example, in: + + Einar Stefferud, Network Management Associates, CA, US + + It would be useful to default "CA" to type State. This might be done + by defaulting all two letter attributes under C=US to type State. + + General Defaulting + + A type may be omitted in cases where it does not follow a default + schema hierarchy, and then type variants can be explored by + searching. Thus a distinguished name could be represented by a + uniquely matching purported name. For example, + + James Hacker, + Basingstoke, + Widget Inc, + GB + + Would match the distinguished name: + + CN=James Hacker, + L=Basingstoke, + O=Widget Inc, + C=GB + + Abbreviation + + Some of the more significant components of the DN will be omitted, + and then defaulted in some way (e.g., relative to a local context). + For example: + + Steve Kille + + + +Kille [Page 6] + +RFC 1781 User Friendly Naming March 1995 + + + Could be interpreted in the context of an organisational default. + + Local Type Keywords + + Local values can be used to identify types, in addition to the + keywords defined in [5]. For example, "Organisation" may be + recognised as an alternative to "O". + + Component Omission + + An intermediate component of the name may be omitted. Typically this + will be an organisational unit. For example: + + Steve Kille, University College London, GB + + In some cases, this can be combined with abbreviation. For example: + + Steve Kille, University College London + + Approximation + + Approximate renditions or alternate values of one or + more of the components will be supplied. For example: + + Stephen Kille, CS, UCL, GB + + or + + Steve Keill, Comp Sci, Univarstiy College London, GB + + Friendly Country + + A "friendly country name" can be used instead of the ISO 3166 two + letter code. For example: UK; USA; France; Deutchland. + +3. Communicating Directory Names + + A goal of this standard is to provide a means of communicating + directory names. Two approaches are given, one defined in [5], and + the other here. A future version of these specifications may contain + only one of these approaches, or recommend use of one approach. The + approach can usually be distinguished implicitly, as types are + normally omitted in the UFN approach, and are always present in the + Distinguished Name approach. No recommendation is made here, but the + merits of each approach is given. + + + + + + +Kille [Page 7] + +RFC 1781 User Friendly Naming March 1995 + + + 1. Distinguished Name or DN. A representation of the distinguished + name, according to the specification of [5]. + + 2. User Friendly Name or UFN. A purported name, which is expected to + unambiguously resolve onto the distinguished name. + + When a UFN is communicated, a form which should efficiently and + unambiguously resolve onto a distinguished name should be chosen. + Thus it is reasonable to omit types, or to use alternate values which + will unambiguously identify the entry in question (e.g., by use of an + alternate value of the RDN attribute type). It is not reasonable to + use keys which are (or are likely to become) ambiguous. The approach + used should be implicit from the context, rather than wired into the + syntax. The terms "Directory Name" and "X.500 Name" should be used + to refer to a name which might be either a DN or UFN. An example of + appropriate usage of both forms is given in the Section which defines + the Author's location in Section 12. Advantages of communicating the + DN are: + + o The Distinguished Name is an unambiguous and stable reference to + the user. + + o The DN will be used efficiently by the directory to obtain + information. + + Advantages of communicating the UFN are: + + o Redundant type information can be omitted (e.g., "California", + rather than "State=California", where there is known to be no + ambiguity. + + o Alternate values can be used to identify a component. This might + be used to select a value which is meaningful to the recipient, or + to use a shorter form of the name. Often the uniqueness + requirements of registration will lead to long names, which users + will wish to avoid. + + o Levels of the hierarchy may be omitted. For example in a very + small organisation, where a level of hierarchy has been used to + represent company structure, and the person has a unique name + within the organisation. + + Where UFN form is used, it is important to specify an unambiguous + form. In some ways, this is analogous to writing a postal address. + There are many legal ways to write it. Care needs to be taken to + make the address unambiguous. + + + + + +Kille [Page 8] + +RFC 1781 User Friendly Naming March 1995 + + +4. Matching a purported name + + The following approach specifies a default algorithm to be used with + the User Friendly Naming approach. It is appropriate to modify this + algorithm, and future specifications may propose alternative + algorithms. Two simple algorithms are noted in passing, which may be + useful in some contexts: + + 1. Use type omission only, but otherwise require the value of the RDN + attribute to be present. + + 2. Require each RDN to be identified as in 1), or by an exact match + on an alternate value of the RDN attribute. + + These algorithms do not offer the flexibility of the default + algorithm proposed, but give many of the benefits of the approach in + a very simple manner. + + The major utility of the purported name is to provide the important + "user friendly" characteristic of guessability. A user will supply a + purported name to a user interface, and this will be resolved onto a + distinguished name. When a user supplies a purported name there is a + need to derive the DN. In most cases, it should be possible to derive + a single name from the purported name. In some cases, ambiguities + will arise and the user will be prompted to select from a multiple + matches. This should also be the case where a component of the name + did not "match very well". + + There is an assumption that the user will simply enter the name + correctly. The purported name variants are designed to make this + happen! There is no need for fancy window based interfaces or form + filling for many applications of the directory. Note that the fancy + interfaces still have a role for browsing, and for more complex + matching. This type of naming is to deal with cases where + information on a known user is desired and keyed on the user's name. + +4.1 Environment + + All matches occur in the context of a local environment. The local + environment defines a sequence of names of a non-leaf objects in the + DIT. This environment effectively defines a list of acceptable name + abbreviations where the DUA is employed. The environment should be + controllable by the individual user. It also defines an order in + which to operate. + + This list is defined in the context of the number of name components + supplied. This allows varying heuristics, depending on the + environment, to make the approach have the "right" behaviour. In + + + +Kille [Page 9] + +RFC 1781 User Friendly Naming March 1995 + + + most cases, the environment will start at a local point in the DIT, + and move upwards. Examples are given in Tables 1 and 2. Table 1 + shows an example for a typical local DUA, which has the following + characteristics: + + One component + + Assumed first to be a user in the department, then a user or + department within the university, then a national organisation, and + finally a country. + + Two components + + Most significant component is first assumed to be a national + organisation, then a department (this might be reversed in some + organisations), and finally a country. + + Three or more components + + The most significant component is first assumed to be a country, then + a national organisation, and finally a department. + +4.2 Matching + + A purported name will be supplied, usually with a small number of + components. This will be matched in the context of an environment. + Where there are multiple components to be matched, these should be + matched sequentially. If an unambiguous DN is determined, the match + continues as if the full DN had been supplied. For example, if + + +-----------+--------------------------------------+ + |Number of |Environment | + |Components | | + +-----------+--------------------------------------+ + |1 |Physics, University College London, GB| + | |University College London, GB | + | |GB | + +-----------+--------------------------------------+ + |2 |GB | + | |University College London, GB | + | |-- | + +-----------+--------------------------------------+ + |3+ |-- | + | |GB | + | |University College London, GB | + +-----------+--------------------------------------+ + + Table 1: Local environment for private DUA + + + +Kille [Page 10] + +RFC 1781 User Friendly Naming March 1995 + + + +------------+-----------+ + | Number of |Environment| + | Components | | + +------------+-----------+ + | 1,2 | US | + | | CA | + | | -- | + +------------+-----------+ + | 3+ | -- | + | | US | + | | CA | + +------------+-----------+ + + Table 2: Local environment for US Public DUA + + Stephen Kille, UCL + + is being matched in the context of environment GB, first UCL is + resolved to the distinguished name: + + University College London, GB + + Then the next component of the purported name is taken to determine + the final name. If there is an ambiguity (e.g., if UCL had made two + matches, both paths are explored to see if the ambiguity can be + resolved. Eventually a set of names will be passed back to the user. + + Each component of the environment is taken in turn. If the purported + name has more components than the maximum depth, the environment + element is skipped. The advantage of this will be seen in the + example given later. + + A match of a name is considered to have three levels: + + Exact A DN is specified exactly + + Good Initially, a match should be considered good if it is + unambiguous, and exactly matches an attribute value in the entry. + For human names, a looser metric is probably desirable (e.g., + S Kille should be a good match of S. Kille, S.E. Kille or Steve + Kille even if these are not explicit alternate values). + + Poor Any other substring or approximate match + + Following a match, the reference can be followed, or the user + prompted. If there are multiple matches, more than one path may be + followed. There is also a shift/reduce type of choice: should any + partial matches be followed or should the next element of the + + + +Kille [Page 11] + +RFC 1781 User Friendly Naming March 1995 + + + environment be tried. The following heuristics are suggested, which + may be modified in the light of experience. The overall aim is to + resolve cleanly specified names with a minimum of fuss, but give + sufficient user control to prevent undue searching and delay. + + 1. Always follow an exact match. + + 2. Follow all good matches if there are no exact matches. + + 3. If there are only poor matches, prompt the user. If the user + accepts one or more matches, they can be considered as good. If + all are rejected, this can be treated as no matches. + + 4. Automatically move to the next element of the environment if no + matches are found. + + When the final component is matched, a set of names will be + identified. If none are identified, proceed to the next environment + element. If the user rejects all of the names, processing of the + next environment element should be confirmed. + + The exact approach to matching will depend on the level of the tree + at which matching is being done. We can now consider how attributes + are matched at various levels of the DIT. + + There is an issue of approximate matching. Sometimes it helps, and + sometimes just returns many spurious matches. When a search is + requested, all relevant attributes should be returned, so that + distinguished and non-distinguished values can be looked at. This + will allow a distinction to be made between good and poor matches. + It is important that where, for example, an acronym exactly matches + an organisation, that the user is not prompted about other + organisations where it matches as a substring. + +4.3 Top Level + + In this case, a match is being done at the root of the DIT. Three + approaches are suggested, dependent on the length of supplied name. + All lead to a single level search of the top level of the DIT. + + Exactly 2 + + This is assumed to be a 3166 two letter country code, or an exact + match on a friendly country or organisation (e.g., UK or UN). Do + exact match on country and friendly country. + + + + + + +Kille [Page 12] + +RFC 1781 User Friendly Naming March 1995 + + + Greater than 2 + + Make an approximate and substring match on friendly country and + organisation. + +4.4 Intermediate Level + + Once the root level has been dealt with, intermediate levels will be + looking for organisational components (Organisation, Locality, Org + Unit). In some cases, private schema control will allow the system + to determine which is at the next level. In general this will not be + possible. In each case, make a substring and approximate match + search of one level. The choice depends on the base object used in + the search. + + 1. If DN has no Organisation or Locality, filter on Organisation and + Locality. + + 2. If DN has Org Unit, filter on Org Unit. + + 3. If DN has Organisation, filter on Locality and Org Unit. + + 4. If DN has Locality, filter on Organisation. + + These allow some optimisation, based on legal choices of schema. + Keeping filters short is usually desirable to improve performance. A + few examples of this, where a base object has been determined (either + by being the environment or by partial resolution of a purported + name), and the next element of a purported name is being considered. + This will generate a single level search. What varies is the types + being filtered against. If the DN is: + + University College London, GB + + The search should be for Org Unit or Locality. If the DN is: + + Organisation=UN + + the search should be for Org Unit or Locality. + + There may be some improvements with respect to very short keys. Not + making approximate or substring matches in these cases seems sensible + (It might be desirable to allow "*" as a part of the purported name + notation.) + + + + + + + +Kille [Page 13] + +RFC 1781 User Friendly Naming March 1995 + + +4.5 Bottom Level + + The "Bottom Level" is to deal with leaf entries in the DIT. This will + often be a person, but may also be a role, an application entity or + something else. + + The last component of a purported name may either reference a leaf or + non-leaf. For this reason, both should be tested for. As a + heuristic, if the base object for the search has two or more + components it should be tested first as a bottom level name and then + intermediate. Reverse this for shorter names. This optimises for + the (normal) case of non-leaves high up the tree and leaves low down + the tree. + + For bottom level names, make an approximate and substring match + against Common Name, Surname, and User ID. Where common name is + looked for, a full subtree search will be used when at the second + level of the DIT or lower, otherwise a single level search. + + For example, if I have resolved a purported name to the distinguished + name + + University College London, GB + + and have a single component Bloggs, this will generate a subtree + search. + +5. Examples + + This is all somewhat confusing, and a few examples are given. These + are all in the context of the environment shown in Table 1 on Page + 13. + + If "Joe Bloggs" is supplied, a subtree search of + + Physics, University College London, GB + + will be made, and the user prompted for "Joseph Z. Bloggs" as the + only possible match. + + If "Computer Science" is supplied, first + + Physics, University College London, GB + + will be searched, and the user will reject the approximate match of + "Colin Skin". Then a subtree search of + + University College London, GB + + + +Kille [Page 14] + +RFC 1781 User Friendly Naming March 1995 + + + will be made, looking for a person. Then a single level search will + be made looking for Org Unit, and + + Computer Science, University College London, GB + + will be returned without prompting (exact match). Supplying "Steve + Kille" will lead to a failed subtree search of + + Physics, University College London, GB + + and lead straight to a subtree search of + + University College London, GB + + This will lead to an exact value match, and so a single entry + returned without prompting. + + If "Andrew Findlay, Brunel" is supplied, the first element of the + environment will be skipped, single level search of "Brunel" under + "GB" will find: + + Brunel University, GB + + and a subtree search for "Andrew Findlay" initiated. This will yield + + Andrew Findlay, Computing and Media Services, Brunel University, GB + + Dr A J Findlay, Manufacturing and Engineering Systems, Brunel + University, GB + + and the user will be prompted with a choice. + + This approach shows how a simple format of this nature will "do the + right thing" in many cases. + +6. Support required from the standard + + Fortunately, all that is needed is there! It would be useful to have + "friendly country name" as a standard attribute. + +7. Support of OSI Services + + The major focus of this work has been to provide a mechanism for + identifying Organisations and Users. A related function is to + identify applications. Where the Application is identified by an AET + (Application Entity Title) with an RDN of Common Name, this + specification leads to a natural usage. For example, if a filestore + is named "gannet", then this could easily be identified by the name: + + + +Kille [Page 15] + +RFC 1781 User Friendly Naming March 1995 + + + Gannet, Computer Laboratory, Cambridge University, GB + + In normal usage, this might lead to access (using a purported name) + of: + + FTAM gannet,cambridge + + A second type of access is where the user identifies an Organisation + (Organisational Unit), and expects to obtain a default service. The + service is implied by the application, and should not require any + additional naming as far as the user is concerned. It is proposed + that this is supported by User Friendly Naming in the following way. + + 1. Determine that the purported name identifies a non-leaf object, + which is of object class Organisation or Organisational Unit or + Locality. + + 2. Perform a single level search for Application Entities which + support the required application contexts. This assumes that all + services which are supporting default access for the organisation + are registered at one level below (possibly by the use of + aliases), and that other services (specific machines or parts of + the organisation) are represented further down the tree. This + seems to be a reasonable layout, and its utility can be evaluated + by experiment. + +8. Experience + + An experimental implementation of this has been written by Colin + Robbins. The example in Figure 1 shows that it can be very effective + at locating known individuals with a minimum of effort. This code has + been deployed within the "FRED" interface of the PSI Pilot [9], and + within an prototype interface for managing distribution lists. The + user reaction has been favourable: + + Some issues have arisen from this experience: + + o Where there is more than one level of Organisational Unit, and the + user guesses one which is not immediately below the organisation, + the algorithm works badly. There does not appear to be an easy + fix for this. It is not clear if this is a serious deficiency. + + o Substring searching is currently done with leading and trailing + wildcards. As many implementations will not implement leading + wildcards efficiently, it may be preferable to only use trailing + wildcards. The effect of this on the algorithm needs to be + investigated. + + + + +Kille [Page 16] + +RFC 1781 User Friendly Naming March 1995 + + + Implementors of this specification are encouraged to investigate + variants of the basic algorithm. A final specification should depend + on experience with such variants. + +9. Relationship to other work + + Colin Robbin's work on the interface "Tom" and implementation of a + distribution list interface strongly influenced this specification + [6]. + + Some of the ideas used here originally came from a UK Proposal to the + ISO/CCITT Directory Group on "New Name Forms" [2]. This defined, and + showed how to implement, four different types of names: + + Typed and Ordered The current Distinguished Name is a restricted + example of this type of name. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 17] + +RFC 1781 User Friendly Naming March 1995 + + + -> t hales, csiro, australia + Found good match(es) for 'australia' + Found exact match(es) for 'csiro' + Please select from the following: + Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y + The following were matched... + Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU + + -> g michaelson, queensland, au + Found exact match(es) for 'au' + Please select from the following: + University of Queensland, AU [y/n] ? y + Axolotl, AU [y/n] ? n + Please select from the following: + George Michaelson, Prentice Computer Centre, University of + Queensland, AU + [y/n] ? y + Manager, University of Queensland, AU [y/n] ? n + The following were matched... + George Michaelson, Prentice Computer Centre, University of + Queensland, AU + + -> r needham, cambridge + Found good match(es) for 'cambridge' + Please select from the following: + Roger Needham, Computer Lab, Cambridge University [y/n] ? y + The following were matched... + Roger Needham, Computer Lab, Cambridge University + + -> kirstein + Found good match(es) for 'kirstein' + The following were matched... + Peter Kirstein + + + Figure 1: Example usage of User Friendly Naming + + Untyped and Ordered + + This is the type of name proposed here (with some extensions to allow + optional typing). It is seen as meeting the key user requirement of + disliking typed names, and is efficient to implement. + + Typed and Unordered + + This sort of name is proposed by others as the key basis for user + friendly naming. Neufeld shows how X.500 can be used to provide this + [7], and Peterson proposes the Profile system to provide this [8]. + + + +Kille [Page 18] + +RFC 1781 User Friendly Naming March 1995 + + + The author contends that whilst typed naming is interesting for some + types of searching (e.g., yellow page searching), it is less + desirable for naming objects. This is borne out by operational + experience with OSI Directories [3]. + + Untyped and Unordered + + Surprisingly this form of name can be supported quite easily. + However, a considerable gain in efficiency can be achieved by + requiring ordering. In practice, users can supply this easily. + Therefore, this type of name is not proposed. + +10. Issues + + The following issues are noted, which would need to be resolved + before this document is progressed as an Internet Standard. + + Potential Ambiguity + + Whilst the intention of the notation is to allow for specification of + alternate values, it inherently allows for ambiguous names to be + specified. It needs to be demonstrated that problems of this + characteristic are outweighed by other benefits of the notation. + + Utility + + Determine that the specification is being implemented and used. + + Performance + + Measurements on the performance implications of using this approach + should be made. + + Alogrithm + + The utility of the algorithm, and possible variants, should be + investigated. + + This format, and the procedures for resolving purported names, should + be evolved to an Internet Standard. The syntax can be expected to be + stable. In light of experience, the algorithm for resolving + purported names may be changed. + + + + + + + + + +Kille [Page 19] + +RFC 1781 User Friendly Naming March 1995 + + +11. References + + [1] The Directory --- overview of concepts, models and services, + 1993. CCITT X.500 Series Recommendations. + + [2] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ WG4/N797 + UK National Body Contribution to the Oslo Directory Meeting. + + [3] S.E. Kille. The THORN large scale pilot exercise. Computer + Networks and ISDN Systems, 16(1):143--145, January 1989. + + [4] S.E. Kille. Using the OSI directory to achieve user friendly + naming. Research Note RN/20/29, Department of Computer Science, + University College London, February 1990. + + [5] Kille, S., "A String Representation of Distinguished Names", RFC + 1779, ISODE Consortium, March 1995. + + [6] S.E. Kille and C.J. Robbins. The ISO development environment: + User's manual (version 7.0), July 1991. Volume 5: QUIPU. + + [7] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89 + Symposiun Communications Architectures and Protocols, pages 64-- + 71, September 1989. + + [8] L.L. Petersen. The profile naming service. ACM Transactions on + Computing Systems, 6(4):341--364, November 1988. + + [9] M.T. Rose. Realizing the White Pages using the OSI Directory + Service. Technical Report 90--05--10--1, Performance Systems + International, Inc., May 1990. + + + + + + + + + + + + + + + + + + + + +Kille [Page 20] + +RFC 1781 User Friendly Naming March 1995 + + +12. Security Considerations + + Security issues are not discussed in this memo. + +13. Author's Address + + Steve Kille + ISODE Consortium + The Dome + The Square + Richmond, Surrey + TW9 1DT + England + + Phone:+44-181-332-9091 + EMail: S.Kille@ISODE.COM + + DN: CN=Steve Kille, + O=ISODE Consortium, C=GB + + UFN: S. Kille, + ISODE Consortium, GB + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 21] + +RFC 1781 User Friendly Naming March 1995 + + +A. Pseudo-code for the matching algorithm + + The following pseudo-code is intended to clarify the matching + algorithm. The language uses ASN.1 data types, with flow control + "C"-like, but with keywords upper-cased. + +PurportedName ::= SEQUENCE OF String + -- simplication, as attribute types can optionally be + -- specified + + -- Each element of the Purported Name is a string + -- which has been parsed from the BNF + +Attribute ::= SEQUENCE { + type OBJECT IDENTIFIER, + value ANY } + +RDN ::= Attribute -- simplification, as can be multi-value + +DN ::= SEQUENCE OF RDN + +Environment ::= SEQUENCE OF DN + +EnvironmentList ::= SEQUENCE OF SEQUENCE { + lower-bound INTEGER, + upper-bound INTEGER, + environment Environment } + + +friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN +{ + -- Find correct environment + + IF length(el) == 0 THEN return(NULL); + + IF length(p) <= head(el).upper-bound + && length(p) >= head(el).lower-bound THEN + return envMatch (p, head(el).environment); + ELSE + return(friendlyMatch(p, tail(el)); +} + +envMatch(p: PurportedName; e: Environment): SET OF DN +{ + -- Check elements of environment + -- in the defined order + + matches: SET OF DN; + + + +Kille [Page 22] + +RFC 1781 User Friendly Naming March 1995 + + + IF length(e) == 0 THEN return(NULL); + + matches = purportedMatch(head(e).DN, p) + IF matches != NULL THEN + return(matches); + ELSE + return(envMatch(p, tail(e)); +} + + +purportedMatch(base: DN; p: PurportedName): SET OF DN +{ + s: String = head(p); + matches: SET OF DN = NULL; + + IF length(p) == 1 THEN + IF length(base) == 0 THEN + IF (matches = rootSearch(s)) != NULL THEN + return(matches); + ELSE return(leafSearch(base, s, one-level); + ELSE IF length(base) == 1 THEN + IF (matches = intSearch(base, s)) != NULL THEN + return(matches); + ELSE return(leafSearch(base, s, one-level); + ELSE + IF (matches = leafSearch(base, s, subtree)) != + NULL THEN return(matches); + ELSE return(intsearch(base, s); + + + IF length(base) == 0 THEN + FOR x IN rootSearch(s) DO + matches += (purportedMatch(x, tail(p)); + ELSE + FOR x IN intSearch(base, s) DO + matches += (purportedMatch(x, tail(p)); + return(matches); +} + + + + + + + + + + + + + +Kille [Page 23] + +RFC 1781 User Friendly Naming March 1995 + + +-- General. Might need to tighten the filter for short strings, +-- in order to stop being flooded. Alternatively, this could be +-- done if the loose search hits a size limit + +rootSearch(s: String): SET OF DN +{ + IF length(s) == 2 THEN + return(search(NULL, one-level, s, {CountryName, + FriendlyCountryName, OrganizationName}, + {exact}, {Country, Organisation})); + -- test exact match only + -- probably a country code + ELSE + return(search(NULL, one-level, s, {OrganizationName, + FriendlyCountryName}, {substring, approx}, + {Country, Organisation})); +} + + +intSearch( base: DN; s: String) +{ + IF present(base, OrgUnitName) THEN + return(search(base, one-level, s, {OrgUnitName}, + {substring, approx}, {OrgUnit})); + ELSE IF present(base, OrganisationName) THEN + return(search(base, one-level, s, {OrgUnitName, + LocalityName}, {substring, approx}, + {Organization, OrgUnit, Locality})); + ELSE IF present(base, LocalityName) THEN + return(search(base, one-level, s, {OrganisationName}, + {substring, approx}, {Locality}); + ELSE + return(search(base, one-level, s, {OrganisationName, + LocalityName}, {substring, approx}, + {Organisation, Locality})); +} + + +present(d: DN; t: AttributeType): BOOLEAN +{ + FOR x IN d DO + IF x.type == t THEN return(TRUE); + return(FALSE); +} + +SearchScope := ENUMERATED (base-object, one-level, subtree) + +leafSearch(base: DN; s: String; search-scope: SearchScope) + + + +Kille [Page 24] + +RFC 1781 User Friendly Naming March 1995 + + +{ + return(search(base, search-scope, s, {CommonName, Surname, + UserId}, {substring, approx})); +} + +search(base: DN; search-scope: SearchScope; s: string; + alist SET OF AttributeType; matchtypes SET OF MatchType + objectClasses SET OF ObjectClass OPTIONAL): SET OF DN +{ + -- mapped onto Directory Search, with OR conjunction + -- of filter items + + return dNSelect (s, search-results, alist); +} + +read(base: DN; alist SET OF AttributeType): SET OF Attribute; +{ + -- mapped onto Directory Read + -- Types repeated to deal with multiple values + -- This would be implemented by returning selected info + -- with the search operation +} + +dNSelect(s: String; dlist SET OF DN; + alist: SET OF AttributeType):16SET0OF DN +{ + exact, good: SET OF DN; + + FOR x IN dlist DO + IF last(DN).Value == s THEN + exact += x; + ELSE IF FOR y IN read(x, alist) DO + IF y.value == s THEN + good += x; + + IF exact != NULL THEN return(exact); + IF good != NULL THEN return(good); + return(userQuery(dlist)); +} + +userQuery(dlist SET OF DN): SET OF DN +{ + -- pass back up for manual checking + -- user can strip all matches to force progres.... +} + +head() -- return first element of list +tail() -- return list with first element removed + + + +Kille [Page 25] + +RFC 1781 User Friendly Naming March 1995 + + +length() -- return size of list +last() -- return last element of list + + Figure 2: Matching Algorithm + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 26] + diff --git a/doc/rfc/rfc1960.txt b/doc/rfc/rfc1960.txt new file mode 100644 index 0000000000..3166b1cd86 --- /dev/null +++ b/doc/rfc/rfc1960.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group T. Howes +Request for Comments: 1960 University of Michigan +Obsoletes: 1558 June 1996 +Category: Standards Track + + A String Representation of LDAP Search Filters + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Lightweight Directory Access Protocol (LDAP) [1] defines a + network representation of a search filter transmitted to an LDAP + server. Some applications may find it useful to have a common way of + representing these search filters in a human-readable form. This + document defines a human-readable string format for representing LDAP + search filters. + +2. LDAP Search Filter Definition + + An LDAP search filter is defined in [1] as follows: + + Filter ::= CHOICE { + and [0] SET OF Filter, + or [1] SET OF Filter, + not [2] Filter, + equalityMatch [3] AttributeValueAssertion, + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeType, + approxMatch [8] AttributeValueAssertion + } + + SubstringFilter ::= SEQUENCE { + type AttributeType, + SEQUENCE OF CHOICE { + initial [0] LDAPString, + any [1] LDAPString, + final [2] LDAPString + } + } + + + +Howes Standards Track [Page 1] + +RFC 1960 LDAP Search Filters June 1996 + + + AttributeValueAssertion ::= SEQUENCE { + attributeType AttributeType, + attributeValue AttributeValue + } + + AttributeType ::= LDAPString + + AttributeValue ::= OCTET STRING + + LDAPString ::= OCTET STRING + + where the LDAPString above is limited to the IA5 character set. The + AttributeType is a string representation of the attribute type name + and is defined in [1]. The AttributeValue OCTET STRING has the form + defined in [2]. The Filter is encoded for transmission over a + network using the Basic Encoding Rules defined in [3], with + simplifications described in [1]. + +3. String Search Filter Definition + + The string representation of an LDAP search filter is defined by the + following grammar. It uses a prefix format. + + ::= '(' ')' + ::= | | | + ::= '&' + ::= '|' + ::= '!' + ::= | + ::= | | + ::= + ::= | | | + ::= '=' + ::= '~=' + ::= '>=' + ::= '<=' + ::= '=*' + ::= '=' + ::= NULL | + ::= '*' + ::= NULL | '*' + ::= NULL | + + is a string representing an AttributeType, and has the format + defined in [1]. is a string representing an AttributeValue, + or part of one, and has the form defined in [2]. If a must + contain one of the characters '*' or '(' or ')', these characters + should be escaped by preceding them with the backslash '\' character. + + + +Howes Standards Track [Page 2] + +RFC 1960 LDAP Search Filters June 1996 + + + Note that although both the and productions can + produce the 'attr=*' construct, this construct is used only to denote + a presence filter. + +4. Examples + + This section gives a few examples of search filters written using + this notation. + + (cn=Babs Jensen) + (!(cn=Tim Howes)) + (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) + (o=univ*of*mich*) + +5. Security Considerations + + Security considerations are not discussed in this memo. + +6. Bibliography + + [1] Yeong, W., Howes, T., and S. Kille, "Lightweight + Directory Access Protocol", RFC 1777, March 1995. + + [2] Howes, R., Kille, S., Yeong, W., and C. Robbins, "The String + Representation of Standard Attribute Syntaxes", RFC 1778, + March 1995. + + [3] Specification of Basic Encoding Rules for Abstract Syntax + Notation One (ASN.1). CCITT Recommendation X.209, 1988. + +7. Author's Address + + Tim Howes + University of Michigan + ITD Research Systems + 535 W William St. + Ann Arbor, MI 48103-4943 + USA + + Phone: +1 313 747-4454 + EMail: tim@umich.edu + + + + + + + + + + +Howes Standards Track [Page 3] + diff --git a/doc/rfc/rfc2044.txt b/doc/rfc/rfc2044.txt new file mode 100644 index 0000000000..22e74522a4 --- /dev/null +++ b/doc/rfc/rfc2044.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group F. Yergeau +Request for Comments: 2044 Alis Technologies +Category: Informational October 1996 + + + UTF-8, a transformation format of Unicode and ISO 10646 + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly + define a 16 bit character set which encompasses most of the world's + writing systems. 16-bit characters, however, are not compatible with + many current applications and protocols, and this has led to the + development of a few so-called UCS transformation formats (UTF), each + with different characteristics. UTF-8, the object of this memo, has + the characteristic of preserving the full US-ASCII range: US-ASCII + characters are encoded in one octet having the usual US-ASCII value, + and any octet with such a value can only be an US-ASCII character. + This provides compatibility with file systems, parsers and other + software that rely on US-ASCII values but are transparent to other + values. + +1. Introduction + + The Unicode Standard, version 1.1 [UNICODE], and ISO/IEC 10646-1:1993 + [ISO-10646] jointly define a 16 bit character set, UCS-2, which + encompasses most of the world's writing systems. ISO 10646 further + defines a 31-bit character set, UCS-4, with currently no assignments + outside of the region corresponding to UCS-2 (the Basic Multilingual + Plane, BMP). The UCS-2 and UCS-4 encodings, however, are hard to use + in many current applications and protocols that assume 8 or even 7 + bit characters. Even newer systems able to deal with 16 bit + characters cannot process UCS-4 data. This situation has led to the + development of so-called UCS transformation formats (UTF), each with + different characteristics. + + UTF-1 has only historical interest, having been removed from ISO + 10646. UTF-7 has the quality of encoding the full Unicode repertoire + using only octets with the high-order bit clear (7 bit US-ASCII + values, [US-ASCII]), and is thus deemed a mail-safe encoding + ([RFC1642]). UTF-8, the object of this memo, uses all bits of an + octet, but has the quality of preserving the full US-ASCII range: + + + +Yergeau Informational [Page 1] + +RFC 2044 UTF-8 October 1996 + + + US-ASCII characters are encoded in one octet having the normal US- + ASCII value, and any octet with such a value can only stand for an + US-ASCII character, and nothing else. + + UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire + into a pair of UCS-2 values from a reserved range. UTF-16 impacts + UTF-8 in that UCS-2 values from the reserved range must be treated + specially in the UTF-8 transformation. + + UTF-8 encodes UCS-2 or UCS-4 characters as a varying number of + octets, where the number of octets, and the value of each, depend on + the integer value assigned to the character in ISO 10646. This + transformation format has the following characteristics (all values + are in hexadecimal): + + - Character values from 0000 0000 to 0000 007F (US-ASCII repertoire) + correspond to octets 00 to 7F (7 bit US-ASCII values). + + - US-ASCII values do not appear otherwise in a UTF-8 encoded charac- + ter stream. This provides compatibility with file systems or + other software (e.g. the printf() function in C libraries) that + parse based on US-ASCII values but are transparent to other val- + ues. + + - Round-trip conversion is easy between UTF-8 and either of UCS-4, + UCS-2 or Unicode. + + - The first octet of a multi-octet sequence indicates the number of + octets in the sequence. + + - Character boundaries are easily found from anywhere in an octet + stream. + + - The lexicographic sorting order of UCS-4 strings is preserved. Of + course this is of limited interest since the sort order is not + culturally valid in either case. + + - The octet values FE and FF never appear. + + UTF-8 was originally a project of the X/Open Joint + Internationalization Group XOJIG with the objective to specify a File + System Safe UCS Transformation Format [FSS-UTF] that is compatible + with UNIX systems, supporting multilingual text in a single encoding. + The original authors were Gary Miller, Greger Leijonhufvud and John + Entenmann. Later, Ken Thompson and Rob Pike did significant work for + the formal UTF-8. + + + + + +Yergeau Informational [Page 2] + +RFC 2044 UTF-8 October 1996 + + + A description can also be found in Unicode Technical Report #4 [UNI- + CODE]. The definitive reference, including provisions for UTF-16 + data within UTF-8, is Annex R of ISO/IEC 10646-1 [ISO-10646]. + +2. UTF-8 definition + + In UTF-8, characters are encoded using sequences of 1 to 6 octets. + The only octet of a "sequence" of one has the higher-order bit set to + 0, the remaining 7 bits being used to encode the character value. In + a sequence of n octets, n>1, the initial octet has the n higher-order + bits set to 1, followed by a bit set to 0. The remaining bit(s) of + that octet contain bits from the value of the character to be + encoded. The following octet(s) all have the higher-order bit set to + 1 and the following bit set to 0, leaving 6 bits in each to contain + bits from the character to be encoded. + + The table below summarizes the format of these different octet types. + The letter x indicates bits available for encoding bits of the UCS-4 + character value. + + UCS-4 range (hex.) UTF-8 octet sequence (binary) + 0000 0000-0000 007F 0xxxxxxx + 0000 0080-0000 07FF 110xxxxx 10xxxxxx + 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx + + 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx + 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx + 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx + + Encoding from UCS-4 to UTF-8 proceeds as follows: + + 1) Determine the number of octets required from the character value + and the first column of the table above. + + 2) Prepare the high-order bits of the octets as per the second column + of the table. + + 3) Fill in the bits marked x from the bits of the character value, + starting from the lower-order bits of the character value and + putting them first in the last octet of the sequence, then the + next to last, etc. until all x bits are filled in. + + + + + + + + + + +Yergeau Informational [Page 3] + +RFC 2044 UTF-8 October 1996 + + + The algorithm for encoding UCS-2 (or Unicode) to UTF-8 can be + obtained from the above, in principle, by simply extending each + UCS-2 character with two zero-valued octets. However, UCS-2 val- + ues between D800 and DFFF, being actually UCS-4 characters trans- + formed through UTF-16, need special treatment: the UTF-16 trans- + formation must be undone, yielding a UCS-4 character that is then + transformed as above. + + Decoding from UTF-8 to UCS-4 proceeds as follows: + + 1) Initialize the 4 octets of the UCS-4 character with all bits set + to 0. + + 2) Determine which bits encode the character value from the number of + octets in the sequence and the second column of the table above + (the bits marked x). + + 3) Distribute the bits from the sequence to the UCS-4 character, + first the lower-order bits from the last octet of the sequence and + proceeding to the left until no x bits are left. + + If the UTF-8 sequence is no more than three octets long, decoding + can proceed directly to UCS-2 (or equivalently Unicode). + + A more detailed algorithm and formulae can be found in [FSS_UTF], + [UNICODE] or Annex R to [ISO-10646]. + +3. Examples + + The Unicode sequence "A." (0041, 2262, 0391, + 002E) may be encoded as follows: + + 41 E2 89 A2 CE 91 2E + + The Unicode sequence "Hi Mom !" (0048, 0069, + 0020, 004D, 006F, 006D, 0020, 263A, 0021) may be encoded as follows: + + 48 69 20 4D 6F 6D 20 E2 98 BA 21 + + The Unicode sequence representing the Han characters for the Japanese + word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows: + + E6 97 A5 E6 9C AC E8 AA 9E + + + + + + + + +Yergeau Informational [Page 4] + +RFC 2044 UTF-8 October 1996 + + +MIME registrations + + This memo is meant to serve as the basis for registration of a MIME + character encoding (charset) as per [RFC1521]. The proposed charset + parameter value is "UTF-8". This string would label media types + containing text consisting of characters from the repertoire of ISO + 10646-1 encoded to a sequence of octets using the encoding scheme + outlined above. + +Security Considerations + + Security issues are not discussed in this memo. + +Acknowledgments + + The following have participated in the drafting and discussion of + this memo: + + James E. Agenbroad Andries Brouwer + Martin J. D|rst David Goldsmith + Edwin F. Hart Kent Karlsson + Markus Kuhn Michael Kung + Alain LaBonte Murray Sargent + Keld Simonsen Arnold Winkler + +Bibliography + + [FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm. + 22p. pbk. 172g. 4/95, X/Open Company Ltd., "File Sys- + tem Safe UCS Transformation Format (FSS_UTF)", X/Open + Preleminary Specification, Document Number P316. Also + published in Unicode Technical Report #4. + + [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Infor- + mation technology -- Universal Multiple-Octet Coded + Character Set (UCS) -- Part 1: Architecture and Basic + Multilingual Plane. UTF-8 is described in Annex R, + adopted but not yet published. UTF-16 is described in + Annex Q, adopted but not yet published. + + [RFC1521] Borenstein, N., and N. Freed, "MIME (Multipurpose + Internet Mail Extensions) Part One: Mechanisms for + Specifying and Describing the Format of Internet Mes- + sage Bodies", RFC 1521, Bellcore, Innosoft, September + 1993. + + [RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with + MIME", RFC 1641, Taligent inc., July 1994. + + + +Yergeau Informational [Page 5] + +RFC 2044 UTF-8 October 1996 + + + [RFC1642] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe + Transformation Format of Unicode", RFC 1642, + Taligent, Inc., July 1994. + + [UNICODE] The Unicode Consortium, "The Unicode Standard -- + Worldwide Character Encoding -- Version 1.0", Addison- + Wesley, Volume 1, 1991, Volume 2, 1992. UTF-8 is + described in Unicode Technical Report #4. + + [US-ASCII] Coded Character Set--7-bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + +Author's Address + + Francois Yergeau + Alis Technologies + 100, boul. Alexis-Nihon + Suite 600 + Montreal QC H4M 2P2 + Canada + + Tel: +1 (514) 747-2547 + Fax: +1 (514) 747-2561 + EMail: fyergeau@alis.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yergeau Informational [Page 6] + diff --git a/doc/rfc/rfc2164.txt b/doc/rfc/rfc2164.txt new file mode 100644 index 0000000000..21270d52ef --- /dev/null +++ b/doc/rfc/rfc2164.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group S. Kille +Request for Comments: 2164 Isode Ltd. +Obsoletes: 1838 January 1998 +Category: Standards Track + + + + Use of an X.500/LDAP directory to support MIXER address mapping + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +1 MIXER X.400/RFC 822 Mappings + + MIXER (RFC 2156) defines an algorithm for use of a set of global + mapping between X.400 and RFC 822 addresses [4]. This specification + defines how to represent and maintain these mappings (MIXER + Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP + directory. Mechanisms for representing OR Address and Domain + hierarchies within the DIT are defined in [5, 2]. These techniques + are used to define two independent subtrees in the DIT, which contain + the mapping information. The benefits of this approach are: + + 1. The mapping information is kept in a clearly defined area which + can be widely replicated in an efficient manner. The tree is + constrained to hold only information needed to support the + mapping. This is important as gateways need good access to the + entire mapping. + + 2. It facilitates migration from a table-based approach. + + 3. It handles the issues of "missing components" in a natural + manner. + + An alternative approach which is not taken is to locate the + information in the routing subtrees. The benefits of this + would be: + + + + + +Kille Standards Track [Page 1] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + + o It is the "natural" location, and will also help to + ensure correct administrative authority for a mapping + definition. + + o The tree will usually be accessed for routing, and so it + will be efficient for addresses which are being routed. + + This is not done, as the benefits of the approach proposed are + greater. + + MCGAMs are global. A MIXER gateway may use any set of MCGAMs. A key + use of the directory is to enable MIXER gateways to share MCGAMs and + to share the effort of maintaining and publishing MCGAMs. This + specification and MIXER also recognise that there is not a single + unique location for publication of all MCGAMs. This specification + allows for multiple sets of MCGAMs to be published. Each set of + MCGAMs is published under a single part of the directory. There are + four mappings, which are represented by two subtrees located under + any part of the DIT. For the examples the location defined below is + used: + + + OU=MIXER MCGAMs, O=Zydeco Plc, C=GB + + These subtree roots are of object class subtree, and use the + mechanism for representing subtrees defined in [1]. + + + X.400 to RFC 822 This table gives the equivalence mapping from X.400 + to RFC 822. There is an OR Address tree under this. An example + entry is: + + PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822, + OU=MIXER MCGAMs, O=Zydeco Plc, C=GB + + RFC 822 to X.400 There is a domain tree under this. This table holds + the equivalence mapping from RFC 822 to X.400, and the gateway + mapping defined in RFC 1327. An example entry is: + + DomainComponent=ISODE, DomainComponent=COM, + CN=RFC 822 to X.400, + OU=MIXER MCGAMs, O=Zydeco Plc, C=GB + + The values of the table mapping are defined by use of two new object + classes, as specified in Figure 1. The objects give pointers to the + mapped components. + + + + + +Kille Standards Track [Page 2] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + +2 Omitted Components + + In MIXER, it is possible to have omitted components in OR Addresses + on either side of the mapping. A mechanism to represent such omitted + components is defined in Figure 2. The attribute at-or-address- + component-type is set to the X.500 attribute type associated with the + omitted component (e.g., + + +rFC822ToX400Mapping OBJECT-CLASS ::= { + SUBCLASS OF {domain-component} + MAY CONTAIN { + associatedORAddress| + associatedX400Gateway} + ID oc-rfc822-to-x400-mapping} + +x400ToRFC822Mapping OBJECT-CLASS ::= { + SUBCLASS OF {top} + MAY CONTAIN { 10 + associatedDomain| + associatedInternetGateway} + ID oc-x400-to-rfc822-mapping} + +associatedORAddress ATTRIBUTE ::= { + SUBTYPE OF distinguishedName + SINGLE VALUE + ID at-associated-or-address} + + 20 +associatedX400Gateway ATTRIBUTE ::= { + SUBTYPE OF mhs-or-addresses + MULTI VALUE + ID at-associated-x400-gateway} + +associatedDomain ATTRIBUTE ::= { + SUBTYPE OF name + WITH SYNTAX caseIgnoreIA5String + SINGLE VALUE + ID at-associated-domain} 30 + +associatedInternetGateway ATTRIBUTE ::= { + SUBTYPE OF name + WITH SYNTAX caseIgnoreIA5String + MULTI VALUE + ID at-associated-internet-gateway} + + + Figure 1: Object Classes for MIXER mappings + + + +Kille Standards Track [Page 3] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + +omittedORAddressComponent OBJECT-CLASS ::= + SUBCLASS OF {top} + MUST Contain { + oRAddressComponentType + } + ID oc-omitted-or-address-component} + + +oRAddressComponentType ATTRIBUTE ::= { + SUBTYPE OF objectIdentifier 10 + SINGLE VALUE + ID at-or-address-component-type} + + Figure 2: Omitted OR Address Component + + + at-prmd-name). This mechanism is for use only within the X.400 to + RFC 822 subtree and for the at-associated-or-address attribute. + +3 Mapping from X.400 to RFC 822 + + As an example, consider the mapping from the OR Address: + + + P=Isode; A=Mailnet; C=FI + + This would be keyed by the directory entry: + + PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822, + OU=MIXER MCGAMs, O=Zydeco Plc, C=GB + + and return the mapping from the associatedDomain attribute, which + gives the domain which this OR address maps to. This attribute is + used to define authoritative mappings, which are placed in the open + community tree. The manager of an MCGAM shall make the appropriate + entry. + + The Internet gateway mapping defined in MIXER[4] is provided by the + associatedInternetGateway attribute. This value may identify + multiple possible associated gateways. This information is looked up + at the same time as mapped OR addresses. In effect, this provides a + fallback mapping, which is found if there is no equivalence mapping. + Because of the nature of the mapping an OR Address will map to either + a gateway or a domain, but not both. Thus, there shall never be both + + + + + + + +Kille Standards Track [Page 4] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + + an associatedDomain and associatedInternetGateway attribute present + in the same entry. Functionally, mapping takes place exactly + according to MIXER. The longest match is found by the following + algorithm. + + 1. Take the OR Address, and derive a directory name. This will be + the OR Address as far as the lowest OU. + + 2. Look up the entire name derived from the MIXER key in the in the + X.400 to RFC 822 subtree. This lookup will either succeed, or it + will fail and indicate the longest possible match, which can then + be looked up. + + 3. Check for an associatedDomain or associatedInternetGateway + attribute in the matched entry. + + The mapping can always be achieved with two lookups. Because of the + availability of aliases, some of the table mappings may be + simplified. In addition, the directory can support mapping from + addresses using the numeric country codes. + +4 Mapping from RFC 822 to X.400 + + There is an analogous structure for mappings in the reverse + direction. The domain hierarchy is represented in the DIT according + to RFC 1279. The domain: + + ISODE.COM + + Is represented in the DIT as: + + DomainComponent=ISODE, DomainComponent=COM, CN=RFC 822 to X.400, + OU=MIXER MCGAMs, O=Zydeco Plc, C=GB + + This has associated with it the attribute associatedORAddress encoded + as a distinguished name with a value: PRMD=Isode, ADMD=Mailnet, C=FI + + The X.400 gateway mapping defined in MIXER[4] is provided by the + associatedX400Gateway attribute. This value may identify multiple + possible associated gateways. This information is looked up at the + same time as mapped OR addresses. In effect, this provides a + fallback mapping, which is found if there is no equivalence mapping. + Because of the nature of the mapping a domain will map to either a + gateway or a domain, but not both. Thus, there shall never be both + an associatedX400Gateway and associatedORAddress attribute present in + the same entry. Functionally, mapping takes place exactly according + to MIXER. The longest match is found by the following algorithm. + + + + +Kille Standards Track [Page 5] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + + 1. Derive a directory name from the domain part of the RFC 822 + address. + + 2. Look up this name in the RFC 822 to X.400 subtree to find the + mapped value (either associatedORAddress or + associatedX400Gateway.). If the lookup fails, the error will + indicate the longest match, which can then be looked up. + + If associatedORAddress is found, this will define the mapped OR + Address. The mapping can always be achieved with two lookups. If an + associatedX400Gateway is present, the address in question will be + encoded as a domain defined attribute, relative to the OR Address + defined by this attribute. If multiple associatedX400Gateway + attributes are found, the MTA may select the one it chooses to use. + + Because of the availability of aliases, some of the table mappings + may be simplified. In addition, the directory can support mapping + from addresses using the numeric country codes. + +5 Gateway Selection of MCGAMs + + The directory information to support identification of MCGAMs is + given in Figure 3. A MIXER gateway simply identifies the an ordered + lists of MCGAM collections that it will use for lookup. These are + referenced by name. A gateway is not required to use any MCGAMs. + Where MCGAMs are accessed from multiple sources, it is recommended + that all of the sources be accessed in order to determine the MCGAM + which gives the + + +mixerGateway OBJECT-CLASS ::= + KIND auxiliary + SUBCLASS OF {mhs-message-transfer-agent} + MUST Contain { + mcgamTables + } + ID oc-mixer-gateway} + + +mcgamTables ATTRIBUTE ::= { 10 + WITH SYNTAX SEQUENCE OF DistinguishedName + SINGLE VALUE + ID at-mcgam-tables} + + Figure 3: Object Classes for MCGAM selection + + +best match. + + + +Kille Standards Track [Page 6] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + +6 Acknowledgements + + Acknowledgements for work on this document are given in [3]. + +References + + [1] Kille, S., "Representing tables and subtrees in the X.500 + directory", RFC 1837, August 1995. + + [2] Kille, S., "Representing the O/R Address hierarchy in the X.500 + directory information tree," RFC 1836, August 1995. + + [3] Kille, S., " X.400-MHS use of the X.500 directory to support + X.400-MHS routing," RFC 1801, June 1995. + + [4] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): + Mapping between X.400 and RFC 822/MIME," RFC 2156, January 1998. + + [5] Kille, S., Wahl, M., Grimsatd, A., Huber, R., and S. Sataluri, + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + +7 Security Considerations + + This document specifies a means by which the X.500/LDAP directory + service can direct the translation between X.400 and Internet mail + addresses. This can indirectly affect the routing of messages across + a gateway between X.400 and Internet Mail. A succesful attack on + this service could cause incorrect translation of an originator + address (thus "forging" the originator address), or incorrect + translation of a recipient address (thus directing the mail to an + unauthorized recipient, or making it appear to an authorized + recipient, that the message was intended for recipients other than + those chosen by the originator). When cryptographic authentication + is available for directory responses, clients shall employ those + mechanisms to verify the authenticity and integrity of those + responses. + + + + + + + + + + + + + + +Kille Standards Track [Page 7] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + +8 Author's Address + + Steve Kille + Isode Ltd. + The Dome + The Square + Richmond + TW9 1DT + England + + Phone: +44-181-332-9091 + Internet EMail: S.Kille@ISODE.COM + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille Standards Track [Page 8] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + +A Object Identifier Assignment + + +mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) + enterprises(1) isode-consortium (453) mhs-ds (7)} + +mapping OBJECT IDENTIFIER ::= {mhs-ds 4} + +oc OBJECT IDENTIFIER ::= {mapping 1} +at OBJECT IDENTIFIER ::= {mapping 2} + + +oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1} 10 +oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2} +oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3} +oc-mixer-gateway ::= {oc 4} + +at-associated-or-address OBJECT IDENTIFIER ::= {at 6} +at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3} +at-associated-domain OBJECT IDENTIFIER ::= {at 4} +at-or-address-component-type OBJECT IDENTIFIER ::= {at 7} +at-associated-internet-gateway OBJECT IDENTIFIER ::= {at 8} +at-mcgam-tables ::= {at 9} 20 + + + Figure 4: Object Identifier Assignment + + + + + + + + + + + + + + + + + + + + + + + + + +Kille Standards Track [Page 9] + +RFC 2164 X.500/LDAP Directory to Support MIXER January 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Kille Standards Track [Page 10] + diff --git a/doc/rfc/rfc2218.txt b/doc/rfc/rfc2218.txt new file mode 100644 index 0000000000..8fa67a9d5d --- /dev/null +++ b/doc/rfc/rfc2218.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group T. Genovese +Request for Comments: 2218 Microsoft +Category: Standards Track B. Jennings + Sandia National Laboratory + October 1997 + + + A Common Schema for the Internet White Pages Service + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This work is the result of the IETF Integrated Directory Services + (IDS) Working Group. The IDS Working Group proposes a standard + specification for a simple Internet White Pages service by defining a + common schema for use by the various White Pages servers. This + schema is independent of specific implementations of the White Pages + service. + + This document specifies the minimum set of core attributes of a White + Pages entry for an individual and describes how new objects with + those attributes can be defined and published. It does not describe + how to represent other objects in the White Pages service. Further, + it does not address the search sort expectations within a particular + service. + +1.0 Introduction to IWPS + + The Internet community has stated a need for the development and + deployment of a White Pages service for use in locating information + about people in the Internet [PA94]. To facilitate interoperability + and to provide a common user experience, the Internet White Pages + Service (IWPS) must have a common set of information about each + person. + + A common user object would allow a user to go between implementations + of the service and to expect consistency in the types of information + provided. A common user object would also provide developers with an + unambigious method of representing the information managed by the + service. + + + +Genovese & Jennings Standards Track [Page 1] + +RFC 2218 Common Schema for IWPS October 1997 + + + This document will focus only on common information modeling issues + to which all IWPS providers must conform. + +2.0 Scope + + This document establishes the set of attributes that specify the + Common User Information Object for the IWPS. It does not attempt to + be an exhaustive specification of all objects that may be stored in + the IWPS. The process used by this document to define the user object + is recommended to be used to define other information objects used in + the IWPS. + + All conforming implementations must support at the minimum, the core + attributes listed in Section 5.0. Implementations may include local + attributes in addition to the core set and still be considered "in + conformance". + + This document will not specify rules with respect to information + privacy. Each country has its own set of laws and practices. + Previous work covering this area has been done by the North American + Directory Forum (NADF), whose publication [NADF92] contain + recommendations for registrants' rights in both the USA and Canada. + + This document does not specify a Directory access protocol (i.e. + whois++, LDAP, DAP, etc.). + +3.0 IWPS Schema Considerations + + The description of the IWPS information object consists of the + following requirements: + + 1. Syntax for definition/representation of information + object templates. + 2. Publication of information object templates, etc. + 3. Database structure or schema. + + Items 1 and 2 will be covered in this document. Because database + structure can potentially restrict implementations (i.e. X.500 schema + based versus DNS schema based) it will be treated as a separate + research topic and will not be defined in this paper. + +4.0 Syntax for Definition/Representation of Information Object + Templates + + A clear, precise, and consistent method must be used when discussing + information object templates and their associated attributes. + Therefore, this document makes uses of the previously defined syntax + used by LDAP. To avoid restrictions on implementations of the IWPS, + + + +Genovese & Jennings Standards Track [Page 2] + +RFC 2218 Common Schema for IWPS October 1997 + + + some syntax are listed as requirements vs specific encodings. The + general IWPS syntax is included in section 6.0 for reference. + + The IWPS Person Object specifies a limited set of recommended + attributes that a White Pages Service must include. Storage of user + attributes are a local issue, therefore, this memo suggests storage + sizes but not storage types. + + This document lists the syntax with the attributes for developers of + user interface (UIs) to use as a reference, but it does not specify + how the UI should display these attributes. + + Attributes that contain multiple-line text (i.e. Address) must use + the procedure defined in RFC 822 in section 3.1.1 on "folding" long + header lines [RFC-822]. + +5.0 Information Object Template Definitions + + This section describes the IWPS Person Information Object Template + and its associated attributes. The Person Object is a simple list of + attributes, no structure nor object inheritance is implied. + + IWPS client applications should use the following size + recommendations as the maximum sizes of the attributes. However, + applications should be able to handle attributes of arbitrary size, + returned by a server which may not comply with these recommendation. + All size recommendations are in characters. + + Note: Because many characters in many encodings require more than one + byte, the size recommendations cannot be interpreted as sizes in + bytes. + + This set of attributes describes information types, and are not + defined attributes in a particular schema. Any technology deploying + a White Page service (WHOIS ++, LDAP, vCard, etc.) will need to + publish as a companion document, their specific schema detailing how + the general attributes of the White Pages schema are expressed. + + SPECIAL CONSIDERATIONS + + Phone number: The full international form is recommended; + i.e. +1 206 703 0852. The field may contain + additional information following the phone + number. For example: + + +1 800 759 7243 #123456 + +1 505 882 8080 ext. 30852 + + + + +Genovese & Jennings Standards Track [Page 3] + +RFC 2218 Common Schema for IWPS October 1997 + + + Email address: Is multivalued. + + Certificate: Is multivalued. + + Common Name: Is multivalued. + + Language Spoken: Is multivalued. + + THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON + + --General Attributes -- + + Field Name Size Syntax + + Email 360 Mailbox + Cert 4000 Certificate + Home Page 128 URI + Common Name 64 WhitepageString + Given Name 48 WhitepageString + Surname 48 WhitepageString + Organization 64 WhitepageString + Locality 20 WhitepageString + Country 2 WhitepageString (ISO 3166) + Language Spoken 128 WhitepageString (RFC 1766) + + --Personal Attributes + + Personal Phone 30 PrintableString + Personal Fax 30 PrintableString + Personal Mobile Phone 30 PrintableString + Personal Pager Number 30 PrintableString + Personal Postal Address 255 Address + Description 255 WhitepageString + + --Organizational Attributes + + Title 64 WhitepageString + Office Phone 30 PrintableString + Office Fax 30 PrintableString + Office Mobile Phone 30 PrintableString + Office Pager 30 PrintableString + Office Postal Address 255 Address + + --Ancillary + + Creation Date 24 GeneralizedTime + Creator Name 255 URI + Modified Date 24 GeneralizedTime + + + +Genovese & Jennings Standards Track [Page 4] + +RFC 2218 Common Schema for IWPS October 1997 + + + Modifier Name 255 URI + +6.0 IWPS Person Information Object Template Syntax + + This section defines the syntax used by the IWPS person information + object template. It is copied in whole from the LDAP attribute + working document with some modification for completeness. + + Certificate: + + The certificate field is intended to hold any kind of certificate; + X.509 certificates are one example. A specific implementation will + specify how to indicate the type of certificate when describing + the mapping of the IWPS schema onto the implementation schema. + + WhitepageString: + + This syntax must be able to encode arbitrary ISO 10646 characters. + One such encoding is the UTF-8 encoding [UTF-8]. + + GeneralizedTime: + + Values of this syntax are encoded as printable strings, + represented as specified in X.208. Note that the time zone must + be specified. It is strongly recommended that Zulu time zone be + used. For example: + + 199412161032Z + + Mailbox: + + here are many kinds of mailbox addresses, including X.400 and + Internet mailbox addresses. The implementation must clearly + distinguish between different types of mailbox address, for + instance by using a textual refix or a set of attribute types. + There must be a way to represent any mailbox type. + + Address: + + According to Universal Postal Union standards, this field must be + able to represent at least 6 lines of 40 characters. + + PrintableString: + + The encoding of a value with PrintableString syntax is the string + value itself. PrintableString is limited to the characters in + production

. Where production

is described by the + following: + + + +Genovese & Jennings Standards Track [Page 5] + +RFC 2218 Common Schema for IWPS October 1997 + + + ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | + 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | + 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | + 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | + 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | + 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' + + ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' + + +

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | + '/' | ':' | '?' | ' ' + +7.0 Publication of IWPS Information Object Templates. + + The Working Group recommends that all information object templates + used for the IWPS be published. + + Individual organizations may define information object templates that + are local in scope as required to meet local organizational needs. + All information that the organization wishes to be part of the IWPS + must use a published IWPS information object template. + +8.0 Data Privacy + + Each country, and each state within the US, has legislation defining + information privacy. The suggested attributes in Section 5.0 may be + considered private and the directory administrator is strongly + advised to verify the privacy legislation for his domain. + + As suggested in "Privacy and Accuracy in NIC Databases" [RFC-1355], + each directory provider should provide a clear statement of the + purpose of the directory, the information that should be contained in + it, and a privacy policy associated with that information. This + policy should include restrictions for data dissemination. + + This policy is strongly recommended for the US and Canada and + required by many countries in the European Community for data + sharing. + +9.0 Data Integrity + + Data Integrity was first addressed in RFC 1107 [KS89], which states + "a White Pages service will not be used, if the information it + provides is out of date or incorrect." Therefore, any production + IWPS provider must insure that all data is reasonably correct and + up-to-date. + + + + +Genovese & Jennings Standards Track [Page 6] + +RFC 2218 Common Schema for IWPS October 1997 + + + The Ancillary Attributes of the IWPS person template denote the + information's source and date of origin, and the source and date of + its latest modification. They provide the user with some measurement + of the quality of data making it easy to determine the owner and + freshness of the data retrieved. + + The IWPS User Agent must be able to retrieve and display Ancillary + Attributes. Retrieval and display may be done as separate + operations. + + The Ancillary Attributes are recommended as the minimum set of + attributes for any new information object template. Each IWPS server + may individually decide whether to support the storage and retrieval + of this data. + + The Ancillary Attributes (also defined in Section 5.0) provide the + following information about its associated information object: + + 1. The date and time the entry was created; Creation Date. + + 2. Owner or individual responsible for the data creation; + Creator Name. + + 3. The date and time of the last modification; + Modified Date. + + 4. Individual responsible for the last modification; + Modifier Name. + +10.0 Security Considerations + + Security is implementation and deployment specific and as such is not + addressed in this memo. Security must ensure that the constraints + mentioned in the Data Privacy Section 8.0 are complied with. + +11.0 References + + [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC + 1107, Laboratory for Computer Science, MIT, July 1989. + + [NADF92] North American Directory Forum, "User Bill of Rights for + entries and listings in the Public Directory', RFC 1295, + North American Directory Forum, January 1992. + + + + + + + + +Genovese & Jennings Standards Track [Page 7] + +RFC 2218 Common Schema for IWPS October 1997 + + + [PA94] Postel, J., and C. Anderson, "WHITE PAGES MEETING REPORT", + RFC 1588, University of Southern California, February 1994. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, August 1982. + + [RFC-1355] Curran, J., and A. Marine, "Privacy and Accuracy Issues + in Network Information Center Databases", FYI 15, RFC 1355, August + 1992. + + [UCS] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993. + + [RFC-1766] Alvestrand, H., "Tags for the Identification of + Languages", RFC 1766, March 1995. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", + Work in Progress. + +11.0 Authors' Addresses + + Tony Genovese + The Microsoft Corporation + One Microsoft Way + Redmond, Washington 98007 + USA + + Phone: (206) 703-0852 + EMail: TonyG@Microsoft.com + + + Barbara Jennings + Sandia National Laboratories + Albuquerque, New Mexico 87106 + USA + + Phone: (505) 845-8554 + EMail: jennings@sandia.gov + + + + + + + + + + + + + +Genovese & Jennings Standards Track [Page 8] + diff --git a/doc/rfc/rfc2247.txt b/doc/rfc/rfc2247.txt new file mode 100644 index 0000000000..be40b102ef --- /dev/null +++ b/doc/rfc/rfc2247.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group S. Kille +Request for Comments: 2247 Isode Ltd. +Category: Standards Track M. Wahl + Critical Angle Inc. + A. Grimstad + AT&T + R. Huber + AT&T + S. Sataluri + AT&T + January 1998 + + + + Using Domains in LDAP/X.500 Distinguished Names + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +1. Abstract + + The Lightweight Directory Access Protocol (LDAP) uses X.500- + compatible distinguished names [3] for providing unique + identification of entries. + + This document defines an algorithm by which a name registered with + the Internet Domain Name Service [2] can be represented as an LDAP + distinguished name. + +2. Background + + The Domain (Nameserver) System (DNS) provides a hierarchical resource + labeling system. A name is made up of an ordered set of components, + each of which are short strings. An example domain name with two + components would be "CRITICAL-ANGLE.COM". + + + + + + +Kille, et. al. Standards Track [Page 1] + +RFC 2247 Using Domains in LDAP/X.500 January 1998 + + + LDAP-based directories provide a more general hierarchical naming + framework. A primary difference in specification of distinguished + names from domain names is that each component of an distinguished + name has an explicit attribute type indication. + + X.500 does not mandate any particular naming structure. It does + contain suggested naming structures which are based on geographic and + national regions, however there is not currently an established + registration infrastructure in many regions which would be able to + assign or ensure uniqueness of names. + + The mechanism described in this document automatically provides an + enterprise a distinguished name for each domain name it has obtained + for use in the Internet. These distinguished names may be used to + identify objects in an LDAP directory. + + An example distinguished name represented in the LDAP string format + [3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most + significant component, closest to the root of the namespace, is + written last. + + This document does not define how to represent objects which do not + have domain names. Nor does this document define the procedure to + locate an enterprise's LDAP directory server, given their domain + name. Such procedures may be defined in future RFCs. + +3. Mapping Domain Names into Distinguished Names + + This section defines a subset of the possible distinguished name + structures for use in representing names allocated in the Internet + Domain Name System. It is possible to algorithmically transform any + Internet domain name into a distinguished name, and to convert these + distinguished names back into the original domain names. + + The algorithm for transforming a domain name is to begin with an + empty distinguished name (DN) and then attach Relative Distinguished + Names (RDNs) for each component of the domain, most significant (e.g. + rightmost) first. Each of these RDNs is a single + AttributeTypeAndValue, where the type is the attribute "DC" and the + value is an IA5 string containing the domain name component. + + Thus the domain name "CS.UCL.AC.UK" can be transformed into + + DC=CS,DC=UCL,DC=AC,DC=UK + + + + + + + +Kille, et. al. Standards Track [Page 2] + +RFC 2247 Using Domains in LDAP/X.500 January 1998 + + + Distinguished names in which there are one or more RDNs, all + containing only the attribute type DC, can be mapped back into domain + names. Note that this document does not define a domain name + equivalence for any other distinguished names. + +4. Attribute Type Definition + + The DC (short for domainComponent) attribute type is defined as + follows: + + ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) + + The value of this attribute is a string holding one component of a + domain name. The encoding of IA5String for use in LDAP is simply the + characters of the string itself. The equality matching rule is case + insensitive, as is today's DNS. + +5. Object Class Definitions + + An object with a name derived from its domain name using the + algorithm of section 3 is represented as an entry in the directory. + The "DC" attribute is present in the entry and used as the RDN. + + An attribute can only be present in an entry held by an LDAP server + when that attribute is permitted by the entry's object class. + + This section defines two object classes. The first, dcObject, is + intended to be used in entries for which there is an appropriate + structural object class. For example, if the domain represents a + particular organization, the entry would have as its structural + object class 'organization', and the 'dcObject' class would be an + auxiliary class. The second, domain, is a structural object class + used for entries in which no other information is being stored. The + domain object class is typically used for entries that are + placeholders or whose domains do not correspond to real-world + entities. + +5.1. The dcObject object class + + The dcObject object class permits the dc attribute to be present in + an entry. This object class is defined as auxiliary, as it would + typically be used in conjunction with an existing structural object + class, such as organization, organizationalUnit or locality. + + The following object class, along with the dc attribute, can be added + to any entry. + + + +Kille, et. al. Standards Track [Page 3] + +RFC 2247 Using Domains in LDAP/X.500 January 1998 + + + ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc ) + + An example entry would be: + + dn: dc=critical-angle,dc=com + objectClass: top + objectClass: organization + objectClass: dcObject + dc: critical-angle + o: Critical Angle Inc. + +5.2. The domain object class + + If the entry does not correspond to an organization, organizational + unit or other type of object for which an object class has been + defined, then the "domain" object class can be used. The "domain" + object class requires that the "DC" attribute be present, and permits + several other attributes to be present in the entry. + + The entry will have as its structural object class the "domain" + object class. + +( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL + MUST dc + MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ + x121Address $ registeredAddress $ destinationIndicator $ + preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ + telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ + street $ postOfficeBox $ postalCode $ postalAddress $ + physicalDeliveryOfficeName $ st $ l $ description $ o $ + associatedName ) ) + + The optional attributes of the domain class are used for describing + the object represented by this domain, and may also be useful when + searching. These attributes are already defined for use with LDAP + [4]. + + An example entry would be: + + dn: dc=tcp,dc=critical-angle,dc=com + objectClass: top + objectClass: domain + dc: tcp + description: a placeholder entry used with SRV records + + The DC attribute is used for naming entries of the domain class, and + this can be represented in X.500 servers by the following name form + rule. + + + +Kille, et. al. Standards Track [Page 4] + +RFC 2247 Using Domains in LDAP/X.500 January 1998 + + + ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) ) + +6. References + + [1] The Directory: Selected Attribute Types. ITU-T Recommendation + X.520, 1993. + + [2] Mockapetris, P., " Domain Names - Concepts and Facilities," + STD 13, RFC 1034, November 1987. + + [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol + (v3): UTF-8 String Representation of Distinguished Names", RFC + 2253, December 1997. + + [4] Wahl, M., "A Summary of the X.500(96) User Schema for use with + LDAP", RFC 2256, December 1997. + +7. Security Considerations + + This memo describes how attributes of objects may be discovered and + retrieved. Servers should ensure that an appropriate security policy + is maintained. + + An enterprise is not restricted in the information which it may store + in DNS or LDAP servers. A client which contacts an untrusted server + may have incorrect or misleading information returned (e.g. an + organization's server may claim to hold naming contexts representing + domain names which have not been delegated to that organization). + +8. Authors' Addresses + + Steve Kille + Isode Ltd. + The Dome + The Square + Richmond, Surrey + TW9 1DT + England + + Phone: +44-181-332-9091 + EMail: S.Kille@ISODE.COM + + + + + + + + + + +Kille, et. al. Standards Track [Page 5] + +RFC 2247 Using Domains in LDAP/X.500 January 1998 + + + Mark Wahl + Critical Angle Inc. + 4815 W. Braker Lane #502-385 + Austin, TX 78759 + USA + + Phone: (1) 512 372 3160 + EMail: M.Wahl@critical-angle.com + + + Al Grimstad + AT&T + Room 1C-429, 101 Crawfords Corner Road + Holmdel, NJ 07733-3030 + USA + + EMail: alg@att.com + + + Rick Huber + AT&T + Room 1B-433, 101 Crawfords Corner Road + Holmdel, NJ 07733-3030 + USA + + EMail: rvh@att.com + + + Sri Sataluri + AT&T + Room 4G-202, 101 Crawfords Corner Road + Holmdel, NJ 07733-3030 + USA + + EMail: sri@att.com + + + + + + + + + + + + + + + + +Kille, et. al. Standards Track [Page 6] + +RFC 2247 Using Domains in LDAP/X.500 January 1998 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Kille, et. al. Standards Track [Page 7] + diff --git a/doc/rfc/rfc2251.txt b/doc/rfc/rfc2251.txt new file mode 100644 index 0000000000..88844cbf38 --- /dev/null +++ b/doc/rfc/rfc2251.txt @@ -0,0 +1,2803 @@ + + + + + + +Network Working Group M. Wahl +Request for Comments: 2251 Critical Angle Inc. +Category: Standards Track T. Howes + Netscape Communications Corp. + S. Kille + Isode Limited + December 1997 + + + Lightweight Directory Access Protocol (v3) + +1. Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +IESG Note + + This document describes a directory access protocol that provides + both read and update access. Update access requires secure + authentication, but this document does not mandate implementation of + any satisfactory authentication mechanisms. + + In accordance with RFC 2026, section 4.4.1, this specification is + being approved by IESG as a Proposed Standard despite this + limitation, for the following reasons: + + a. to encourage implementation and interoperability testing of + these protocols (with or without update access) before they + are deployed, and + + b. to encourage deployment and use of these protocols in read-only + applications. (e.g. applications where LDAPv3 is used as + a query language for directories which are updated by some + secure mechanism other than LDAP), and + + c. to avoid delaying the advancement and deployment of other Internet + standards-track protocols which require the ability to query, but + not update, LDAPv3 directory servers. + + + + + +Wahl, et. al. Standards Track [Page 1] + +RFC 2251 LDAPv3 December 1997 + + + Readers are hereby warned that until mandatory authentication + mechanisms are standardized, clients and servers written according to + this specification which make use of update functionality are + UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION + IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. + + Implementors are hereby discouraged from deploying LDAPv3 clients or + servers which implement the update functionality, until a Proposed + Standard for mandatory authentication in LDAPv3 has been approved and + published as an RFC. + +Table of Contents + + 1. Status of this Memo .................................... 1 + Copyright Notice ....................................... 1 + IESG Note .............................................. 1 + 2. Abstract ............................................... 3 + 3. Models ................................................. 4 + 3.1. Protocol Model ........................................ 4 + 3.2. Data Model ............................................ 5 + 3.2.1. Attributes of Entries ............................... 5 + 3.2.2. Subschema Entries and Subentries .................... 7 + 3.3. Relationship to X.500 ................................. 8 + 3.4. Server-specific Data Requirements ..................... 8 + 4. Elements of Protocol ................................... 9 + 4.1. Common Elements ....................................... 9 + 4.1.1. Message Envelope .................................... 9 + 4.1.1.1. Message ID ........................................ 11 + 4.1.2. String Types ........................................ 11 + 4.1.3. Distinguished Name and Relative Distinguished Name .. 11 + 4.1.4. Attribute Type ...................................... 12 + 4.1.5. Attribute Description ............................... 13 + 4.1.5.1. Binary Option ..................................... 14 + 4.1.6. Attribute Value ..................................... 14 + 4.1.7. Attribute Value Assertion ........................... 15 + 4.1.8. Attribute ........................................... 15 + 4.1.9. Matching Rule Identifier ............................ 15 + 4.1.10. Result Message ..................................... 16 + 4.1.11. Referral ........................................... 18 + 4.1.12. Controls ........................................... 19 + 4.2. Bind Operation ........................................ 20 + 4.2.1. Sequencing of the Bind Request ...................... 21 + 4.2.2. Authentication and Other Security Services .......... 22 + 4.2.3. Bind Response ....................................... 23 + 4.3. Unbind Operation ...................................... 24 + 4.4. Unsolicited Notification .............................. 24 + 4.4.1. Notice of Disconnection ............................. 24 + 4.5. Search Operation ...................................... 25 + + + +Wahl, et. al. Standards Track [Page 2] + +RFC 2251 LDAPv3 December 1997 + + + 4.5.1. Search Request ...................................... 25 + 4.5.2. Search Result ....................................... 29 + 4.5.3. Continuation References in the Search Result ........ 31 + 4.5.3.1. Example ........................................... 31 + 4.6. Modify Operation ...................................... 32 + 4.7. Add Operation ......................................... 34 + 4.8. Delete Operation ...................................... 35 + 4.9. Modify DN Operation ................................... 36 + 4.10. Compare Operation .................................... 37 + 4.11. Abandon Operation .................................... 38 + 4.12. Extended Operation ................................... 38 + 5. Protocol Element Encodings and Transfer ................ 39 + 5.1. Mapping Onto BER-based Transport Services ............. 39 + 5.2. Transfer Protocols .................................... 40 + 5.2.1. Transmission Control Protocol (TCP) ................. 40 + 6. Implementation Guidelines .............................. 40 + 6.1. Server Implementations ................................ 40 + 6.2. Client Implementations ................................ 40 + 7. Security Considerations ................................ 41 + 8. Acknowledgements ....................................... 41 + 9. Bibliography ........................................... 41 + 10. Authors' Addresses ..................................... 42 + Appendix A - Complete ASN.1 Definition ..................... 44 + Full Copyright Statement ................................... 50 + +2. Abstract + + The protocol described in this document is designed to provide access + to directories supporting the X.500 models, while not incurring the + resource requirements of the X.500 Directory Access Protocol (DAP). + This protocol is specifically targeted at management applications and + browser applications that provide read/write interactive access to + directories. When used with a directory supporting the X.500 + protocols, it is intended to be a complement to the X.500 DAP. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document + are to be interpreted as described in RFC 2119 [10]. + + Key aspects of this version of LDAP are: + + - All protocol elements of LDAPv2 (RFC 1777) are supported. The + protocol is carried directly over TCP or other transport, bypassing + much of the session/presentation overhead of X.500 DAP. + + - Most protocol data elements can be encoded as ordinary strings + (e.g., Distinguished Names). + + + + +Wahl, et. al. Standards Track [Page 3] + +RFC 2251 LDAPv3 December 1997 + + + - Referrals to other servers may be returned. + + - SASL mechanisms may be used with LDAP to provide association + security services. + + - Attribute values and Distinguished Names have been + internationalized through the use of the ISO 10646 character set. + + - The protocol can be extended to support new operations, and + controls may be used to extend existing operations. + + - Schema is published in the directory for use by clients. + +3. Models + + Interest in X.500 [1] directory technologies in the Internet has led + to efforts to reduce the high cost of entry associated with use of + these technologies. This document continues the efforts to define + directory protocol alternatives, updating the LDAP [2] protocol + specification. + +3.1. Protocol Model + + The general model adopted by this protocol is one of clients + performing protocol operations against servers. In this model, a + client transmits a protocol request describing the operation to be + performed to a server. The server is then responsible for performing + the necessary operation(s) in the directory. Upon completion of the + operation(s), the server returns a response containing any results or + errors to the requesting client. + + In keeping with the goal of easing the costs associated with use of + the directory, it is an objective of this protocol to minimize the + complexity of clients so as to facilitate widespread deployment of + applications capable of using the directory. + + Note that although servers are required to return responses whenever + such responses are defined in the protocol, there is no requirement + for synchronous behavior on the part of either clients or servers. + Requests and responses for multiple operations may be exchanged + between a client and server in any order, provided the client + eventually receives a response for every request that requires one. + + In LDAP versions 1 and 2, no provision was made for protocol servers + returning referrals to clients. However, for improved performance + and distribution this version of the protocol permits servers to + return to clients referrals to other servers. This allows servers to + offload the work of contacting other servers to progress operations. + + + +Wahl, et. al. Standards Track [Page 4] + +RFC 2251 LDAPv3 December 1997 + + + Note that the core protocol operations defined in this document can + be mapped to a strict subset of the X.500(1997) directory abstract + service, so it can be cleanly provided by the DAP. However there is + not a one-to-one mapping between LDAP protocol operations and DAP + operations: server implementations acting as a gateway to X.500 + directories may need to make multiple DAP requests. + +3.2. Data Model + + This section provides a brief introduction to the X.500 data model, + as used by LDAP. + + The LDAP protocol assumes there are one or more servers which jointly + provide access to a Directory Information Tree (DIT). The tree is + made up of entries. Entries have names: one or more attribute values + from the entry form its relative distinguished name (RDN), which MUST + be unique among all its siblings. The concatenation of the relative + distinguished names of the sequence of entries from a particular + entry to an immediate subordinate of the root of the tree forms that + entry's Distinguished Name (DN), which is unique in the tree. An + example of a Distinguished Name is + + CN=Steve Kille, O=Isode Limited, C=GB + + Some servers may hold cache or shadow copies of entries, which can be + used to answer search and comparison queries, but will return + referrals or contact other servers if modification operations are + requested. + + Servers which perform caching or shadowing MUST ensure that they do + not violate any access control constraints placed on the data by the + originating server. + + The largest collection of entries, starting at an entry that is + mastered by a particular server, and including all its subordinates + and their subordinates, down to the entries which are mastered by + different servers, is termed a naming context. The root of the DIT + is a DSA-specific Entry (DSE) and not part of any naming context: + each server has different attribute values in the root DSE. (DSA is + an X.500 term for the directory server). + +3.2.1. Attributes of Entries + + Entries consist of a set of attributes. An attribute is a type with + one or more associated values. The attribute type is identified by a + short descriptive name and an OID (object identifier). The attribute + + + + + +Wahl, et. al. Standards Track [Page 5] + +RFC 2251 LDAPv3 December 1997 + + + type governs whether there can be more than one value of an attribute + of that type in an entry, the syntax to which the values must + conform, the kinds of matching which can be performed on values of + that attribute, and other functions. + + An example of an attribute is "mail". There may be one or more values + of this attribute, they must be IA5 (ASCII) strings, and they are + case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). + + Schema is the collection of attribute type definitions, object class + definitions and other information which a server uses to determine + how to match a filter or attribute value assertion (in a compare + operation) against the attributes of an entry, and whether to permit + add and modify operations. The definition of schema for use with + LDAP is given in [5] and [6]. Additional schema elements may be + defined in other documents. + + Each entry MUST have an objectClass attribute. The objectClass + attribute specifies the object classes of an entry, which along with + the system and user schema determine the permitted attributes of an + entry. Values of this attribute may be modified by clients, but the + objectClass attribute cannot be removed. Servers may restrict the + modifications of this attribute to prevent the basic structural class + of the entry from being changed (e.g. one cannot change a person into + a country). When creating an entry or adding an objectClass value to + an entry, all superclasses of the named classes are implicitly added + as well if not already present, and the client must supply values for + any mandatory attributes of new superclasses. + + Some attributes, termed operational attributes, are used by servers + for administering the directory system itself. They are not returned + in search results unless explicitly requested by name. Attributes + which are not operational, such as "mail", will have their schema and + syntax constraints enforced by servers, but servers will generally + not make use of their values. + + Servers MUST NOT permit clients to add attributes to an entry unless + those attributes are permitted by the object class definitions, the + schema controlling that entry (specified in the subschema - see + below), or are operational attributes known to that server and used + for administrative purposes. Note that there is a particular + objectClass 'extensibleObject' defined in [5] which permits all user + attributes to be present in an entry. + + Entries MAY contain, among others, the following operational + attributes, defined in [5]. These attributes are maintained + automatically by the server and are not modifiable by clients: + + + + +Wahl, et. al. Standards Track [Page 6] + +RFC 2251 LDAPv3 December 1997 + + + - creatorsName: the Distinguished Name of the user who added this + entry to the directory. + + - createTimestamp: the time this entry was added to the directory. + + - modifiersName: the Distinguished Name of the user who last modified + this entry. + + - modifyTimestamp: the time this entry was last modified. + + - subschemaSubentry: the Distinguished Name of the subschema entry + (or subentry) which controls the schema for this entry. + +3.2.2. Subschema Entries and Subentries + + Subschema entries are used for administering information about the + directory schema, in particular the object classes and attribute + types supported by directory servers. A single subschema entry + contains all schema definitions used by entries in a particular part + of the directory tree. + + Servers which follow X.500(93) models SHOULD implement subschema + using the X.500 subschema mechanisms, and so these subschemas are not + ordinary entries. LDAP clients SHOULD NOT assume that servers + implement any of the other aspects of X.500 subschema. A server + which masters entries and permits clients to modify these entries + MUST implement and provide access to these subschema entries, so that + its clients may discover the attributes and object classes which are + permitted to be present. It is strongly recommended that all other + servers implement this as well. + + The following four attributes MUST be present in all subschema + entries: + + - cn: this attribute MUST be used to form the RDN of the subschema + entry. + + - objectClass: the attribute MUST have at least the values "top" and + "subschema". + + - objectClasses: each value of this attribute specifies an object + class known to the server. + + - attributeTypes: each value of this attribute specifies an attribute + type known to the server. + + These are defined in [5]. Other attributes MAY be present in + subschema entries, to reflect additional supported capabilities. + + + +Wahl, et. al. Standards Track [Page 7] + +RFC 2251 LDAPv3 December 1997 + + + These include matchingRules, matchingRuleUse, dITStructureRules, + dITContentRules, nameForms and ldapSyntaxes. + + Servers SHOULD provide the attributes createTimestamp and + modifyTimestamp in subschema entries, in order to allow clients to + maintain their caches of schema information. + + Clients MUST only retrieve attributes from a subschema entry by + requesting a base object search of the entry, where the search filter + is "(objectClass=subschema)". (This will allow LDAPv3 servers which + gateway to X.500(93) to detect that subentry information is being + requested.) + +3.3. Relationship to X.500 + + This document defines LDAP in terms of X.500 as an X.500 access + mechanism. An LDAP server MUST act in accordance with the + X.500(1993) series of ITU recommendations when providing the service. + However, it is not required that an LDAP server make use of any X.500 + protocols in providing this service, e.g. LDAP can be mapped onto any + other directory system so long as the X.500 data and service model as + used in LDAP is not violated in the LDAP interface. + +3.4. Server-specific Data Requirements + + An LDAP server MUST provide information about itself and other + information that is specific to each server. This is represented as + a group of attributes located in the root DSE (DSA-Specific Entry), + which is named with the zero-length LDAPDN. These attributes are + retrievable if a client performs a base object search of the root + with filter "(objectClass=*)", however they are subject to access + control restrictions. The root DSE MUST NOT be included if the + client performs a subtree search starting from the root. + + Servers may allow clients to modify these attributes. + + The following attributes of the root DSE are defined in section 5 of + [5]. Additional attributes may be defined in other documents. + + - namingContexts: naming contexts held in the server. Naming contexts + are defined in section 17 of X.501 [6]. + + - subschemaSubentry: subschema entries (or subentries) known by this + server. + + - altServer: alternative servers in case this one is later + unavailable. + + + + +Wahl, et. al. Standards Track [Page 8] + +RFC 2251 LDAPv3 December 1997 + + + - supportedExtension: list of supported extended operations. + + - supportedControl: list of supported controls. + + - supportedSASLMechanisms: list of supported SASL security features. + + - supportedLDAPVersion: LDAP versions implemented by the server. + + If the server does not master entries and does not know the locations + of schema information, the subschemaSubentry attribute is not present + in the root DSE. If the server masters directory entries under one + or more schema rules, there may be any number of values of the + subschemaSubentry attribute in the root DSE. + +4. Elements of Protocol + + The LDAP protocol is described using Abstract Syntax Notation 1 + (ASN.1) [3], and is typically transferred using a subset of ASN.1 + Basic Encoding Rules [11]. In order to support future extensions to + this protocol, clients and servers MUST ignore elements of SEQUENCE + encodings whose tags they do not recognize. + + Note that unlike X.500, each change to the LDAP protocol other than + through the extension mechanisms will have a different version + number. A client will indicate the version it supports as part of + the bind request, described in section 4.2. If a client has not sent + a bind, the server MUST assume that version 3 is supported in the + client (since version 2 required that the client bind first). + + Clients may determine the protocol version a server supports by + reading the supportedLDAPVersion attribute from the root DSE. Servers + which implement version 3 or later versions MUST provide this + attribute. Servers which only implement version 2 may not provide + this attribute. + +4.1. Common Elements + + This section describes the LDAPMessage envelope PDU (Protocol Data + Unit) format, as well as data type definitions which are used in the + protocol operations. + +4.1.1. Message Envelope + + For the purposes of protocol exchanges, all protocol operations are + encapsulated in a common envelope, the LDAPMessage, which is defined + as follows: + + LDAPMessage ::= SEQUENCE { + + + +Wahl, et. al. Standards Track [Page 9] + +RFC 2251 LDAPv3 December 1997 + + + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + The function of the LDAPMessage is to provide an envelope containing + common fields required in all protocol exchanges. At this time the + only common fields are the message ID and the controls. + + If the server receives a PDU from the client in which the LDAPMessage + SEQUENCE tag cannot be recognized, the messageID cannot be parsed, + the tag of the protocolOp is not recognized as a request, or the + encoding structures or lengths of data fields are found to be + incorrect, then the server MUST return the notice of disconnection + described in section 4.4.1, with resultCode protocolError, and + immediately close the connection. In other cases that the server + cannot parse the request received by the client, the server MUST + return an appropriate response to the request, with the resultCode + set to protocolError. + + If the client receives a PDU from the server which cannot be parsed, + the client may discard the PDU, or may abruptly close the connection. + + The ASN.1 type Controls is defined in section 4.1.12. + + + + +Wahl, et. al. Standards Track [Page 10] + +RFC 2251 LDAPv3 December 1997 + + +4.1.1.1. Message ID + + All LDAPMessage envelopes encapsulating responses contain the + messageID value of the corresponding request LDAPMessage. + + The message ID of a request MUST have a value different from the + values of any other requests outstanding in the LDAP session of which + this message is a part. + + A client MUST NOT send a second request with the same message ID as + an earlier request on the same connection if the client has not + received the final response from the earlier request. Otherwise the + behavior is undefined. Typical clients increment a counter for each + request. + + A client MUST NOT reuse the message id of an abandonRequest or of the + abandoned operation until it has received a response from the server + for another request invoked subsequent to the abandonRequest, as the + abandonRequest itself does not have a response. + +4.1.2. String Types + + The LDAPString is a notational convenience to indicate that, although + strings of LDAPString type encode as OCTET STRING types, the ISO + 10646 [13] character set (a superset of Unicode) is used, encoded + following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm + characters which are the same as ASCII (0x0000 through 0x007F) are + represented as that same ASCII character in a single byte. The other + byte values are used to form a variable-length encoding of an + arbitrary character. + + LDAPString ::= OCTET STRING + + The LDAPOID is a notational convenience to indicate that the + permitted value of this string is a (UTF-8 encoded) dotted-decimal + representation of an OBJECT IDENTIFIER. + + LDAPOID ::= OCTET STRING + + For example, + + 1.3.6.1.4.1.1466.1.2.3 + +4.1.3. Distinguished Name and Relative Distinguished Name + + An LDAPDN and a RelativeLDAPDN are respectively defined to be the + representation of a Distinguished Name and a Relative Distinguished + Name after encoding according to the specification in [4], such that + + + +Wahl, et. al. Standards Track [Page 11] + +RFC 2251 LDAPv3 December 1997 + + + ::= + + ::= + + where and are as defined in [4]. + + LDAPDN ::= LDAPString + + RelativeLDAPDN ::= LDAPString + + Only Attribute Types can be present in a relative distinguished name + component; the options of Attribute Descriptions (next section) MUST + NOT be used in specifying distinguished names. + +4.1.4. Attribute Type + + An AttributeType takes on as its value the textual string associated + with that AttributeType in its specification. + + AttributeType ::= LDAPString + + Each attribute type has a unique OBJECT IDENTIFIER which has been + assigned to it. This identifier may be written as decimal digits + with components separated by periods, e.g. "2.5.4.10". + + A specification may also assign one or more textual names for an + attribute type. These names MUST begin with a letter, and only + contain ASCII letters, digit characters and hyphens. They are case + insensitive. (These ASCII characters are identical to ISO 10646 + characters whose UTF-8 encoding is a single byte between 0x00 and + 0x7F.) + + If the server has a textual name for an attribute type, it MUST use a + textual name for attributes returned in search results. The dotted- + decimal OBJECT IDENTIFIER is only used if there is no textual name + for an attribute type. + + Attribute type textual names are non-unique, as two different + specifications (neither in standards track RFCs) may choose the same + name. + + A server which masters or shadows entries SHOULD list all the + attribute types it supports in the subschema entries, using the + attributeTypes attribute. Servers which support an open-ended set of + attributes SHOULD include at least the attributeTypes value for the + 'objectClass' attribute. Clients MAY retrieve the attributeTypes + value from subschema entries in order to obtain the OBJECT IDENTIFIER + and other information associated with attribute types. + + + +Wahl, et. al. Standards Track [Page 12] + +RFC 2251 LDAPv3 December 1997 + + + Some attribute type names which are used in this version of LDAP are + described in [5]. Servers may implement additional attribute types. + +4.1.5. Attribute Description + + An AttributeDescription is a superset of the definition of the + AttributeType. It has the same ASN.1 definition, but allows + additional options to be specified. They are also case insensitive. + + AttributeDescription ::= LDAPString + + A value of AttributeDescription is based on the following BNF: + + ::= [ ";" ] + + ::=