--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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> | <String> <anychar>
+
+ anychar ::= --any character occurring in general text, excluding
+ -- the end of line character
+
+ lString ::= <lowercase> <otherstring>
+
+ lowercase ::= [a-z]
+
+ UString ::= <uppercase> <otherstring>
+
+ uppercase ::= [A-Z]
+
+ otherstring ::= <otherchar> | <otherstring> <otherchar>
+
+ otherchar ::= <lowercase> | <uppercase> | <digit>
+
+ Integer ::= <digit> | <Integer> <digit>
+
+ digit ::= [0-9]
+
+1. Object Class
+
+
+ OCProforma ::= <ObjectClassName> <BlankLine> <Description> \
+ <BlankLine> <OCMacro>
+
+ ObjectClassName ::= "ObjectClass:" <String> <EOL>
+
+ Description ::= "Description:" <DescriptiveText> <EOL>
+
+ DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
+
+ OCMacro ::= "ASN1OCMacro:" <ObjectClassMacro>
+
+ -- The definition of ObjectClassMacro is adapted from
+ -- that given in X.501
+
+
+
+Barker & Kille [Page 29]
+\f
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ObjectClassMacro ::= <OCname> "OBJECT-CLASS" <SubclassOf> \
+ <MandatoryAttributes> <OptionalAttributes>
+
+ OCName ::= <lString>
+
+ SubclassOf ::= "SUBCLASS OF" Subclasses | <empty>
+
+ Subclasses ::= <Subclass> | <Subclass> "," <Subclasses>
+
+ Subclass ::= <OCName>
+
+ MandatoryAttributes ::= "MUST CONTAIN {" <Attributes> "}" \
+ | <empty>
+ OptionalAttributes ::= "MAY CONTAIN {" <Attributes> "}" | <empty>
+
+ Attributes ::= <AttributeTerm> | <AttributeTerm> "," <Attributes>
+
+ AttributeTerm ::= <Attribute> | <AttributeSet>
+
+ Attribute ::= <lString>
+
+ AttributeSet ::= <lString>
+
+2. Attribute Type
+
+
+ ATProforma ::= <AttributeTypeName> <BlankLine> <Description> \
+ <BlankLine> <OCMust> <Blankline> <OCMay> \
+ <BlankLine> <ATMacro>
+
+ AttributeTypeName ::= "Attribute Type:" <String> <EOL>
+
+ Description ::= "Description:" <DescriptiveText> <EOL>
+
+ DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
+
+ OCMust ::= "OCMust:" <OCList> <EOL>
+
+ OCList ::= <OCName> | <OCList> "," <OCName> | <empty>
+
+ OCMay ::= "OCMay:" <OCList> <EOL>
+
+ ATMacro ::= "ASN1ATMacro:" <AttributeTypeMacro>
+
+ -- The definition of AttributeTypeMacro is adapted from that
+ -- given in X.501
+
+ AttributeTypeMacro ::= <ATname> "ATTRIBUTE" <AttributeSyntax> \
+
+
+
+Barker & Kille [Page 30]
+\f
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ <Multivalued> | <empty>
+
+ ATName ::= <lString>
+
+ AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice
+
+ SyntaxChoice ::= <Syntax> <Constraint> | <ASN1Type> <MatchTypes>
+
+ Syntax ::= <lString>
+
+ Constraint ::= "(" ConstraintAlternative ")" | <empty>
+
+ ConstraintAlternative ::= StringConstraint | IntegerConstraint
+
+ StringConstraint ::= "SIZE" "(" SizeConstraint ")"
+
+ SizeConstraint ::= SingleValue | Range
+
+ SingleValue ::= <Integer>
+
+ Range ::= <Integer> ".." <Integer>
+
+ IntegerConstraint ::= Range
+
+ ASN1Type ::= <UString>
+ -- one of ASN.1's base types: e.g. PrintableString,
+ -- NumericString, etc.
+
+ MatchTypes ::= "MATCHES FOR" Matches | <empty>
+
+ Matches ::= Match | Matches Match
+
+ Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING"
+
+ Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | <empty>
+
+APPENDIX B - Format checking tools
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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: <osi-ds@cs.ucl.ac.uk>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barker & Kille [Page 60]
+\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+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.
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+RFC 1275 Replication Requirements November 1991
+
+
+ Phone: +44-71-380-7294
+
+ EMail: S.Kille@CS.UCL.AC.UK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardcastle-Kille Page 3
+
--- /dev/null
+
+
+
+
+
+
+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.
+\f
+
+
+
+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:
+
+
+ <S.Kille@CS.UCL.AC.UK>
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+RFC 1279 X.500 and Domains November 1991
+
+
+ <rr> [ ";" <comment> ]
+
+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 <CR><LF>.
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+\f
+
+
+
+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
+
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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: "+" <country code> <national number> ["x" <extension>]
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+\r
+\r
+\r
+\r
+\r
+\r
+Network Working Group T. Howes\r
+Request for Comments: 1960 University of Michigan\r
+Obsoletes: 1558 June 1996\r
+Category: Standards Track\r
+\r
+ A String Representation of LDAP Search Filters\r
+\r
+Status of this Memo\r
+\r
+ This document specifies an Internet standards track protocol for the\r
+ Internet community, and requests discussion and suggestions for\r
+ improvements. Please refer to the current edition of the "Internet\r
+ Official Protocol Standards" (STD 1) for the standardization state\r
+ and status of this protocol. Distribution of this memo is unlimited.\r
+\r
+1. Abstract\r
+\r
+ The Lightweight Directory Access Protocol (LDAP) [1] defines a\r
+ network representation of a search filter transmitted to an LDAP\r
+ server. Some applications may find it useful to have a common way of\r
+ representing these search filters in a human-readable form. This\r
+ document defines a human-readable string format for representing LDAP\r
+ search filters.\r
+\r
+2. LDAP Search Filter Definition\r
+\r
+ An LDAP search filter is defined in [1] as follows:\r
+\r
+ Filter ::= CHOICE {\r
+ and [0] SET OF Filter,\r
+ or [1] SET OF Filter,\r
+ not [2] Filter,\r
+ equalityMatch [3] AttributeValueAssertion,\r
+ substrings [4] SubstringFilter,\r
+ greaterOrEqual [5] AttributeValueAssertion,\r
+ lessOrEqual [6] AttributeValueAssertion,\r
+ present [7] AttributeType,\r
+ approxMatch [8] AttributeValueAssertion\r
+ }\r
+\r
+ SubstringFilter ::= SEQUENCE {\r
+ type AttributeType,\r
+ SEQUENCE OF CHOICE {\r
+ initial [0] LDAPString,\r
+ any [1] LDAPString,\r
+ final [2] LDAPString\r
+ }\r
+ }\r
+\r
+\r
+\r
+Howes Standards Track [Page 1]\r
+\f\r
+RFC 1960 LDAP Search Filters June 1996\r
+\r
+\r
+ AttributeValueAssertion ::= SEQUENCE {\r
+ attributeType AttributeType,\r
+ attributeValue AttributeValue\r
+ }\r
+\r
+ AttributeType ::= LDAPString\r
+\r
+ AttributeValue ::= OCTET STRING\r
+\r
+ LDAPString ::= OCTET STRING\r
+\r
+ where the LDAPString above is limited to the IA5 character set. The\r
+ AttributeType is a string representation of the attribute type name\r
+ and is defined in [1]. The AttributeValue OCTET STRING has the form\r
+ defined in [2]. The Filter is encoded for transmission over a\r
+ network using the Basic Encoding Rules defined in [3], with\r
+ simplifications described in [1].\r
+\r
+3. String Search Filter Definition\r
+\r
+ The string representation of an LDAP search filter is defined by the\r
+ following grammar. It uses a prefix format.\r
+\r
+ <filter> ::= '(' <filtercomp> ')'\r
+ <filtercomp> ::= <and> | <or> | <not> | <item>\r
+ <and> ::= '&' <filterlist>\r
+ <or> ::= '|' <filterlist>\r
+ <not> ::= '!' <filter>\r
+ <filterlist> ::= <filter> | <filter> <filterlist>\r
+ <item> ::= <simple> | <present> | <substring>\r
+ <simple> ::= <attr> <filtertype> <value>\r
+ <filtertype> ::= <equal> | <approx> | <greater> | <less>\r
+ <equal> ::= '='\r
+ <approx> ::= '~='\r
+ <greater> ::= '>='\r
+ <less> ::= '<='\r
+ <present> ::= <attr> '=*'\r
+ <substring> ::= <attr> '=' <initial> <any> <final>\r
+ <initial> ::= NULL | <value>\r
+ <any> ::= '*' <starval>\r
+ <starval> ::= NULL | <value> '*' <starval>\r
+ <final> ::= NULL | <value>\r
+\r
+ <attr> is a string representing an AttributeType, and has the format\r
+ defined in [1]. <value> is a string representing an AttributeValue,\r
+ or part of one, and has the form defined in [2]. If a <value> must\r
+ contain one of the characters '*' or '(' or ')', these characters\r
+ should be escaped by preceding them with the backslash '\' character.\r
+\r
+\r
+\r
+Howes Standards Track [Page 2]\r
+\f\r
+RFC 1960 LDAP Search Filters June 1996\r
+\r
+\r
+ Note that although both the <substring> and <present> productions can\r
+ produce the 'attr=*' construct, this construct is used only to denote\r
+ a presence filter.\r
+\r
+4. Examples\r
+\r
+ This section gives a few examples of search filters written using\r
+ this notation.\r
+\r
+ (cn=Babs Jensen)\r
+ (!(cn=Tim Howes))\r
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))\r
+ (o=univ*of*mich*)\r
+\r
+5. Security Considerations\r
+\r
+ Security considerations are not discussed in this memo.\r
+\r
+6. Bibliography\r
+\r
+ [1] Yeong, W., Howes, T., and S. Kille, "Lightweight\r
+ Directory Access Protocol", RFC 1777, March 1995.\r
+\r
+ [2] Howes, R., Kille, S., Yeong, W., and C. Robbins, "The String\r
+ Representation of Standard Attribute Syntaxes", RFC 1778,\r
+ March 1995.\r
+\r
+ [3] Specification of Basic Encoding Rules for Abstract Syntax\r
+ Notation One (ASN.1). CCITT Recommendation X.209, 1988.\r
+\r
+7. Author's Address\r
+\r
+ Tim Howes\r
+ University of Michigan\r
+ ITD Research Systems\r
+ 535 W William St.\r
+ Ann Arbor, MI 48103-4943\r
+ USA\r
+\r
+ Phone: +1 313 747-4454\r
+ EMail: tim@umich.edu\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Howes Standards Track [Page 3]\r
+\f\r
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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<NOT IDENTICAL TO><ALPHA>." (0041, 2262, 0391,
+ 002E) may be encoded as follows:
+
+ 41 E2 89 A2 CE 91 2E
+
+ The Unicode sequence "Hi Mom <WHITE SMILING FACE>!" (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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <p>. Where production <p> is described by the
+ following:
+
+
+
+Genovese & Jennings Standards Track [Page 5]
+\f
+RFC 2218 Common Schema for IWPS October 1997
+
+
+ <a> ::= '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'
+
+ <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
+
+
+ <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
+ '/' | ':' | '?' | ' '
+
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ <distinguished-name> ::= <name>
+
+ <relative-distinguished-name> ::= <name-component>
+
+ where <name> and <name-component> 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]
+\f
+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:
+
+ <AttributeDescription> ::= <AttributeType> [ ";" <options> ]
+
+ <options> ::= <option> | <option> ";" <options>
+
+ <option> ::= <opt-char> <opt-char>*
+
+ <opt-char> ::= ASCII-equivalent letters, numbers and hyphen
+
+ Examples of valid AttributeDescription:
+
+ cn
+ userCertificate;binary
+
+ One option, "binary", is defined in this document. Additional
+ options may be defined in IETF standards-track and experimental RFCs.
+ Options beginning with "x-" are reserved for private experiments.
+ Any option could be associated with any AttributeType, although not
+ all combinations may be supported by a server.
+
+ An AttributeDescription with one or more options is treated as a
+ subtype of the attribute type without any options. Options present
+ in an AttributeDescription are never mutually exclusive.
+ Implementations MUST generate the <options> list sorted in ascending
+ order, and servers MUST treat any two AttributeDescription with the
+ same AttributeType and options as equivalent. A server will treat an
+ AttributeDescription with any options it does not implement as an
+ unrecognized attribute type.
+
+ The data type "AttributeDescriptionList" describes a list of 0 or
+ more attribute types. (A list of zero elements has special
+ significance in the Search request.)
+
+ AttributeDescriptionList ::= SEQUENCE OF
+ AttributeDescription
+
+
+
+
+Wahl, et. al. Standards Track [Page 13]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+4.1.5.1. Binary Option
+
+ If the "binary" option is present in an AttributeDescription, it
+ overrides any string-based encoding representation defined for that
+ attribute in [5]. Instead the attribute is to be transferred as a
+ binary value encoded using the Basic Encoding Rules [11]. The syntax
+ of the binary value is an ASN.1 data type definition which is
+ referenced by the "SYNTAX" part of the attribute type definition.
+
+ The presence or absence of the "binary" option only affects the
+ transfer of attribute values in protocol; servers store any
+ particular attribute in a single format. If a client requests that a
+ server return an attribute in the binary format, but the server
+ cannot generate that format, the server MUST treat this attribute
+ type as an unrecognized attribute type. Similarly, clients MUST NOT
+ expect servers to return an attribute in binary format if the client
+ requested that attribute by name without the binary option.
+
+ This option is intended to be used with attributes whose syntax is a
+ complex ASN.1 data type, and the structure of values of that type is
+ needed by clients. Examples of this kind of syntax are "Certificate"
+ and "CertificateList".
+
+4.1.6. Attribute Value
+
+ A field of type AttributeValue takes on as its value either a string
+ encoding of a AttributeValue data type, or an OCTET STRING containing
+ an encoded binary value, depending on whether the "binary" option is
+ present in the companion AttributeDescription to this AttributeValue.
+
+ The definition of string encodings for different syntaxes and types
+ may be found in other documents, and in particular [5].
+
+ AttributeValue ::= OCTET STRING
+
+ Note that there is no defined limit on the size of this encoding;
+ thus protocol values may include multi-megabyte attributes (e.g.
+ photographs).
+
+ Attributes may be defined which have arbitrary and non-printable
+ syntax. Implementations MUST NEITHER simply display nor attempt to
+ decode as ASN.1 a value if its syntax is not known. The
+ implementation may attempt to discover the subschema of the source
+ entry, and retrieve the values of attributeTypes from it.
+
+ Clients MUST NOT send attribute values in a request which are not
+ valid according to the syntax defined for the attributes.
+
+
+
+
+Wahl, et. al. Standards Track [Page 14]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+4.1.7. Attribute Value Assertion
+
+ The AttributeValueAssertion type definition is similar to the one in
+ the X.500 directory standards. It contains an attribute description
+ and a matching rule assertion value suitable for that type.
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ If the "binary" option is present in attributeDesc, this signals to
+ the server that the assertionValue is a binary encoding of the
+ assertion value.
+
+ For all the string-valued user attributes described in [5], the
+ assertion value syntax is the same as the value syntax. Clients may
+ use attribute values as assertion values in compare requests and
+ search filters.
+
+ Note however that the assertion syntax may be different from the
+ value syntax for other attributes or for non-equality matching rules.
+ These may have an assertion syntax which contains only part of the
+ value. See section 20.2.1.8 of X.501 [6] for examples.
+
+4.1.8. Attribute
+
+ An attribute consists of a type and one or more values of that type.
+ (Though attributes MUST have at least one value when stored, due to
+ access control restrictions the set may be empty when transferred in
+ protocol. This is described in section 4.5.2, concerning the
+ PartialAttributeList type.)
+
+ Attribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Each attribute value is distinct in the set (no duplicates). The
+ order of attribute values within the vals set is undefined and
+ implementation-dependent, and MUST NOT be relied upon.
+
+4.1.9. Matching Rule Identifier
+
+ A matching rule is a means of expressing how a server should compare
+ an AssertionValue received in a search filter with an abstract data
+ value. The matching rule defines the syntax of the assertion value
+ and the process to be performed in the server.
+
+
+
+Wahl, et. al. Standards Track [Page 15]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ An X.501(1993) Matching Rule is identified in the LDAP protocol by
+ the printable representation of its OBJECT IDENTIFIER, either as one
+ of the strings given in [5], or as decimal digits with components
+ separated by periods, e.g. "caseIgnoreIA5Match" or
+ "1.3.6.1.4.1.453.33.33".
+
+ MatchingRuleId ::= LDAPString
+
+ Servers which support matching rules for use in the extensibleMatch
+ search filter MUST list the matching rules they implement in
+ subschema entries, using the matchingRules attributes. The server
+ SHOULD also list there, using the matchingRuleUse attribute, the
+ attribute types with which each matching rule can be used. More
+ information is given in section 4.4 of [5].
+
+4.1.10. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. In response
+ to various requests servers will return responses containing fields
+ of type LDAPResult to indicate the final status of a protocol
+ operation request.
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10), -- new
+ adminLimitExceeded (11), -- new
+ unavailableCriticalExtension (12), -- new
+ confidentialityRequired (13), -- new
+ saslBindInProgress (14), -- new
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+
+
+
+Wahl, et. al. Standards Track [Page 16]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71), -- new
+ -- 72-79 unused --
+ other (80) },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ errorMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ All the result codes with the exception of success, compareFalse and
+ compareTrue are to be treated as meaning the operation could not be
+ completed in its entirety.
+
+ Most of the result codes are based on problem indications from X.511
+ error data types. Result codes from 16 to 21 indicate an
+ AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem,
+ codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54
+ indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an
+ UpdateProblem.
+
+ If a client receives a result code which is not listed above, it is
+ to be treated as an unknown error condition.
+
+ The errorMessage field of this construct may, at the server's option,
+ be used to return a string containing a textual, human-readable
+ (terminal control and page formatting characters should be avoided)
+ error diagnostic. As this error diagnostic is not standardized,
+
+
+
+
+Wahl, et. al. Standards Track [Page 17]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ implementations MUST NOT rely on the values returned. If the server
+ chooses not to return a textual diagnostic, the errorMessage field of
+ the LDAPResult type MUST contain a zero length string.
+
+ For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
+ aliasDereferencingProblem, the matchedDN field is set to the name of
+ the lowest entry (object or alias) in the directory that was matched.
+ If no aliases were dereferenced while attempting to locate the entry,
+ this will be a truncated form of the name provided, or if aliases
+ were dereferenced, of the resulting name, as defined in section 12.5
+ of X.511 [8]. The matchedDN field is to be set to a zero length
+ string with all other result codes.
+
+4.1.11. Referral
+
+ The referral error indicates that the contacted server does not hold
+ the target entry of the request. The referral field is present in an
+ LDAPResult if the LDAPResult.resultCode field value is referral, and
+ absent with all other result codes. It contains a reference to
+ another server (or set of servers) which may be accessed via LDAP or
+ other protocols. Referrals can be returned in response to any
+ operation request (except unbind and abandon which do not have
+ responses). At least one URL MUST be present in the Referral.
+
+ The referral is not returned for a singleLevel or wholeSubtree search
+ in which the search scope spans multiple naming contexts, and several
+ different servers would need to be contacted to complete the
+ operation. Instead, continuation references, described in section
+ 4.5.3, are returned.
+
+ Referral ::= SEQUENCE OF LDAPURL -- one or more
+
+ LDAPURL ::= LDAPString -- limited to characters permitted in URLs
+
+ If the client wishes to progress the operation, it MUST follow the
+ referral by contacting any one of servers. All the URLs MUST be
+ equally capable of being used to progress the operation. (The
+ mechanisms for how this is achieved by multiple servers are outside
+ the scope of this document.)
+
+ URLs for servers implementing the LDAP protocol are written according
+ to [9]. If an alias was dereferenced, the <dn> part of the URL MUST
+ be present, with the new target object name. If the <dn> part is
+ present, the client MUST use this name in its next request to
+ progress the operation, and if it is not present the client will use
+ the same name as in the original request. Some servers (e.g.
+ participating in distributed indexing) may provide a different filter
+ in a referral for a search operation. If the filter part of the URL
+
+
+
+Wahl, et. al. Standards Track [Page 18]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ is present in an LDAPURL, the client MUST use this filter in its next
+ request to progress this search, and if it is not present the client
+ MUST use the same filter as it used for that search. Other aspects
+ of the new request may be the same or different as the request which
+ generated the referral.
+
+ Note that UTF-8 characters appearing in a DN or search filter may not
+ be legal for URLs (e.g. spaces) and MUST be escaped using the %
+ method in RFC 1738 [7].
+
+ Other kinds of URLs may be returned, so long as the operation could
+ be performed using that protocol.
+
+4.1.12. Controls
+
+ A control is a way to specify extension information. Controls which
+ are sent as part of a request apply only to that request and are not
+ saved.
+
+ Controls ::= SEQUENCE OF Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field MUST be a UTF-8 encoded dotted-decimal
+ representation of an OBJECT IDENTIFIER which uniquely identifies the
+ control. This prevents conflicts between control names.
+
+ The criticality field is either TRUE or FALSE.
+
+ If the server recognizes the control type and it is appropriate for
+ the operation, the server will make use of the control when
+ performing the operation.
+
+ If the server does not recognize the control type and the criticality
+ field is TRUE, the server MUST NOT perform the operation, and MUST
+ instead return the resultCode unsupportedCriticalExtension.
+
+ If the control is not appropriate for the operation and criticality
+ field is TRUE, the server MUST NOT perform the operation, and MUST
+ instead return the resultCode unsupportedCriticalExtension.
+
+ If the control is unrecognized or inappropriate but the criticality
+ field is FALSE, the server MUST ignore the control.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 19]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ The controlValue contains any information associated with the
+ control, and its format is defined for the control. The server MUST
+ be prepared to handle arbitrary contents of the controlValue octet
+ string, including zero bytes. It is absent only if there is no value
+ information which is associated with a control of its type.
+
+ This document does not define any controls. Controls may be defined
+ in other documents. The definition of a control consists of:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - whether the control is always noncritical, always critical, or
+ critical at the client's option,
+
+ - the format of the controlValue contents of the control.
+
+ Servers list the controls which they recognize in the
+ supportedControl attribute in the root DSE.
+
+4.2. Bind Operation
+
+ The function of the Bind Operation is to allow authentication
+ information to be exchanged between the client and server.
+
+ The Bind Request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Parameters of the Bind Request are:
+
+ - version: A version number indicating the version of the protocol to
+ be used in this protocol session. This document describes version
+ 3 of the LDAP protocol. Note that there is no version negotiation,
+ and the client just sets this parameter to the version it desires.
+ If the client requests protocol version 2, a server that supports
+ the version 2 protocol as described in [2] will not return any v3-
+
+
+
+Wahl, et. al. Standards Track [Page 20]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ specific protocol fields. (Note that not all LDAP servers will
+ support protocol version 2, since they may be unable to generate
+ the attribute syntaxes associated with version 2.)
+
+ - name: The name of the directory object that the client wishes to
+ bind as. This field may take on a null value (a zero length
+ string) for the purposes of anonymous binds, when authentication
+ has been performed at a lower layer, or when using SASL credentials
+ with a mechanism that includes the LDAPDN in the credentials.
+
+ - authentication: information used to authenticate the name, if any,
+ provided in the Bind Request.
+
+ Upon receipt of a Bind Request, a protocol server will authenticate
+ the requesting client, if necessary. The server will then return a
+ Bind Response to the client indicating the status of the
+ authentication.
+
+ Authorization is the use of this authentication information when
+ performing operations. Authorization MAY be affected by factors
+ outside of the LDAP Bind request, such as lower layer security
+ services.
+
+4.2.1. Sequencing of the Bind Request
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times. If at any stage the
+ client wishes to abort the bind process it MAY unbind and then drop
+ the underlying connection. Clients MUST NOT invoke operations
+ between two Bind requests made as part of a multi-stage bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with
+ authMethodNotSupported as the resultCode. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+ Unlike LDAP v2, the client need not send a Bind Request in the first
+ PDU of the connection. The client may request any operations and the
+ server MUST treat these as unauthenticated. If the server requires
+ that the client bind before browsing or modifying the directory, the
+ server MAY reject a request other than binding, unbinding or an
+ extended request with the "operationsError" result.
+
+
+
+
+Wahl, et. al. Standards Track [Page 21]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ If the client did not bind before sending a request and receives an
+ operationsError, it may then send a Bind Request. If this also fails
+ or the client chooses not to bind on the existing connection, it will
+ close the connection, reopen it and begin again by first sending a
+ PDU with a Bind Request. This will aid in interoperating with
+ servers implementing other versions of LDAP.
+
+ Clients MAY send multiple bind requests on a connection to change
+ their credentials. A subsequent bind process has the effect of
+ abandoning all operations outstanding on the connection. (This
+ simplifies server implementation.) Authentication from earlier binds
+ are subsequently ignored, and so if the bind fails, the connection
+ will be treated as anonymous. If a SASL transfer encryption or
+ integrity mechanism has been negotiated, and that mechanism does not
+ support the changing of credentials from one identity to another,
+ then the client MUST instead establish a new connection.
+
+4.2.2. Authentication and Other Security Services
+
+ The simple authentication option provides minimal authentication
+ facilities, with the contents of the authentication field consisting
+ only of a cleartext password. Note that the use of cleartext
+ passwords is not recommended over open networks when there is no
+ authentication or encryption being performed by a lower layer; see
+ the "Security Considerations" section.
+
+ If no authentication is to be performed, then the simple
+ authentication option MUST be chosen, and the password be of zero
+ length. (This is often done by LDAPv2 clients.) Typically the DN is
+ also of zero length.
+
+ The sasl choice allows for any mechanism defined for use with SASL
+ [12]. The mechanism field contains the name of the mechanism. The
+ credentials field contains the arbitrary data used for
+ authentication, inside an OCTET STRING wrapper. Note that unlike
+ some Internet application protocols where SASL is used, LDAP is not
+ text-based, thus no base64 transformations are performed on the
+ credentials.
+
+ If any SASL-based integrity or confidentiality services are enabled,
+ they take effect following the transmission by the server and
+ reception by the client of the final BindResponse with resultCode
+ success.
+
+ The client can request that the server use authentication information
+ from a lower layer protocol by using the SASL EXTERNAL mechanism.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 22]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+4.2.3. Bind Response
+
+ The Bind Response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of he
+ status of the client's request for authentication.
+
+ f the bind was successful, the resultCode will be success, therwise
+ it will be one of:
+
+ - operationsError: server encountered an internal error,
+
+ - protocolError: unrecognized version number or incorrect PDU
+ structure,
+
+ - authMethodNotSupported: unrecognized SASL mechanism name,
+
+ - strongAuthRequired: the server requires authentication be
+ performed with a SASL mechanism,
+
+ - referral: this server cannot accept this bind and the client
+ should try another,
+
+ - saslBindInProgress: the server requires the client to send a
+ new bind request, with the same sasl mechanism, to continue the
+ authentication process,
+
+ - inappropriateAuthentication: the server requires the client
+ which had attempted to bind anonymously or without supplying
+ credentials to provide some form of credentials,
+
+ - invalidCredentials: the wrong password was supplied or the SASL
+ credentials could not be processed,
+
+ - unavailable: the server is shutting down.
+
+ If the server does not support the client's requested protocol
+ version, it MUST set the resultCode to protocolError.
+
+ If the client receives a BindResponse response where the resultCode
+ was protocolError, it MUST close the connection as the server will be
+ unwilling to accept further operations. (This is for compatibility
+ with earlier versions of LDAP, in which the bind was always the first
+ operation, and there was no negotiation.)
+
+
+
+Wahl, et. al. Standards Track [Page 23]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ The serverSaslCreds are used as part of a SASL-defined bind mechanism
+ to allow the client to authenticate the server to which it is
+ communicating, or to perform "challenge-response" authentication. If
+ the client bound with the password choice, or the SASL mechanism does
+ not require the server to return information to the client, then this
+ field is not to be included in the result.
+
+4.3. Unbind Operation
+
+ The function of the Unbind Operation is to terminate a protocol
+ session. The Unbind Operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The Unbind Operation has no response defined. Upon transmission of an
+ UnbindRequest, a protocol client may assume that the protocol session
+ is terminated. Upon receipt of an UnbindRequest, a protocol server
+ may assume that the requesting client has terminated the session and
+ that all outstanding requests may be discarded, and may close the
+ connection.
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client which is not in response to any LDAPMessage received by
+ the server. It is used to signal an extraordinary condition in the
+ server or in the connection between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is 0 and protocolOp is of the extendedResp form. The
+ responseName field of the ExtendedResponse is present. The LDAPOID
+ value MUST be unique for this notification, and not be used in any
+ other situation.
+
+ One unsolicited notification is defined in this document.
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to close the connection due to an error
+ condition. Note that this notification is NOT a response to an
+ unbind requested by the client: the server MUST follow the procedures
+ of section 4.3. This notification is intended to assist clients in
+ distinguishing between an error condition and a transient network
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 24]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ failure. As with a connection close due to network failure, the
+ client MUST NOT assume that any outstanding requests which modified
+ the directory have succeeded or failed.
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the response field is
+ absent, and the resultCode is used to indicate the reason for the
+ disconnection.
+
+ The following resultCode values are to be used in this notification:
+
+ - protocolError: The server has received data from the client in
+ which
+ the LDAPMessage structure could not be parsed.
+
+ - strongAuthRequired: The server has detected that an established
+ underlying security association protecting communication between
+ the client and server has unexpectedly failed or been compromised.
+
+ - unavailable: This server will stop accepting new connections and
+ operations on all existing connections, and be unavailable for an
+ extended period of time. The client may make use of an alternative
+ server.
+
+ After sending this notice, the server MUST close the connection.
+ After receiving this notice, the client MUST NOT transmit any further
+ on the connection, and may abruptly close the connection.
+
+4.5. Search Operation
+
+ The Search Operation allows a client to request that a search be
+ performed on its behalf by a server. This can be used to read
+ attributes from a single entry, from entries immediately below a
+ particular entry, or a whole subtree of entries.
+
+4.5.1. Search Request
+
+ The Search Request is defined as follows:
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+
+
+
+Wahl, et. al. Standards Track [Page 25]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
+
+ 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] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- at least one must be present
+ substrings SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString } }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ Parameters of the Search Request are:
+
+ - baseObject: An LDAPDN that is the base object entry relative to
+ which the search is to be performed.
+
+ - scope: An indicator of the scope of the search to be performed. The
+ semantics of the possible values of this field are identical to the
+ semantics of the scope field in the X.511 Search Operation.
+
+ - derefAliases: An indicator as to how alias objects (as defined in
+ X.501) are to be handled in searching. The semantics of the
+ possible values of this field are:
+
+ neverDerefAliases: do not dereference aliases in searching
+ or in locating the base object of the search;
+
+
+
+Wahl, et. al. Standards Track [Page 26]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ derefInSearching: dereference aliases in subordinates of
+ the base object in searching, but not in locating the
+ base object of the search;
+
+ derefFindingBaseObj: dereference aliases in locating
+ the base object of the search, but not when searching
+ subordinates of the base object;
+
+ derefAlways: dereference aliases both in searching and in
+ locating the base object of the search.
+
+ - sizelimit: A sizelimit that restricts the maximum number of entries
+ to be returned as a result of the search. A value of 0 in this
+ field indicates that no client-requested sizelimit restrictions are
+ in effect for the search. Servers may enforce a maximum number of
+ entries to return.
+
+ - timelimit: A timelimit that restricts the maximum time (in seconds)
+ allowed for a search. A value of 0 in this field indicates that no
+ client-requested timelimit restrictions are in effect for the
+ search.
+
+ - typesOnly: An indicator as to whether search results will contain
+ both attribute types and values, or just attribute types. Setting
+ this field to TRUE causes only attribute types (no values) to be
+ returned. Setting this field to FALSE causes both attribute types
+ and values to be returned.
+
+ - filter: A filter that defines the conditions that must be fulfilled
+ in order for the search to match a given entry.
+
+ The 'and', 'or' and 'not' choices can be used to form combinations of
+ filters. At least one filter element MUST be present in an 'and' or
+ 'or' choice. The others match against individual attribute values of
+ entries in the scope of the search. (Implementor's note: the 'not'
+ filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag was explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic
+ of X.511(93) section 7.8.1. In summary, a filter is evaluated to
+ either "TRUE", "FALSE" or "Undefined". If the filter evaluates
+ to TRUE for a particular entry, then the attributes of that entry
+ are returned as part of the search result (subject to any applicable
+ access control restrictions). If the filter evaluates to FALSE or
+ Undefined, then the entry is ignored for the search.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 27]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ A filter of the "and" choice is TRUE if all the filters in the SET
+ OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ otherwise Undefined. A filter of the "or" choice is FALSE if all
+ of the filters in the SET OF evaluate to FALSE, TRUE if at least
+ one filter is TRUE, and Undefined otherwise. A filter of the "not"
+ choice is TRUE if the filter being negated is FALSE, FALSE if it is
+ TRUE, and Undefined if it is Undefined.
+
+ The present match evaluates to TRUE where there is an attribute or
+ subtype of the specified attribute description present in an entry,
+ and FALSE otherwise (including a presence test with an unrecognized
+ attribute description.)
+
+ The extensibleMatch is new in this version of LDAP. If the
+ matchingRule field is absent, the type field MUST be present, and
+ the equality match is performed for that type. If the type field is
+ absent and matchingRule is present, the matchValue is compared
+ against all attributes in an entry which support that matchingRule,
+ and the matchingRule determines the syntax for the assertion value
+ (the filter item evaluates to TRUE if it matches with at least
+ one attribute in the entry, FALSE if it does not match any attribute
+ in the entry, and Undefined if the matchingRule is not recognized
+ or the assertionValue cannot be parsed.) If the type field is
+ present and matchingRule is present, the matchingRule MUST be one
+ permitted for use with that type, otherwise the filter item is
+ undefined. If the dnAttributes field is set to TRUE, the match is
+ applied against all the attributes in an entry's distinguished name
+ as well, and also evaluates to TRUE if there is at least one
+ attribute in the distinguished name for which the filter item
+ evaluates to TRUE. (Editors note: The dnAttributes field is present
+ so that there does not need to be multiple versions of generic
+ matching rules such as for word matching, one to apply to entries
+ and another to apply to entries and dn attributes as well).
+
+ A filter item evaluates to Undefined when the server would not
+ be able to determine whether the assertion value matches an
+ entry. If an attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
+ filter is not recognized by the server, a matching rule id in the
+ extensibleMatch is not recognized by the server, the assertion
+ value cannot be parsed, or the type of filtering requested is not
+ implemented, then the filter is Undefined. Thus for example if a
+ server did not recognize the attribute type shoeSize, a filter of
+ (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12),
+ (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 28]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, or assertion values cannot be parsed.
+ More details of filter processing are given in section 7.8 of X.511
+ [8].
+
+ - attributes: A list of the attributes to be returned from each entry
+ which matches the search filter. There are two special values which
+ may be used: an empty list with no attributes, and the attribute
+ description string "*". Both of these signify that all user
+ attributes are to be returned. (The "*" allows the client to
+ request all user attributes in addition to specific operational
+ attributes).
+
+ Attributes MUST be named at most once in the list, and are returned
+ at most once in an entry. If there are attribute descriptions in
+ the list which are not recognized, they are ignored by the server.
+
+ If the client does not want any attributes returned, it can specify
+ a list containing only the attribute with OID "1.1". This OID was
+ chosen arbitrarily and does not correspond to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes of the entry may not be included in
+ search results due to access control or other restrictions.
+ Furthermore, servers will not return operational attributes, such
+ as objectClasses or attributeTypes, unless they are listed by name,
+ since there may be extremely large number of values for certain
+ operational attributes. (A list of operational attributes for use
+ in LDAP is given in [5].)
+
+ Note that an X.500 "list"-like operation can be emulated by the client
+ requesting a one-level LDAP search operation with a filter checking
+ for the existence of the objectClass attribute, and that an X.500
+ "read"-like operation can be emulated by a base object LDAP search
+ operation with the same filter. A server which provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does must provide the same semantics
+ as the X.500 search operation.
+
+4.5.2. Search Result
+
+ The results of the search attempted by the server upon receipt of a
+ Search Request are returned in Search Responses, which are LDAP
+ messages containing either SearchResultEntry, SearchResultReference,
+ ExtendedResponse or SearchResultDone data types.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+
+
+
+Wahl, et. al. Standards Track [Page 29]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+ -- implementors should note that the PartialAttributeList may
+ -- have zero elements (if none of the attributes of that entry
+ -- were requested, or could be returned), and that the vals set
+ -- may also have zero elements (if types only was requested, or
+ -- all values were excluded from the result.)
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+ -- at least one LDAPURL element must be present
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Upon receipt of a Search Request, a server will perform the necessary
+ search of the DIT.
+
+ If the LDAP session is operating over a connection-oriented transport
+ such as TCP, the server will return to the client a sequence of
+ responses in separate LDAP messages. There may be zero or more
+ responses containing SearchResultEntry, one for each entry found
+ during the search. There may also be zero or more responses
+ containing SearchResultReference, one for each area not explored by
+ this server during the search. The SearchResultEntry and
+ SearchResultReference PDUs may come in any order. Following all the
+ SearchResultReference responses and all SearchResultEntry responses
+ to be returned by the server, the server will return a response
+ containing the SearchResultDone, which contains an indication of
+ success, or detailing any errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ attributes, complete with associated values if necessary, as
+ specified in the attributes field of the Search Request. Return of
+ attributes is subject to access control and other administrative
+ policy. Some attributes may be returned in binary format (indicated
+ by the AttributeDescription in the response having the binary option
+ present).
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients MUST NOT assume that all attributes
+ can be modified, even if permitted by access control.
+
+ LDAPMessage responses of the ExtendedResponse form are reserved for
+ returning information associated with a control requested by the
+ client. These may be defined in future versions of this document.
+
+
+
+Wahl, et. al. Standards Track [Page 30]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable to search all the entries in the scope at
+ and under the baseObject, the server may return one or more
+ SearchResultReference, each containing a reference to another set of
+ servers for continuing the operation. A server MUST NOT return any
+ SearchResultReference if it has not located the baseObject and
+ thus has not searched any entries; in this case it would return a
+ SearchResultDone containing a referral resultCode.
+
+ In the absence of indexing information provided to a server from
+ servers holding subordinate naming contexts, SearchResultReference
+ responses are not affected by search filters and are always returned
+ when in scope.
+
+ The SearchResultReference is of the same data type as the Referral.
+ URLs for servers implementing the LDAP protocol are written according
+ to [9]. The <dn> part MUST be present in the URL, with the new target
+ object name. The client MUST use this name in its next request.
+ Some servers (e.g. part of a distributed index exchange system) may
+ provide a different filter in the URLs of the SearchResultReference.
+ If the filter part of the URL is present in an LDAP URL, the client
+ MUST use the new filter in its next request to progress the search,
+ and if the filter part is absent the client will use again the same
+ filter. Other aspects of the new search request may be the same or
+ different as the search which generated the continuation references.
+
+ Other kinds of URLs may be returned so long as the operation could be
+ performed using that protocol.
+
+ The name of an unexplored subtree in a SearchResultReference need not
+ be subordinate to the base object.
+
+ In order to complete the search, the client MUST issue a new search
+ operation for each SearchResultReference that is returned. Note that
+ the abandon operation described in section 4.11 applies only to a
+ particular operation sent on a connection between a client and server,
+ and if the client has multiple outstanding search operations to
+ different servers, it MUST abandon each operation individually.
+
+4.5.3.1. Example
+
+ For example, suppose the contacted server (hosta) holds the entry
+ "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that
+ either LDAP-capable servers (hostb) or (hostc) hold
+ "OU=People,O=MNN,C=WW" (one is the master and the other server a
+
+
+
+
+Wahl, et. al. Standards Track [Page 31]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ shadow), and that LDAP-capable server (hostd) holds the subtree
+ "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is
+ requested to the contacted server, it may return the following:
+
+ SearchResultEntry for O=MNN,C=WW
+ SearchResultEntry for CN=Manager,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostb/OU=People,O=MNN,C=WW
+ ldap://hostc/OU=People,O=MNN,C=WW
+ }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,O=MNN,C=WW
+ }
+ SearchResultDone (success)
+
+ Client implementors should note that when following a
+ SearchResultReference, additional SearchResultReference may be
+ generated. Continuing the example, if the client contacted the
+ server (hostb) and issued the search for the subtree
+ "OU=People,O=MNN,C=WW", the server might respond as follows:
+
+ SearchResultEntry for OU=People,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
+ }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
+ }
+ SearchResultDone (success)
+
+ If the contacted server does not hold the base object for the search,
+ then it will return a referral to the client. For example, if the
+ client requests a subtree search of "O=XYZ,C=US" to hosta, the server
+ may return only a SearchResultDone containing a referral.
+
+ SearchResultDone (referral) {
+ ldap://hostg/
+ }
+
+4.6. Modify Operation
+
+ The Modify Operation allows a client to request that a modification
+ of an entry be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+
+
+
+Wahl, et. al. Standards Track [Page 32]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Parameters of the Modify Request are:
+
+ - object: The object to be modified. The value of this field contains
+ the DN of the entry to be modified. The server will not perform
+ any alias dereferencing in determining the object to be modified.
+
+ - modification: A list of modifications to be performed on the entry.
+ The entire list of entry modifications MUST be performed
+ in the order they are listed, as a single atomic operation. While
+ individual modifications may violate the directory schema, the
+ resulting entry after the entire list of modifications is performed
+ MUST conform to the requirements of the directory schema. The
+ values that may be taken on by the 'operation' field in each
+ modification construct have the following semantics respectively:
+
+ add: add values listed to the given attribute, creating
+ the attribute if necessary;
+
+ delete: delete values listed from the given attribute,
+ removing the entire attribute if no values are listed, or
+ if all current values of the attribute are listed for
+ deletion;
+
+ replace: replace all existing values of the given attribute
+ with the new values listed, creating the attribute if it
+ did not already exist. A replace with no value will delete
+ the entire attribute if it exists, and is ignored if the
+ attribute does not exist.
+
+ The result of the modify attempted by the server upon receipt of a
+ Modify Request is returned in a Modify Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ Upon receipt of a Modify Request, a server will perform the necessary
+ modifications to the DIT.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 33]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIT modification,
+ or the reason that the modification failed. Note that due to the
+ requirement for atomicity in applying the list of modifications in
+ the Modify Request, the client may expect that no modifications of
+ the DIT have been performed if the Modify Response received indicates
+ any sort of error, and that all requested modifications have been
+ performed if the Modify Response indicates successful completion of
+ the Modify Operation. If the connection fails, whether the
+ modification occurred or not is indeterminate.
+
+ The Modify Operation cannot be used to remove from an entry any of
+ its distinguished values, those values which form the entry's
+ relative distinguished name. An attempt to do so will result in the
+ server returning the error notAllowedOnRDN. The Modify DN Operation
+ described in section 4.9 is used to rename an entry.
+
+ If an equality match filter has not been defined for an attribute type,
+ clients MUST NOT attempt to delete individual values of that attribute
+ from an entry using the "delete" form of a modification, and MUST
+ instead use the "replace" form.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the modifications in an LDAP ModifyRequest onto the
+ EntryModifications of a DAP ModifyEntry operation, and different
+ implementations of LDAP-DAP gateways may use different means of
+ representing the change. If successful, the final effect of the
+ operations on the entry MUST be identical.
+
+4.7. Add Operation
+
+ The Add Operation allows a client to request the addition of an entry
+ into the directory. The Add Request is defined as follows:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Parameters of the Add Request are:
+
+ - entry: the Distinguished Name of the entry to be added. Note that
+ the server will not dereference any aliases in locating the entry
+ to be added.
+
+
+
+
+Wahl, et. al. Standards Track [Page 34]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ - attributes: the list of attributes that make up the content of the
+ entry being added. Clients MUST include distinguished values
+ (those forming the entry's own RDN) in this list, the objectClass
+ attribute, and values of any mandatory attributes of the listed
+ object classes. Clients MUST NOT supply the createTimestamp or
+ creatorsName attributes, since these will be generated
+ automatically by the server.
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The parent of the entry to be added
+ MUST exist. For example, if the client attempted to add
+ "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the
+ "C=US" entry did exist, then the server would return the error
+ noSuchObject with the matchedDN field containing "C=US". If the
+ parent entry exists but is not in a naming context held by the
+ server, the server SHOULD return a referral to the server holding the
+ parent entry.
+
+ Servers implementations SHOULD NOT restrict where entries can be
+ located in the directory. Some servers MAY allow the administrator
+ to restrict the classes of entries which can be added to the
+ directory.
+
+ Upon receipt of an Add Request, a server will attempt to perform the
+ add requested. The result of the add attempt will be returned to the
+ client in the Add Response, defined as follows:
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ A response of success indicates that the new entry is present in the
+ directory.
+
+4.8. Delete Operation
+
+ The Delete Operation allows a client to request the removal of an
+ entry from the directory. The Delete Request is defined as follows:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ The Delete Request consists of the Distinguished Name of the entry to
+ be deleted. Note that the server will not dereference aliases while
+ resolving the name of the target entry to be removed, and that only
+ leaf entries (those with no subordinate entries) can be deleted with
+ this operation.
+
+ The result of the delete attempted by the server upon receipt of a
+ Delete Request is returned in the Delete Response, defined as
+ follows:
+
+
+
+Wahl, et. al. Standards Track [Page 35]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested. The result of the delete attempt will be
+ returned to the client in the Delete Response.
+
+4.9. Modify DN Operation
+
+ The Modify DN Operation allows a client to change the leftmost (least
+ significant) component of the name of an entry in the directory, or
+ to move a subtree of entries to a new location in the directory. The
+ Modify DN Request is defined as follows:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ Parameters of the Modify DN Request are:
+
+ - entry: the Distinguished Name of the entry to be changed. This
+ entry may or may not have subordinate entries.
+
+ - newrdn: the RDN that will form the leftmost component of the new
+ name of the entry.
+
+ - deleteoldrdn: a boolean parameter that controls whether the old RDN
+ attribute values are to be retained as attributes of the entry, or
+ deleted from the entry.
+
+ - newSuperior: if present, this is the Distinguished Name of the entry
+ which becomes the immediate superior of the existing entry.
+
+ The result of the name change attempted by the server upon receipt of
+ a Modify DN Request is returned in the Modify DN Response, defined
+ as follows:
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to
+ perform the name change. The result of the name change attempt will
+ be returned to the client in the Modify DN Response.
+
+ For example, if the entry named in the "entry" parameter was
+ "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith",
+ and the newSuperior parameter was absent, then this operation would
+
+
+
+
+Wahl, et. al. Standards Track [Page 36]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ attempt to rename the entry to be "cn=John Cougar Smith,c=US". If
+ there was already an entry with that name, the operation would fail
+ with error code entryAlreadyExists.
+
+ If the deleteoldrdn parameter is TRUE, the values forming the old
+ RDN are deleted from the entry. If the deleteoldrdn parameter is
+ FALSE, the values forming the old RDN will be retained as
+ non-distinguished attribute values of the entry. The server may
+ not perform the operation and return an error code if the setting of
+ the deleteoldrdn parameter would cause a schema inconsistency in the
+ entry.
+
+ Note that X.500 restricts the ModifyDN operation to only affect
+ entries that are contained within a single server. If the LDAP
+ server is mapped onto DAP, then this restriction will apply, and the
+ resultCode affectsMultipleDSAs will be returned if this error
+ occurred. In general clients MUST NOT expect to be able to perform
+ arbitrary movements of entries and subtrees between servers.
+
+4.10. Compare Operation
+
+ The Compare Operation allows a client to compare an assertion
+ provided with an entry in the directory. The Compare Request is
+ defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Parameters of the Compare Request are:
+
+ - entry: the name of the entry to be compared with.
+
+ - ava: the assertion with which an attribute in the entry is to be
+ compared.
+
+ The result of the compare attempted by the server upon receipt of a
+ Compare Request is returned in the Compare Response, defined as
+ follows:
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison. The result of the comparison will be
+ returned to the client in the Compare Response. Note that errors and
+ the result of comparison are all returned in the same construct.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 37]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ Note that some directory systems may establish access controls which
+ permit the values of certain attributes (such as userPassword) to be
+ compared but not read. In a search result, it may be that an
+ attribute of that type would be returned, but with an empty set of
+ values.
+
+4.11. Abandon Operation
+
+ The function of the Abandon Operation is to allow a client to request
+ that the server abandon an outstanding operation. The Abandon
+ Request is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID MUST be that of a an operation which was requested
+ earlier in this connection.
+
+ (The abandon request itself has its own message id. This is distinct
+ from the id of the earlier operation being abandoned.)
+
+ There is no response defined in the Abandon Operation. Upon
+ transmission of an Abandon Operation, a client may expect that the
+ operation identified by the Message ID in the Abandon Request has
+ been abandoned. In the event that a server receives an Abandon
+ Request on a Search Operation in the midst of transmitting responses
+ to the search, that server MUST cease transmitting entry responses to
+ the abandoned request immediately, and MUST NOT send the
+ SearchResponseDone. Of course, the server MUST ensure that only
+ properly encoded LDAPMessage PDUs are transmitted.
+
+ Clients MUST NOT send abandon requests for the same operation
+ multiple times, and MUST also be prepared to receive results from
+ operations it has abandoned (since these may have been in transit
+ when the abandon was requested).
+
+ Servers MUST discard abandon requests for message IDs they do not
+ recognize, for operations which cannot be abandoned, and for
+ operations which have already been abandoned.
+
+4.12. Extended Operation
+
+ An extension mechanism has been added in this version of LDAP, in
+ order to allow additional operations to be defined for services not
+ available elsewhere in this protocol, for instance digitally signed
+ operations and results.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 38]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ The extended operation allows clients to make requests and receive
+ responses with predefined syntaxes and semantics. These may be
+ defined in RFCs or be private to particular implementations. Each
+ request MUST have a unique OBJECT IDENTIFIER assigned to it.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ The requestName is a dotted-decimal representation of the OBJECT
+ IDENTIFIER corresponding to the request. The requestValue is
+ information in a form defined by that request, encapsulated inside an
+ OCTET STRING.
+
+ The server will respond to this with an LDAPMessage containing the
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ If the server does not recognize the request name, it MUST return
+ only the response fields from LDAPResult, containing the
+ protocolError result code.
+
+5. Protocol Element Encodings and Transfer
+
+ One underlying service is defined here. Clients and servers SHOULD
+ implement the mapping of LDAP over TCP described in 5.2.1.
+
+5.1. Mapping Onto BER-based Transport Services
+
+ The protocol elements of LDAP are encoded for exchange using the
+ Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
+ high overhead involved in using certain elements of the BER, the
+ following additional restrictions are placed on BER-encodings of LDAP
+ protocol elements:
+
+ (1) Only the definite form of length encoding will be used.
+
+ (2) OCTET STRING values will be encoded in the primitive form only.
+
+ (3) If the value of a BOOLEAN type is true, the encoding MUST have
+ its contents octets set to hex "FF".
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 39]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ (4) If a value of a type is its default value, it MUST be absent.
+ Only some BOOLEAN and INTEGER types have default values in this
+ protocol definition.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ noted.
+
+5.2. Transfer Protocols
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, with all 8 bits in an octet being significant in the data
+ stream.
+
+5.2.1. Transmission Control Protocol (TCP)
+
+ The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It
+ is recommended that server implementations running over the TCP MAY
+ provide a protocol listener on the assigned port, 389. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+6. Implementation Guidelines
+
+ This document describes an Internet protocol.
+
+6.1. Server Implementations
+
+ The server MUST be capable of recognizing all the mandatory attribute
+ type names and implement the syntaxes specified in [5]. Servers MAY
+ also recognize additional attribute type names.
+
+6.2. Client Implementations
+
+ Clients which request referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server for
+ the same request with the same target entry name, scope and filter.
+ Some clients may be using a counter that is incremented each time
+ referral handling occurs for an operation, and these kinds of clients
+ MUST be able to handle a DIT with at least ten layers of naming
+ contexts between the root and a leaf entry.
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schemas beyond those
+ referenced in section 6.1. Different schemas can have different
+ attribute types with the same names. The client can retrieve the
+ subschema entries referenced by the subschemaSubentry attribute in
+ the server's root DSE or in entries held by the server.
+
+
+
+Wahl, et. al. Standards Track [Page 40]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+7. Security Considerations
+
+ When used with a connection-oriented transport, this version of the
+ protocol provides facilities for the LDAP v2 authentication
+ mechanism, simple authentication using a cleartext password, as well
+ as any SASL mechanism [12]. SASL allows for integrity and privacy
+ services to be negotiated.
+
+ It is also permitted that the server can return its credentials to
+ the client, if it chooses to do so.
+
+ Use of cleartext password is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ When used with SASL, it should be noted that the name field of the
+ BindRequest is not protected against modification. Thus if the
+ distinguished name of the client (an LDAPDN) is agreed through the
+ negotiation of the credentials, it takes precedence over any value in
+ the unprotected name field.
+
+ Implementations which cache attributes and entries obtained via LDAP
+ MUST ensure that access controls are maintained if that information
+ is to be provided to multiple clients, since servers may have access
+ control policies which prevent the return of entries or attributes in
+ search results except to particular authenticated clients. For
+ example, caches could serve result information only to the client
+ whose request caused it to be cache.
+
+8. Acknowledgements
+
+ This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes,
+ and Steve Kille. Design ideas included in this document are based on
+ those discussed in ASID and other IETF Working Groups. The
+ contributions of individuals in these working groups is gratefully
+ acknowledged.
+
+9. Bibliography
+
+ [1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
+ and Service", 1993.
+
+ [2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol", RFC 1777, March 1995.
+
+ [3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", 1994.
+
+
+
+
+Wahl, et. al. Standards Track [Page 41]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ [4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [6] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+ [7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
+ 1993.
+
+ [9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+ [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", 1994.
+
+ [12] Meyers, J., "Simple Authentication and Security Layer",
+ RFC 2222, October 1997.
+
+ [13] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
+ 1993.
+
+ [14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+10. Authors' Addresses
+
+ 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
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 42]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd., MS MV068
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 937-3419
+ EMail: howes@netscape.com
+
+ Steve Kille
+ Isode Limited
+ The Dome, The Square
+ Richmond
+ TW9 1DT
+ UK
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 43]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+Appendix A - Complete ASN.1 Definition
+
+ Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
+ IMPLICIT TAGS ::=
+
+ BEGIN
+
+ LDAPMessage ::= SEQUENCE {
+ 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) --
+
+ LDAPString ::= OCTET STRING
+
+ LDAPOID ::= OCTET STRING
+
+ LDAPDN ::= LDAPString
+
+ RelativeLDAPDN ::= LDAPString
+
+ AttributeType ::= LDAPString
+
+ AttributeDescription ::= LDAPString
+
+
+
+
+Wahl, et. al. Standards Track [Page 44]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ AttributeDescriptionList ::= SEQUENCE OF
+ AttributeDescription
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ Attribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ MatchingRuleId ::= LDAPString
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10), -- new
+ adminLimitExceeded (11), -- new
+ unavailableCriticalExtension (12), -- new
+ confidentialityRequired (13), -- new
+ saslBindInProgress (14), -- new
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+
+
+
+Wahl, et. al. Standards Track [Page 45]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71), -- new
+ -- 72-79 unused --
+ other (80) },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ errorMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE OF LDAPURL
+
+ LDAPURL ::= LDAPString -- limited to characters permitted in URLs
+
+ Controls ::= SEQUENCE OF Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+
+
+
+Wahl, et. al. Standards Track [Page 46]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
+
+ 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] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- at least one must be present
+ substrings SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString } }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+Wahl, et. al. Standards Track [Page 47]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+
+
+Wahl, et. al. Standards Track [Page 48]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 49]
+\f
+RFC 2251 LDAPv3 December 1997
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 50]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2252 Critical Angle Inc.
+Category: Standards Track A. Coulbeck
+ Isode Inc.
+ T. Howes
+ Netscape Communications Corp.
+ S. Kille
+ Isode Limited
+ December 1997
+
+
+ Lightweight Directory Access Protocol (v3):
+ Attribute Syntax Definitions
+
+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
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 1]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ 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.
+
+ 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.
+
+2. Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) [1] requires that
+ the contents of AttributeValue fields in protocol elements be octet
+ strings. This document defines a set of syntaxes for LDAPv3, and the
+ rules by which attribute values of these syntaxes are represented as
+ octet strings for transmission in the LDAP protocol. The syntaxes
+ defined in this document are referenced by this and other documents
+ that define attribute types. This document also defines the set of
+ attribute types which LDAP servers should support.
+
+3. Overview
+
+ This document defines the framework for developing schemas for
+ directories accessible via the Lightweight Directory Access Protocol.
+
+ 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.
+
+ Section 4 states the general requirements and notations for attribute
+ types, object classes, syntax and matching rule definitions.
+
+ Section 5 lists attributes, section 6 syntaxes and section 7 object
+ classes.
+
+ Additional documents define schemas for representing real-world
+ objects as directory entries.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 2]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+4. General Issues
+
+ This document describes encodings used in an Internet protocol.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [4].
+
+ Attribute Type and Object Class definitions are written in a string
+ representation of the AttributeTypeDescription and
+ ObjectClassDescription data types defined in X.501(93) [3].
+ Implementors are strongly advised to first read the description of
+ how schema is represented in X.500 before reading the rest of this
+ document.
+
+4.1. Common Encoding Aspects
+
+ For the purposes of defining the encoding rules for attribute
+ syntaxes, the following BNF definitions will be used. They are based
+ on the BNF styles of RFC 822 [13].
+
+ a = "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"
+
+ d = "0" / "1" / "2" / "3" / "4" /
+ "5" / "6" / "7" / "8" / "9"
+
+ hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" /
+ "A" / "B" / "C" / "D" / "E" / "F"
+
+ k = a / d / "-" / ";"
+
+ p = a / d / """ / "(" / ")" / "+" / "," /
+ "-" / "." / "/" / ":" / "?" / " "
+
+ letterstring = 1*a
+
+ numericstring = 1*d
+
+ anhstring = 1*k
+
+ keystring = a [ anhstring ]
+
+ printablestring = 1*p
+
+
+
+Wahl, et. al. Standards Track [Page 3]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ space = 1*" "
+
+ whsp = [ space ]
+
+ utf8 = <any sequence of octets formed from the UTF-8 [9]
+ transformation of a character from ISO10646 [10]>
+
+ dstring = 1*utf8
+
+ qdstring = whsp "'" dstring "'" whsp
+
+ qdstringlist = [ qdstring *( qdstring ) ]
+
+ qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp )
+
+ In the following BNF for the string representation of OBJECT
+ IDENTIFIERs, descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter. An OBJECT IDENTIFIER in the numericoid format should not
+ have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
+ not be generated).
+
+ When encoding 'oid' elements in a value, the descr encoding option
+ SHOULD be used in preference to the numericoid. An object descriptor
+ is a more readable alias for a number OBJECT IDENTIFIER, and these
+ (where assigned and known by the implementation) SHOULD be used in
+ preference to numeric oids to the greatest extent possible. Examples
+ of object descriptors in LDAP are attribute type, object class and
+ matching rule names.
+
+ oid = descr / numericoid
+
+ descr = keystring
+
+ numericoid = numericstring *( "." numericstring )
+
+ woid = whsp oid whsp
+
+ ; set of oids of either form
+ oids = woid / ( "(" oidlist ")" )
+
+ oidlist = woid *( "$" woid )
+
+ ; object descriptors used as schema element names
+ qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp )
+
+ qdescrlist = [ qdescr *( qdescr ) ]
+
+
+
+
+Wahl, et. al. Standards Track [Page 4]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ qdescr = whsp "'" descr "'" whsp
+
+4.2. Attribute Types
+
+ The attribute types are described by sample values for the subschema
+ "attributeTypes" attribute, which is written in the
+ AttributeTypeDescription syntax. While lines have been folded for
+ readability, the values transferred in protocol would not contain
+ newlines.
+
+ The AttributeTypeDescription is encoded according to the following
+ BNF, and the productions for oid, qdescrs and qdstring are given in
+ section 4.1. Implementors should note that future versions of this
+ document may have expanded this BNF to include additional terms.
+ Terms which begin with the characters "X-" are reserved for private
+ experiments, and MUST be followed by a <qdstrings>.
+
+ AttributeTypeDescription = "(" whsp
+ numericoid whsp ; AttributeType identifier
+ [ "NAME" qdescrs ] ; name used in AttributeType
+ [ "DESC" qdstring ] ; description
+ [ "OBSOLETE" whsp ]
+ [ "SUP" woid ] ; derived from this other
+ ; AttributeType
+ [ "EQUALITY" woid ; Matching Rule name
+ [ "ORDERING" woid ; Matching Rule name
+ [ "SUBSTR" woid ] ; Matching Rule name
+ [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
+ [ "SINGLE-VALUE" whsp ] ; default multi-valued
+ [ "COLLECTIVE" whsp ] ; default not collective
+ [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
+ [ "USAGE" whsp AttributeUsage ]; default userApplications
+ whsp ")"
+
+ AttributeUsage =
+ "userApplications" /
+ "directoryOperation" /
+ "distributedOperation" / ; DSA-shared
+ "dSAOperation" ; DSA-specific, value depends on server
+
+ Servers are not required to provide the same or any text in the
+ description part of the subschema values they maintain. Servers
+ SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
+ AttributeTypeDescription.
+
+ Servers MUST implement all the attribute types referenced in sections
+ 5.1, 5.2 and 5.3.
+
+
+
+
+Wahl, et. al. Standards Track [Page 5]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Servers MAY recognize additional names and attributes not listed in
+ this document, and if they do so, MUST publish the definitions of the
+ types in the attributeTypes attribute of their subschema entries.
+
+ Schema developers MUST NOT create attribute definitions whose names
+ conflict with attributes defined for use with LDAP in existing
+ standards-track RFCs.
+
+ An AttributeDescription can be used as the value in a NAME part of an
+ AttributeTypeDescription. Note that these are case insensitive.
+
+ Note that the AttributeTypeDescription does not list the matching
+ rules which can can be used with that attribute type in an
+ extensibleMatch search filter. This is done using the
+ matchingRuleUse attribute described in section 4.5.
+
+ This document refines the schema description of X.501 by requiring
+ that the syntax field in an AttributeTypeDescription be a string
+ representation of an OBJECT IDENTIFIER for the LDAP string syntax
+ definition, and an optional indication of the maximum length of a
+ value of this attribute (defined in section 4.3.2).
+
+4.3. Syntaxes
+
+ This section defines general requirements for LDAP attribute value
+ syntax encodings. All documents defining attribute syntax encodings
+ for use with LDAP are expected to conform to these requirements.
+
+ The encoding rules defined for a given attribute syntax must produce
+ octet strings. To the greatest extent possible, encoded octet
+ strings should be usable in their native encoded form for display
+ purposes. In particular, encoding rules for attribute syntaxes
+ defining non-binary values should produce strings that can be
+ displayed with little or no translation by clients implementing LDAP.
+ There are a few cases (e.g. audio) however, when it is not sensible
+ to produce a printable representation, and clients MUST NOT assume
+ that an unrecognized syntax is a string representation.
+
+ In encodings where an arbitrary string, not a Distinguished Name, is
+ used as part of a larger production, and other than as part of a
+ Distinguished Name, a backslash quoting mechanism is used to escape
+ the following separator symbol character (such as "'", "$" or "#") if
+ it should occur in that string. The backslash is followed by a pair
+ of hexadecimal digits representing the next character. A backslash
+ itself in the string which forms part of a larger syntax is always
+ transmitted as '\5C' or '\5c'. An example is given in section 6.27.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 6]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Syntaxes are also defined for matching rules whose assertion value
+ syntax is different from the attribute value syntax.
+
+4.3.1 Binary Transfer of Values
+
+ This encoding format is used if the binary encoding is requested by
+ the client for an attribute, or if the attribute syntax name is
+ "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP
+ AttributeValue or AssertionValue field is a BER-encoded instance of
+ the attribute value or a matching rule assertion value ASN.1 data
+ type as defined for use with X.500. (The first byte inside the OCTET
+ STRING wrapper is a tag octet. However, the OCTET STRING is still
+ encoded in primitive form.)
+
+ All servers MUST implement this form for both generating attribute
+ values in search responses, and parsing attribute values in add,
+ compare and modify requests, if the attribute type is recognized and
+ the attribute syntax name is that of Binary. Clients which request
+ that all attributes be returned from entries MUST be prepared to
+ receive values in binary (e.g. userCertificate;binary), and SHOULD
+ NOT simply display binary or unrecognized values to users.
+
+4.3.2. Syntax Object Identifiers
+
+ Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
+ dotted-decimal strings. These are not intended to be displayed to
+ users.
+
+ noidlen = numericoid [ "{" len "}" ]
+
+ len = numericstring
+
+ The following table lists some of the syntaxes that have been defined
+ for LDAP thus far. The H-R column suggests whether a value in that
+ syntax would likely be a human readable string. Clients and servers
+ need not implement all the syntaxes listed here, and MAY implement
+ other syntaxes.
+
+ Other documents may define additional syntaxes. However, the
+ definition of additional arbitrary syntaxes is strongly deprecated
+ since it will hinder interoperability: today's client and server
+ implementations generally do not have the ability to dynamically
+ recognize new syntaxes. In most cases attributes will be defined
+ with the syntax for directory strings.
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 7]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Value being represented H-R OBJECT IDENTIFIER
+ =================================================================
+ ACI Item N 1.3.6.1.4.1.1466.115.121.1.1
+ Access Point Y 1.3.6.1.4.1.1466.115.121.1.2
+ Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3
+ Audio N 1.3.6.1.4.1.1466.115.121.1.4
+ Binary N 1.3.6.1.4.1.1466.115.121.1.5
+ Bit String Y 1.3.6.1.4.1.1466.115.121.1.6
+ Boolean Y 1.3.6.1.4.1.1466.115.121.1.7
+ Certificate N 1.3.6.1.4.1.1466.115.121.1.8
+ Certificate List N 1.3.6.1.4.1.1466.115.121.1.9
+ Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10
+ Country String Y 1.3.6.1.4.1.1466.115.121.1.11
+ DN Y 1.3.6.1.4.1.1466.115.121.1.12
+ Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13
+ Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14
+ Directory String Y 1.3.6.1.4.1.1466.115.121.1.15
+ DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16
+ DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17
+ DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18
+ DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19
+ DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20
+ Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21
+ Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22
+ Fax N 1.3.6.1.4.1.1466.115.121.1.23
+ Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24
+ Guide Y 1.3.6.1.4.1.1466.115.121.1.25
+ IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26
+ INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27
+ JPEG N 1.3.6.1.4.1.1466.115.121.1.28
+ LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54
+ LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56
+ LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57
+ Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
+ Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30
+ Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31
+ Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32
+ MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33
+ Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55
+ Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34
+ Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35
+ Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36
+ Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37
+ Octet String Y 1.3.6.1.4.1.1466.115.121.1.40
+ OID Y 1.3.6.1.4.1.1466.115.121.1.38
+ Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39
+ Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41
+ Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42
+
+
+
+Wahl, et. al. Standards Track [Page 8]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43
+ Printable String Y 1.3.6.1.4.1.1466.115.121.1.44
+ Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58
+ Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45
+ Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46
+ Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47
+ Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48
+ Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49
+ Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50
+ Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51
+ Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52
+ UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53
+
+ A suggested minimum upper bound on the number of characters in value
+ with a string-based syntax, or the number of bytes in a value for all
+ other syntaxes, may be indicated by appending this bound count inside
+ of curly braces following the syntax name's OBJECT IDENTIFIER in an
+ Attribute Type Description. This bound is not part of the syntax
+ name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
+ server implementations should allow a string to be 64 characters
+ long, although they may allow longer strings. Note that a single
+ character of the Directory String syntax may be encoded in more than
+ one byte since UTF-8 is a variable-length encoding.
+
+4.3.3. Syntax Description
+
+ The following BNF may be used to associate a short description with a
+ syntax OBJECT IDENTIFIER. Implementors should note that future
+ versions of this document may expand this definition to include
+ additional terms. Terms whose identifier begins with "X-" are
+ reserved for private experiments, and MUST be followed by a
+ <qdstrings>.
+
+ SyntaxDescription = "(" whsp
+ numericoid whsp
+ [ "DESC" qdstring ]
+ whsp ")"
+
+4.4. Object Classes
+
+ The format for representation of object classes is defined in X.501
+ [3]. In general every entry will contain an abstract class ("top" or
+ "alias"), at least one structural object class, and zero or more
+ auxiliary object classes. Whether an object class is abstract,
+ structural or auxiliary is defined when the object class identifier
+ is assigned. An object class definition should not be changed
+ without having a new identifier assigned to it.
+
+
+
+
+Wahl, et. al. Standards Track [Page 9]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Object class descriptions are written according to the following BNF.
+ Implementors should note that future versions of this document may
+ expand this definition to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+ MUST be followed by a <qdstrings> encoding.
+
+ ObjectClassDescription = "(" whsp
+ numericoid whsp ; ObjectClass identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ [ "SUP" oids ] ; Superior ObjectClasses
+ [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
+ ; default structural
+ [ "MUST" oids ] ; AttributeTypes
+ [ "MAY" oids ] ; AttributeTypes
+ whsp ")"
+
+ These are described as sample values for the subschema
+ "objectClasses" attribute for a server which implements the LDAP
+ schema. While lines have been folded for readability, the values
+ transferred in protocol would not contain newlines.
+
+ Servers SHOULD implement all the object classes referenced in section
+ 7, except for extensibleObject, which is optional. Servers MAY
+ implement additional object classes not listed in this document, and
+ if they do so, MUST publish the definitions of the classes in the
+ objectClasses attribute of their subschema entries.
+
+ Schema developers MUST NOT create object class definitions whose
+ names conflict with attributes defined for use with LDAP in existing
+ standards-track RFCs.
+
+4.5. Matching Rules
+
+ Matching rules are used by servers to compare attribute values
+ against assertion values when performing Search and Compare
+ operations. They are also used to identify the value to be added or
+ deleted when modifying entries, and are used when comparing a
+ purported distinguished name with the name of an entry.
+
+ Most of the attributes given in this document will have an equality
+ matching rule defined.
+
+ Matching rule descriptions are written according to the following
+ BNF. Implementors should note that future versions of this document
+ may have expanded this BNF to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+
+
+
+Wahl, et. al. Standards Track [Page 10]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ MUST be followed by a <qdstrings> encoding.
+
+ MatchingRuleDescription = "(" whsp
+ numericoid whsp ; MatchingRule identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ "SYNTAX" numericoid
+ whsp ")"
+
+ Values of the matchingRuleUse list the attributes which are suitable
+ for use with an extensible matching rule.
+
+ MatchingRuleUseDescription = "(" whsp
+ numericoid whsp ; MatchingRule identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" ]
+ "APPLIES" oids ; AttributeType identifiers
+ whsp ")"
+
+ Servers which support matching rules and the extensibleMatch SHOULD
+ implement all the matching rules in section 8.
+
+ Servers MAY implement additional matching rules not listed in this
+ document, and if they do so, MUST publish the definitions of the
+ matching rules in the matchingRules attribute of their subschema
+ entries. If the server supports the extensibleMatch, then the server
+ MUST publish the relationship between the matching rules and
+ attributes in the matchingRuleUse attribute.
+
+ For example, a server which implements a privately-defined matching
+ rule for performing sound-alike matches on Directory String-valued
+ attributes would include the following in the subschema entry
+ (1.2.3.4.5 is an example, the OID of an actual matching rule would be
+ different):
+
+ matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ If this matching rule could be used with the attributes 2.5.4.41 and
+ 2.5.4.15, the following would also be present:
+
+ matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 11]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ A client could then make use of this matching rule by sending a
+ search operation in which the filter is of the extensibleMatch
+ choice, the matchingRule field is "soundAlikeMatch", and the type
+ field is "2.5.4.41" or "2.5.4.15".
+
+5. Attribute Types
+
+ All LDAP server implementations MUST recognize the attribute types
+ defined in this section.
+
+ Servers SHOULD also recognize all the attributes from section 5 of
+ [12].
+
+5.1. Standard Operational Attributes
+
+ Servers MUST maintain values of these attributes in accordance with
+ the definitions in X.501(93).
+
+5.1.1. createTimestamp
+
+ This attribute SHOULD appear in entries which were created using the
+ Add operation.
+
+ ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.2. modifyTimestamp
+
+ This attribute SHOULD appear in entries which have been modified
+ using the Modify operation.
+
+ ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.3. creatorsName
+
+ This attribute SHOULD appear in entries which were created using the
+ Add operation.
+
+ ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 12]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+5.1.4. modifiersName
+
+ This attribute SHOULD appear in entries which have been modified
+ using the Modify operation.
+
+ ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.5. subschemaSubentry
+
+ The value of this attribute is the name of a subschema entry (or
+ subentry if the server is based on X.500(93)) in which the server
+ makes available attributes specifying the schema.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
+ SINGLE-VALUE USAGE directoryOperation )
+
+5.1.6. attributeTypes
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
+
+5.1.7. objectClasses
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
+
+5.1.8. matchingRules
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 13]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+5.1.9. matchingRuleUse
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
+
+5.2. LDAP Operational Attributes
+
+ These attributes are only present in the root DSE (see [1] and [3]).
+
+ Servers MUST recognize these attribute names, but it is not required
+ that a server provide values for these attributes, when the attribute
+ corresponds to a feature which the server does not implement.
+
+5.2.1. namingContexts
+
+ The values of this attribute correspond to naming contexts which this
+ server masters or shadows. If the server does not master any
+ information (e.g. it is an LDAP gateway to a public X.500 directory)
+ this attribute will be absent. If the server believes it contains
+ the entire directory, the attribute will have a single value, and
+ that value will be the empty string (indicating the null DN of the
+ root). This attribute will allow a client to choose suitable base
+ objects for searching when it has contacted a server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
+
+5.2.2. altServer
+
+ The values of this attribute are URLs of other servers which may be
+ contacted when this server becomes unavailable. If the server does
+ not know of any other servers which could be used this attribute will
+ be absent. Clients may cache this information in case their preferred
+ LDAP server later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
+
+5.2.3. supportedExtension
+
+ The values of this attribute are OBJECT IDENTIFIERs identifying the
+ supported extended operations which the server supports.
+
+ If the server does not support any extensions this attribute will be
+ absent.
+
+
+
+Wahl, et. al. Standards Track [Page 14]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+5.2.4. supportedControl
+
+ The values of this attribute are the OBJECT IDENTIFIERs identifying
+ controls which the server supports. If the server does not support
+ any controls, this attribute will be absent.
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+5.2.5. supportedSASLMechanisms
+
+ The values of this attribute are the names of supported SASL
+ mechanisms which the server supports. If the server does not support
+ any mechanisms this attribute will be absent.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
+
+5.2.6. supportedLDAPVersion
+
+ The values of this attribute are the versions of the LDAP protocol
+ which the server implements.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
+
+5.3. LDAP Subschema Attribute
+
+ This attribute is typically located in the subschema entry.
+
+5.3.1. ldapSyntaxes
+
+ Servers MAY use this attribute to list the syntaxes which are
+ implemented. Each value corresponds to one syntax.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
+
+5.4. X.500 Subschema attributes
+
+ These attributes are located in the subschema entry. All servers
+ SHOULD recognize their name, although typically only X.500 servers
+ will implement their functionality.
+
+
+
+
+Wahl, et. al. Standards Track [Page 15]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+5.4.1. dITStructureRules
+
+ ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
+
+5.4.2. nameForms
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
+
+5.4.3. ditContentRules
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
+
+6. Syntaxes
+
+ Servers SHOULD recognize all the syntaxes described in this section.
+
+6.1. Attribute Type Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+ Values in this syntax are encoded according to the BNF given at the
+ start of section 4.2. For example,
+
+ ( 2.5.4.0 NAME 'objectClass'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+6.2. Binary
+
+ ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
+
+ Values in this syntax are encoded as described in section 4.3.1.
+
+6.3. Bit String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ bitstring = "'" *binary-digit "'B"
+
+ binary-digit = "0" / "1"
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 16]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Example:
+
+ '0101111101'B
+
+6.4. Boolean
+
+ ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ boolean = "TRUE" / "FALSE"
+
+ Boolean values have an encoding of "TRUE" if they are logically true,
+ and have an encoding of "FALSE" otherwise.
+
+6.5. Certificate
+
+ ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
+
+ Because of the changes from X.509(1988) and X.509(1993) and
+ additional changes to the ASN.1 definition to support certificate
+ extensions, no string representation is defined, and values in this
+ syntax MUST only be transferred using the binary encoding, by
+ requesting or returning the attributes with descriptions
+ "userCertificate;binary" or "caCertificate;binary". The BNF notation
+ in RFC 1778 for "User Certificate" is not recommended to be used.
+
+6.6. Certificate List
+
+ ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
+
+ Because of the incompatibility of the X.509(1988) and X.509(1993)
+ definitions of revocation lists, values in this syntax MUST only be
+ transferred using a binary encoding, by requesting or returning the
+ attributes with descriptions "certificateRevocationList;binary" or
+ "authorityRevocationList;binary". The BNF notation in RFC 1778 for
+ "Authority Revocation List" is not recommended to be used.
+
+6.7. Certificate Pair
+
+ ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
+
+ Because the Certificate is being carried in binary, values in this
+ syntax MUST only be transferred using a binary encoding, by
+ requesting or returning the attribute description
+ "crossCertificatePair;binary". The BNF notation in RFC 1778 for
+ "Certificate Pair" is not recommended to be used.
+
+
+
+
+Wahl, et. al. Standards Track [Page 17]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.8. Country String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+ A value in this syntax is encoded the same as a value of Directory
+ String syntax. Note that this syntax is limited to values of exactly
+ two printable string characters, as listed in ISO 3166 [14].
+
+ CountryString = p p
+
+ Example:
+ US
+
+6.9. DN
+
+ ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+ Values in the Distinguished Name syntax are encoded to have the
+ representation defined in [5]. Note that this representation is not
+ reversible to an ASN.1 encoding used in X.500 for Distinguished
+ Names, as the CHOICE of any DirectoryString element in an RDN is no
+ longer known.
+
+ Examples (from [5]):
+ CN=Steve Kille,O=Isode Limited,C=GB
+ OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
+ CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
+ CN=Before\0DAfter,O=Test,C=GB
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
+ SN=Lu\C4\8Di\C4\87
+
+6.10. Directory String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+ A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a
+ superset of Unicode). Servers and clients MUST be prepared to
+ receive encodings of arbitrary Unicode characters, including
+ characters not presently assigned to any character set.
+
+ For characters in the PrintableString form, the value is encoded as
+ the string value itself.
+
+ If it is of the TeletexString form, then the characters are
+ transliterated to their equivalents in UniversalString, and encoded
+ in UTF-8 [9].
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 18]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ If it is of the UniversalString or BMPString forms [10], UTF-8 is
+ used to encode them.
+
+ Note: the form of DirectoryString is not indicated in protocol unless
+ the attribute value is carried in binary. Servers which convert to
+ DAP MUST choose an appropriate form. Servers MUST NOT reject values
+ merely because they contain legal Unicode characters outside of the
+ range of printable ASCII.
+
+ Example:
+
+ This is a string of DirectoryString containing #!%#@
+
+6.11. DIT Content Rule Description
+
+
+ ues in this syntax are encoded according to the following BNF.
+ lementors should note that future versions of this document
+ have expanded this BNF to include additional terms.
+
+ 0
+
+ DITContentRuleDescription = "("
+ numericoid ; Structural ObjectClass identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" ]
+ [ "AUX" oids ] ; Auxiliary ObjectClasses
+ [ "MUST" oids ] ; AttributeType identifiers
+ [ "MAY" oids ] ; AttributeType identifiers
+ [ "NOT" oids ] ; AttributeType identifiers
+ ")"
+
+ 0 2. Facsimile Telephone Number
+
+ 3
+
+ ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ fax-number = printablestring [ "$" faxparameters ]
+
+ faxparameters = faxparm / ( faxparm "$" faxparameters )
+
+ faxparm = "twoDimensional" / "fineResolution" /
+ "unlimitedLength" /
+ "b4Length" / "a3Width" / "b4Width" / "uncompressed"
+
+
+
+Wahl, et. al. Standards Track [Page 19]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ In the above, the first printablestring is the telephone number,
+ based on E.123 [15], and the faxparm tokens represent fax parameters.
+
+6.13. Fax
+
+ ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+ Values in this syntax are encoded as if they were octet strings
+ containing Group 3 Fax images as defined in [7].
+
+6.14. Generalized Time
+
+ ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+ Values in 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 GMT time be used. For example,
+
+ 199412161032Z
+
+6.15. IA5 String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+ The encoding of a value in this syntax is the string value itself.
+
+6.16. INTEGER
+
+ ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+ Values in this syntax are encoded as the decimal representation of
+ their values, with each decimal digit represented by the its
+ character equivalent. So the number 1321 is represented by the
+ character string "1321".
+
+6.17. JPEG
+
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ Values in this syntax are encoded as strings containing JPEG images
+ in the JPEG File Interchange Format (JFIF), as described in [8].
+
+6.18. Matching Rule Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+ Values of type matchingRules are encoded as strings according to the
+ BNF given in section 4.5.
+
+
+
+Wahl, et. al. Standards Track [Page 20]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.19. Matching Rule Use Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
+ )
+
+ Values of type matchingRuleUse are encoded as strings according to
+ the BNF given in section 4.5.
+
+6.20. MHS OR Address
+
+ ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
+
+ Values in this syntax are encoded as strings, according to the format
+ defined in [11].
+
+6.21. Name And Optional UID
+
+ ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
+
+ Although the '#' character may occur in a string representation of a
+ distinguished name, no additional special quoting is done. This
+ syntax has been added subsequent to RFC 1778.
+
+ Example:
+
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+6.22. Name Form Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+ Values in this syntax are encoded according to the following BNF.
+ Implementors should note that future versions of this document may
+ have expanded this BNF to include additional terms.
+
+ NameFormDescription = "(" whsp
+ numericoid whsp ; NameForm identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ "OC" woid ; Structural ObjectClass
+ "MUST" oids ; AttributeTypes
+ [ "MAY" oids ] ; AttributeTypes
+ whsp ")"
+
+
+
+Wahl, et. al. Standards Track [Page 21]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.23. Numeric String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+ The encoding of a string in this syntax is the string value itself.
+ Example:
+
+ 1997
+
+6.24. Object Class Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+ Values in this syntax are encoded according to the BNF in section
+ 4.4.
+
+6.25. OID
+
+ ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+ Values in the Object Identifier syntax are encoded according to
+ the BNF in section 4.1 for "oid".
+
+ Example:
+
+ 1.2.3.4
+ cn
+
+6.26. Other Mailbox
+
+ ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ otherMailbox = mailbox-type "$" mailbox
+
+ mailbox-type = printablestring
+
+ mailbox = <an encoded IA5 String>
+
+ In the above, mailbox-type represents the type of mail system in
+ which the mailbox resides, for example "MCIMail"; and mailbox is the
+ actual mailbox in the mail system defined by mailbox-type.
+
+6.27. Postal Address
+
+ ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+
+
+
+Wahl, et. al. Standards Track [Page 22]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Values in this syntax are encoded according to the following BNF:
+
+ postal-address = dstring *( "$" dstring )
+
+ In the above, each dstring component of a postal address value is
+ encoded as a value of type Directory String syntax. Backslashes and
+ dollar characters, if they occur in the component, are quoted as
+ described in section 4.3. Many servers limit the postal address to
+ six lines of up to thirty characters.
+
+ Example:
+
+ 1234 Main St.$Anytown, CA 12345$USA
+ \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+6.28. Presentation Address
+
+ ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
+
+ Values in this syntax are encoded with the representation described
+ in RFC 1278 [6].
+
+6.29. Printable String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+ The encoding of a value in this syntax is the string value itself.
+ PrintableString is limited to the characters in production p of
+ section 4.1.
+
+ Example:
+
+ This is a PrintableString
+
+6.30. Telephone Number
+
+ ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+ Values in this syntax are encoded as if they were Printable String
+ types. Telephone numbers are recommended in X.520 to be in
+ international form, as described in E.123 [15].
+
+ Example:
+
+ +1 512 305 0280
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 23]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.31. UTC Time
+
+ ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+ Values in this syntax are encoded as if they were printable strings
+ with the strings containing a UTCTime value. This is historical; new
+ attribute definitions SHOULD use GeneralizedTime instead.
+
+6.32. LDAP Syntax Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+ Values in this syntax are encoded according to the BNF in section
+ 4.3.3.
+
+6.33. DIT Structure Rule Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description'
+ )
+
+ Values with this syntax are encoded according to the following BNF:
+
+ DITStructureRuleDescription = "(" whsp
+ ruleidentifier whsp ; DITStructureRule identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ "FORM" woid whsp ; NameForm
+ [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
+ ")"
+
+ ruleidentifier = integer
+
+ ruleidentifiers = ruleidentifier |
+ "(" whsp ruleidentifierlist whsp ")"
+
+ ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
+
+7. Object Classes
+
+ Servers SHOULD recognize all the names of standard classes from
+ section 7 of [12].
+
+7.1. Extensible Object Class
+
+ The extensibleObject object class, if present in an entry, permits
+ that entry to optionally hold any attribute. The MAY attribute list
+ of this class is implicitly the set of all attributes.
+
+
+
+Wahl, et. al. Standards Track [Page 24]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+ The mandatory attributes of the other object classes of this entry
+ are still required to be present.
+
+ Note that not all servers will implement this object class, and those
+ which do not will reject requests to add entries which contain this
+ object class, or modify an entry to add this object class.
+
+7.2. subschema
+
+ This object class is used in the subschema entry.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The ldapSyntaxes operational attribute may also be present in
+ subschema entries.
+
+8. Matching Rules
+
+ Servers which implement the extensibleMatch filter SHOULD allow all
+ the matching rules listed in this section to be used in the
+ extensibleMatch. In general these servers SHOULD allow matching
+ rules to be used with all attribute types known to the server, when
+ the assertion syntax of the matching rule is the same as the value
+ syntax of the attribute.
+
+ Servers MAY implement additional matching rules.
+
+8.1. Matching Rules used in Equality Filters
+
+ Servers SHOULD be capable of performing the following matching rules.
+
+ For all these rules, the assertion syntax is the same as the value
+ syntax.
+
+ ( 2.5.13.0 NAME 'objectIdentifierMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ If the client supplies a filter using an objectIdentifierMatch whose
+ matchValue oid is in the "descr" form, and the oid is not recognized
+ by the server, then the filter is Undefined.
+
+ ( 2.5.13.1 NAME 'distinguishedNameMatch'
+
+
+
+Wahl, et. al. Standards Track [Page 25]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( 2.5.13.8 NAME 'numericStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ ( 2.5.13.14 NAME 'integerMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ ( 2.5.13.16 NAME 'bitStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ ( 2.5.13.20 NAME 'telephoneNumberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ ( 2.5.13.22 NAME 'presentationAddressMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )
+
+ ( 2.5.13.23 NAME 'uniqueMemberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ ( 2.5.13.24 NAME 'protocolInformationMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+ ( 2.5.13.27 NAME 'generalizedTimeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ When performing the caseIgnoreMatch, caseIgnoreListMatch,
+ telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
+ multiple adjoining whitespace characters are treated the same as an
+ individual space, and leading and trailing whitespace is ignored.
+
+ Clients MUST NOT assume that servers are capable of transliteration
+ of Unicode values.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 26]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+8.2. Matching Rules used in Inequality Filters
+
+ Servers SHOULD be capable of performing the following matching rules,
+ which are used in greaterOrEqual and lessOrEqual filters.
+
+ ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The sort ordering for a caseIgnoreOrderingMatch is implementation-
+ dependent.
+
+8.3. Syntax and Matching Rules used in Substring Filters
+
+ The Substring Assertion syntax is used only as the syntax of
+ assertion values in the extensible match. It is not used as the
+ syntax of attributes, or in the substring filter.
+
+ ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+ The Substring Assertion is encoded according to the following BNF:
+
+ substring = [initial] any [final]
+ initial = value
+ any = "*" *(value "*")
+ final = value
+
+ The <value> production is UTF-8 encoded string. Should the backslash
+ or asterix characters be present in a production of <value>, they are
+ quoted as described in section 4.3.
+
+ Servers SHOULD be capable of performing the following matching rules,
+ which are used in substring filters.
+
+ ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 27]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+8.4. Matching Rules for Subschema Attributes
+
+ Servers which allow subschema entries to be modified by clients MUST
+ support the following matching rules, as they are the equality
+ matching rules for several of the subschema attributes.
+
+ ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ Implementors should note that the assertion syntax of these matching
+ rules, an INTEGER or OID, is different from the value syntax of
+ attributes for which this is the equality matching rule.
+
+ If the client supplies an extensible filter using an
+ objectIdentifierFirstComponentMatch whose matchValue is in the
+ "descr" form, and the OID is not recognized by the server, then the
+ filter is Undefined.
+
+9. Security Considerations
+
+9.1. Disclosure
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+9.2. Use of Attribute Values in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER or DER form. An example of a situation which requires the
+ DER form of a distinguished name is the verification of an X.509
+ certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam' would be represented in LDAP as the
+ string CN=Sam. Another distinguished name in which the value is
+ still 'Sam' but of the PrintableString choice would have the same
+ representation CN=Sam.
+
+ Applications which require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a value to LDAP format. Instead it SHOULD use the
+
+
+
+Wahl, et. al. Standards Track [Page 28]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Binary syntax.
+
+10. Acknowledgements
+
+ This document is based substantially on RFC 1778, written by Tim
+ Howes, Steve Kille, Wengyik Yeong and Colin Robbins.
+
+ Many of the attribute syntax encodings defined in this and related
+ documents are adapted from those used in the QUIPU and the IC R3
+ X.500 implementations. The contributions of the authors of both these
+ implementations in the specification of syntaxes are gratefully
+ acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 29]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+11. Authors' Addresses
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 West Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 372-3160
+ EMail: M.Wahl@critical-angle.com
+
+ Andy Coulbeck
+ Isode Inc.
+ 9390 Research Blvd Suite 305
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 231-8993
+ EMail: A.Coulbeck@isode.com
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd, MS MV068
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 937-3419
+ EMail: howes@netscape.com
+
+ Steve Kille
+ Isode Limited
+ The Dome, The Square
+ Richmond
+ TW9 1DT
+ UK
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 30]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+12. Bibliography
+
+ [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 1993.
+
+ [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+ [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [6] Kille, S., "A String Representation for Presentation Addresses",
+ RFC 1278, November 1991.
+
+ [7] Terminal Equipment and Protocols for Telematic Services -
+ Standardization of Group 3 facsimile apparatus for document
+ transmission. CCITT, Recommendation T.4.
+
+ [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton,
+ C-Cube Microsystems, Milpitas, CA, September 1, 1992.
+
+ [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+ [10] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
+ 1993 (With amendments).
+
+ [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
+ and RFC 822", RFC 1327, May 1992.
+
+ [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [14] ISO 3166, "Codes for the representation of names of countries".
+
+ [15] ITU-T Rec. E.123, Notation for national and international
+ telephone numbers, 1988.
+
+
+
+
+Wahl, et. al. Standards Track [Page 31]
+\f
+RFC 2252 LADPv3 Attributes December 1997
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 32]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2253 Critical Angle Inc.
+Obsoletes: 1779 S. Kille
+Category: Standards Track Isode Ltd.
+ T. Howes
+ Netscape Communications Corp.
+ December 1997
+
+
+ Lightweight Directory Access Protocol (v3):
+ UTF-8 String Representation of 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 (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. Proposed Standard [Page 1]
+\f
+RFC 2253 LADPv3 Distinguished Names 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.
+
+Abstract
+
+ The X.500 Directory uses distinguished names as the primary keys to
+ entries in the directory. Distinguished Names are encoded in ASN.1
+ in the X.500 Directory protocols. In the Lightweight Directory
+ Access Protocol, a string representation of distinguished names is
+ transferred. This specification defines the string format for
+ representing names, which is designed to give a clean representation
+ of commonly used distinguished names, while being able to represent
+ any distinguished name.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [6].
+
+1. Background
+
+ This specification assumes familiarity with X.500 [1], and the
+ concept of Distinguished Name. It is important to have a common
+ format to be able to unambiguously represent a distinguished name.
+ The primary goal of this specification is ease of encoding and
+ decoding. A secondary goal is to have names that are human readable.
+ It is not expected that LDAP clients with a human user interface
+ would display these strings directly to the user, but would most
+ likely be performing translations (such as expressing attribute type
+ names in one of the local national languages).
+
+2. Converting DistinguishedName from ASN.1 to a String
+
+ In X.501 [2] the ASN.1 structure of distinguished name is defined as:
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 2]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ The following sections define the algorithm for converting from an
+ ASN.1 structured representation to a UTF-8 string representation.
+
+2.1. Converting the RDNSequence
+
+ If the RDNSequence is an empty sequence, the result is the empty or
+ zero length string.
+
+ Otherwise, the output consists of the string encodings of each
+ RelativeDistinguishedName in the RDNSequence (according to 2.2),
+ starting with the last element of the sequence and moving backwards
+ toward the first.
+
+ The encodings of adjoining RelativeDistinguishedNames are separated
+ by a comma character (',' ASCII 44).
+
+2.2. Converting RelativeDistinguishedName
+
+ When converting from an ASN.1 RelativeDistinguishedName to a string,
+ the output consists of the string encodings of each
+ AttributeTypeAndValue (according to 2.3), in any order.
+
+ Where there is a multi-valued RDN, the outputs from adjoining
+ AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
+ character.
+
+2.3. Converting AttributeTypeAndValue
+
+ The AttributeTypeAndValue is encoded as the string representation of
+ the AttributeType, followed by an equals character ('=' ASCII 61),
+ followed by the string representation of the AttributeValue. The
+ encoding of the AttributeValue is given in section 2.4.
+
+ If the AttributeType is in a published table of attribute types
+ associated with LDAP [4], then the type name string from that table
+ is used, otherwise it is encoded as the dotted-decimal encoding of
+ the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
+ described in [3]. As an example, strings for a few of the attribute
+ types frequently seen in RDNs include:
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 3]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ String X.500 AttributeType
+ ------------------------------
+ CN commonName
+ L localityName
+ ST stateOrProvinceName
+ O organizationName
+ OU organizationalUnitName
+ C countryName
+ STREET streetAddress
+ DC domainComponent
+ UID userid
+
+2.4. Converting an AttributeValue from ASN.1 to a String
+
+ If the AttributeValue is of a type which does not have a string
+ representation defined for it, then it is simply encoded as an
+ octothorpe character ('#' ASCII 35) followed by the hexadecimal
+ representation of each of the bytes of the BER encoding of the X.500
+ AttributeValue. This form SHOULD be used if the AttributeType is of
+ the dotted-decimal form.
+
+ Otherwise, if the AttributeValue is of a type which has a string
+ representation, the value is converted first to a UTF-8 string
+ according to its syntax specification (see for example section 6 of
+ [4]).
+
+ If the UTF-8 string does not have any of the following characters
+ which need escaping, then that string can be used as the string
+ representation of the value.
+
+ o a space or "#" character occurring at the beginning of the
+ string
+
+ o a space character occurring at the end of the string
+
+ o one of the characters ",", "+", """, "\", "<", ">" or ";"
+
+ Implementations MAY escape other characters.
+
+ If a character to be escaped is one of the list shown above, then it
+ is prefixed by a backslash ('\' ASCII 92).
+
+ Otherwise the character to be escaped is replaced by a backslash and
+ two hex digits, which form a single byte in the code of the
+ character.
+
+ Examples of the escaping mechanism are shown in section 5.
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 4]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+3. Parsing a String back to a Distinguished Name
+
+ The structure of the string is specified in a BNF grammar, based on
+ the grammar defined in RFC 822 [5]. Server implementations parsing a
+ DN string generated by an LDAPv2 client MUST also accept (and ignore)
+ the variants given in section 4 of this document.
+
+distinguishedName = [name] ; may be empty string
+
+name = name-component *("," name-component)
+
+name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
+
+attributeTypeAndValue = attributeType "=" attributeValue
+
+attributeType = (ALPHA 1*keychar) / oid
+keychar = ALPHA / DIGIT / "-"
+
+oid = 1*DIGIT *("." 1*DIGIT)
+
+attributeValue = string
+
+string = *( stringchar / pair )
+ / "#" hexstring
+ / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
+
+quotechar = <any character except "\" or QUOTATION >
+
+special = "," / "=" / "+" / "<" / ">" / "#" / ";"
+
+pair = "\" ( special / "\" / QUOTATION / hexpair )
+stringchar = <any character except one of special, "\" or QUOTATION >
+
+hexstring = 1*hexpair
+hexpair = hexchar hexchar
+
+hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+ / "a" / "b" / "c" / "d" / "e" / "f"
+
+ALPHA = <any ASCII alphabetic character>
+ ; (decimal 65-90 and 97-122)
+DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
+QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
+
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 5]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+4. Relationship with RFC 1779 and LDAPv2
+
+ The syntax given in this document is more restrictive than the syntax
+ in RFC 1779. Implementations parsing a string generated by an LDAPv2
+ client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
+ however, generate any of the RFC 1779 encodings which are not
+ described above in section 2.
+
+ Implementations MUST allow a semicolon character to be used instead
+ of a comma to separate RDNs in a distinguished name, and MUST also
+ allow whitespace characters to be present on either side of the comma
+ or semicolon. The whitespace characters are ignored, and the
+ semicolon replaced with a comma.
+
+ Implementations MUST allow an oid in the attribute type to be
+ prefixed by one of the character strings "oid." or "OID.".
+
+ Implementations MUST allow for space (' ' ASCII 32) characters to be
+ present between name-component and ',', between attributeTypeAndValue
+ and '+', between attributeType and '=', and between '=' and
+ attributeValue. These space characters are ignored when parsing.
+
+ Implementations MUST allow a value to be surrounded by quote ('"'
+ ASCII 34) characters, which are not part of the value. Inside the
+ quoted value, the following characters can occur without any
+ escaping:
+
+ ",", "=", "+", "<", ">", "#" and ";"
+
+5. Examples
+
+ This notation is designed to be convenient for common forms of name.
+ This section gives a few examples of distinguished names written
+ using this notation. First is a name containing three relative
+ distinguished names (RDNs):
+
+ CN=Steve Kille,O=Isode Limited,C=GB
+
+ Here is an example name containing three RDNs, in which the first RDN
+ is multi-valued:
+
+ OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
+
+ This example shows the method of quoting of a comma in an
+ organization name:
+
+ CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 6]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ An example name in which a value contains a carriage return
+ character:
+
+ CN=Before\0DAfter,O=Test,C=GB
+
+ An example name in which an RDN was of an unrecognized type. The
+ value is the BER encoding of an OCTET STRING containing two bytes
+ 0x48 and 0x69.
+
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
+
+ Finally, an example of an RDN surname value consisting of 5 letters:
+
+ Unicode Letter Description 10646 code UTF-8 Quoted
+ =============================== ========== ====== =======
+ LATIN CAPITAL LETTER L U0000004C 0x4C L
+ LATIN SMALL LETTER U U00000075 0x75 u
+ LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
+ LATIN SMALL LETTER I U00000069 0x69 i
+ LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
+
+ Could be written in printable ASCII (useful for debugging purposes):
+
+ SN=Lu\C4\8Di\C4\87
+
+6. References
+
+ [1] The Directory -- overview of concepts, models and services.
+ ITU-T Rec. X.500(1993).
+
+ [2] The Directory -- Models. ITU-T Rec. X.501(1993).
+
+ [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 7]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+7. Security Considerations
+
+7.1. Disclosure
+
+ Distinguished Names typically consist of descriptive information
+ about the entries they name, which can be people, organizations,
+ devices or other real-world objects. This frequently includes some
+ of the following kinds of information:
+
+ - the common name of the object (i.e. a person's full name)
+ - an email or TCP/IP address
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or affiliation)
+
+ Most countries have privacy laws regarding the publication of
+ information about people.
+
+7.2. Use of Distinguished Names in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER or DER form. An example of a situation which requires the
+ DER form of a distinguished name is the verification of an X.509
+ certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam' would be represented in LDAP as the
+ string CN=Sam. Another distinguished name in which the value is
+ still 'Sam' but of the PrintableString choice would have the same
+ representation CN=Sam.
+
+ Applications which require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a distinguished name to the LDAP format. Instead,
+ they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
+ as described in the first paragraph of section 2.4.
+
+8. Authors' Addresses
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 W. Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ EMail: M.Wahl@critical-angle.com
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 8]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ Steve Kille
+ Isode Ltd.
+ The Dome
+ The Square
+ Richmond, Surrey
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille@ISODE.COM
+
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd, MS MV068
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 937-3419
+ EMail: howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 9]
+\f
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 10]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 2254 Netscape Communications Corp.
+Category: Standards Track December 1997
+
+
+ The String Representation of LDAP Search Filters
+
+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.
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 1]
+\f
+RFC 2254 String Representation of LDAP 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.
+
+2. 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.
+
+ This document replaces RFC 1960, extending the string LDAP filter
+ definition to include support for LDAP version 3 extended match
+ filters, and including support for representing the full range of
+ possible LDAP search filters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 2]
+\f
+RFC 2254 String Representation of LDAP December 1997
+
+
+3. LDAP Search Filter Definition
+
+ An LDAPv3 search filter is defined in Section 4.5.1 of [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] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion
+ }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString
+ }
+ }
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ attributeValue AttributeValue
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleID OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE
+ }
+
+ AttributeDescription ::= LDAPString
+
+ AttributeValue ::= OCTET STRING
+
+ MatchingRuleID ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
+
+ LDAPString ::= OCTET STRING
+
+
+
+Howes Standards Track [Page 3]
+\f
+RFC 2254 String Representation of LDAP December 1997
+
+
+ where the LDAPString above is limited to the UTF-8 encoding of the
+ ISO 10646 character set [4]. The AttributeDescription is a string
+ representation of the attribute description and is defined in [1].
+ The AttributeValue and AssertionValue OCTET STRING have 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].
+
+4. String Search Filter Definition
+
+ The string representation of an LDAP search filter is defined by the
+ following grammar, following the ABNF notation defined in [5]. The
+ filter format uses a prefix notation.
+
+ filter = "(" filtercomp ")"
+ filtercomp = and / or / not / item
+ and = "&" filterlist
+ or = "|" filterlist
+ not = "!" filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype value
+ filtertype = equal / approx / greater / less
+ equal = "="
+ approx = "~="
+ greater = ">="
+ less = "<="
+ extensible = attr [":dn"] [":" matchingrule] ":=" value
+ / [":dn"] ":" matchingrule ":=" value
+ present = attr "=*"
+ substring = attr "=" [initial] any [final]
+ initial = value
+ any = "*" *(value "*")
+ final = value
+ attr = AttributeDescription from Section 4.1.5 of [1]
+ matchingrule = MatchingRuleId from Section 4.1.9 of [1]
+ value = AttributeValue from Section 4.1.6 of [1]
+
+ The attr, matchingrule, and value constructs are as described in the
+ corresponding section of [1] given above.
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 4]
+\f
+RFC 2254 String Representation of LDAP December 1997
+
+
+ If a value should contain any of the following characters
+
+ Character ASCII value
+ ---------------------------
+ * 0x2a
+ ( 0x28
+ ) 0x29
+ \ 0x5c
+ NUL 0x00
+
+ the character must be encoded as the backslash '\' character (ASCII
+ 0x5c) followed by the two hexadecimal digits representing the ASCII
+ value of the encoded character. The case of the two hexadecimal
+ digits is not significant.
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other characters besides the
+ ones listed above may be escaped using this mechanism, for example,
+ non-printing characters.
+
+ For example, the filter checking whether the "cn" attribute contained
+ a value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ Note that although both the substring and present productions in the
+ grammar above can produce the "attr=*" construct, this construct is
+ used only to denote a presence filter.
+
+5. 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*)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:1.2.3.4.5:=Fred Flintstone)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:dn:2.4.6.8.10:=Dino)
+
+
+
+
+
+
+Howes Standards Track [Page 5]
+\f
+RFC 2254 String Representation of LDAP December 1997
+
+
+ The second example illustrates the use of the ":dn" notation to
+ indicate that matching rule "2.4.6.8.10" should be used when making
+ comparisons, and that the attributes of an entry's distinguished name
+ should be considered part of the entry when evaluating the match.
+
+ The third example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ The fourth example is a filter that should be applied to any
+ attribute supporting the matching rule given (since the attr has been
+ left off). Attributes supporting the matching rule contained in the
+ DN should also be considered.
+
+ The following examples illustrate the use of the escaping mechanism.
+
+ (o=Parens R Us \28for all your parenthetical needs\29)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (sn=Lu\c4\8di\c4\87)
+
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent a
+ "*" in a value, preventing it from being interpreted as a substring
+ indicator. The third illustrates the escaping of the backslash
+ character.
+
+ The fourth example shows a filter searching for the four-byte value
+ 0x00000004, illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The final example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters.
+
+6. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 6]
+\f
+RFC 2254 String Representation of LDAP December 1997
+
+
+7. References
+
+ [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+ 2252, December 1997.
+
+ [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
+ Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
+
+ [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+ [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+8. Author's Address
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Road
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3419
+ EMail: howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 7]
+\f
+RFC 2254 String Representation of LDAP December 1997
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 8]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 2255 M. Smith
+Category: Standards Track Netscape Communications Corp.
+ December 1997
+
+
+ The LDAP URL Format
+
+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.
+
+
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 1]
+\f
+RFC 2255 LDAP URL Format 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.
+
+2. Abstract
+
+ LDAP is the Lightweight Directory Access Protocol, defined in [1],
+ [2] and [3]. This document describes a format for an LDAP Uniform
+ Resource Locator. The format describes an LDAP search operation to
+ perform to retrieve information from an LDAP directory. This document
+ replaces RFC 1959. It updates the LDAP URL format for version 3 of
+ LDAP and clarifies how LDAP URLs are resolved. This document also
+ defines an extension mechanism for LDAP URLs, so that future
+ documents can extend their functionality, for example, to provide
+ access to new LDAPv3 extensions as they are defined.
+
+ The key words "MUST", "MAY", and "SHOULD" used in this document are
+ to be interpreted as described in [6].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 2]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+3. URL Definition
+
+ An LDAP URL begins with the protocol prefix "ldap" and is defined by
+ the following grammar.
+
+ ldapurl = scheme "://" [hostport] ["/"
+ [dn ["?" [attributes] ["?" [scope]
+ ["?" [filter] ["?" extensions]]]]]]
+ scheme = "ldap"
+ attributes = attrdesc *("," attrdesc)
+ scope = "base" / "one" / "sub"
+ dn = distinguishedName from Section 3 of [1]
+ hostport = hostport from Section 5 of RFC 1738 [5]
+ attrdesc = AttributeDescription from Section 4.1.5 of [2]
+ filter = filter from Section 4 of [4]
+ extensions = extension *("," extension)
+ extension = ["!"] extype ["=" exvalue]
+ extype = token / xtoken
+ exvalue = LDAPString from section 4.1.2 of [2]
+ token = oid from section 4.1 of [3]
+ xtoken = ("X-" / "x-") token
+
+ The "ldap" prefix indicates an entry or entries residing in the LDAP
+ server running on the given hostname at the given portnumber. The
+ default LDAP port is TCP port 389. If no hostport is given, the
+ client must have some apriori knowledge of an appropriate LDAP server
+ to contact.
+
+ The dn is an LDAP Distinguished Name using the string format
+ described in [1]. It identifies the base object of the LDAP search.
+
+ ldapurl = scheme "://" [hostport] ["/"
+ [dn ["?" [attributes] ["?" [scope]
+ ["?" [filter] ["?" extensions]]]]]]
+ scheme = "ldap"
+ attributes = attrdesc *("," attrdesc)
+ scope = "base" / "one" / "sub"
+ dn = distinguishedName from Section 3 of [1]
+ hostport = hostport from Section 5 of RFC 1738 [5]
+ attrdesc = AttributeDescription from Section 4.1.5 of [2]
+ filter = filter from Section 4 of [4]
+ extensions = extension *("," extension)
+ extension = ["!"] extype ["=" exvalue]
+ extype = token / xtoken
+ exvalue = LDAPString from section 4.1.2 of [2]
+ token = oid from section 4.1 of [3]
+ xtoken = ("X-" / "x-") token
+
+
+
+
+Howes & Smith Standards Track [Page 3]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+ The "ldap" prefix indicates an entry or entries residing in the LDAP
+ server running on the given hostname at the given portnumber. The
+ default LDAP port is TCP port 389. If no hostport is given, the
+ client must have some apriori knowledge of an appropriate LDAP server
+ to contact.
+
+ The dn is an LDAP Distinguished Name using the string format
+ described in [1]. It identifies the base object of the LDAP search.
+
+ The attributes construct is used to indicate which attributes should
+ be returned from the entry or entries. Individual attrdesc names are
+ as defined for AttributeDescription in [2]. If the attributes part
+ is omitted, all user attributes of the entry or entries should be
+ requested (e.g., by setting the attributes field
+ AttributeDescriptionList in the LDAP search request to a NULL list,
+ or (in LDAPv3) by requesting the special attribute name "*").
+
+ The scope construct is used to specify the scope of the search to
+ perform in the given LDAP server. The allowable scopes are "base"
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search. If scope is omitted, a scope of "base" is assumed.
+
+ The filter is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [4]. If filter is omitted, a filter of
+ "(objectClass=*)" is assumed.
+
+ The extensions construct provides the LDAP URL with an extensibility
+ mechanism, allowing the capabilities of the URL to be extended in the
+ future. Extensions are a simple comma-separated list of type=value
+ pairs, where the =value portion MAY be omitted for options not
+ requiring it. Each type=value pair is a separate extension. These
+ LDAP URL extensions are not necessarily related to any of the LDAPv3
+ extension mechanisms. Extensions may be supported or unsupported by
+ the client resolving the URL. An extension prefixed with a '!'
+ character (ASCII 33) is critical. An extension not prefixed with a '
+ !' character is non-critical.
+
+ If an extension is supported by the client, the client MUST obey the
+ extension if the extension is critical. The client SHOULD obey
+ supported extensions that are non-critical.
+
+ If an extension is unsupported by the client, the client MUST NOT
+ process the URL if the extension is critical. If an unsupported
+ extension is non-critical, the client MUST ignore the extension.
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 4]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+ If a critical extension cannot be processed successfully by the
+ client, the client MUST NOT process the URL. If a non-critical
+ extension cannot be processed successfully by the client, the client
+ SHOULD ignore the extension.
+
+ Extension types prefixed by "X-" or "x-" are reserved for use in
+ bilateral agreements between communicating parties. Other extension
+ types MUST be defined in this document, or in other standards-track
+ documents.
+
+ One LDAP URL extension is defined in this document in the next
+ section. Other documents or a future version of this document MAY
+ define other extensions.
+
+ Note that any URL-illegal characters (e.g., spaces), URL special
+ characters (as defined in section 2.2 of RFC 1738) and the reserved
+ character '?' (ASCII 63) occurring inside a dn, filter, or other
+ element of an LDAP URL MUST be escaped using the % method described
+ in RFC 1738 [5]. If a comma character ',' occurs inside an extension
+ value, the character MUST also be escaped using the % method.
+
+4. The Bindname Extension
+
+ This section defines an LDAP URL extension for representing the
+ distinguished name for a client to use when authenticating to an LDAP
+ directory during resolution of an LDAP URL. Clients MAY implement
+ this extension.
+
+ The extension type is "bindname". The extension value is the
+ distinguished name of the directory entry to authenticate as, in the
+ same form as described for dn in the grammar above. The dn may be the
+ NULL string to specify unauthenticated access. The extension may be
+ either critical (prefixed with a '!' character) or non-critical (not
+ prefixed with a '!' character).
+
+ If the bindname extension is critical, the client resolving the URL
+ MUST authenticate to the directory using the given distinguished name
+ and an appropriate authentication method. Note that for a NULL
+ distinguished name, no bind MAY be required to obtain anonymous
+ access to the directory. If the extension is non-critical, the client
+ MAY bind to the directory using the given distinguished name.
+
+5. URL Processing
+
+ This section describes how an LDAP URL SHOULD be resolved by a
+ client.
+
+
+
+
+
+Howes & Smith Standards Track [Page 5]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+ First, the client obtains a connection to the LDAP server referenced
+ in the URL, or an LDAP server of the client's choice if no LDAP
+ server is explicitly referenced. This connection MAY be opened
+ specifically for the purpose of resolving the URL or the client MAY
+ reuse an already open connection. The connection MAY provide
+ confidentiality, integrity, or other services, e.g., using TLS. Use
+ of security services is at the client's discretion if not specified
+ in the URL.
+
+ Next, the client authenticates itself to the LDAP server. This step
+ is optional, unless the URL contains a critical bindname extension
+ with a non-NULL value. If a bindname extension is given, the client
+ proceeds according to the section above.
+
+ If a bindname extension is not specified, the client MAY bind to the
+ directory using a appropriate dn and authentication method of its own
+ choosing (including NULL authentication).
+
+ Next, the client performs the LDAP search operation specified in the
+ URL. Additional fields in the LDAP protocol search request, such as
+ sizelimit, timelimit, deref, and anything else not specified or
+ defaulted in the URL specification, MAY be set at the client's
+ discretion.
+
+ Once the search has completed, the client MAY close the connection to
+ the LDAP server, or the client MAY keep the connection open for
+ future use.
+
+6. Examples
+
+ The following are some example LDAP URLs using the format defined
+ above. The first example is an LDAP URL referring to the University
+ of Michigan entry, available from an LDAP server of the client's
+ choosing:
+
+ ldap:///o=University%20of%20Michigan,c=US
+
+ The next example is an LDAP URL referring to the University of
+ Michigan entry in a particular ldap server:
+
+ ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
+
+ Both of these URLs correspond to a base object search of the
+ "o=University of Michigan, c=US" entry using a filter of
+ "(objectclass=*)", requesting all attributes.
+
+ The next example is an LDAP URL referring to only the postalAddress
+ attribute of the University of Michigan entry:
+
+
+
+Howes & Smith Standards Track [Page 6]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+ ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
+ c=US?postalAddress
+
+ The corresponding LDAP search operation is the same as in the
+ previous example, except that only the postalAddress attribute is
+ requested.
+
+ The next example is an LDAP URL referring to the set of entries found
+ by querying the given LDAP server on port 6666 and doing a subtree
+ search of the University of Michigan for any entry with a common name
+ of "Babs Jensen", retrieving all attributes:
+
+ ldap://host.com:6666/o=University%20of%20Michigan,
+ c=US??sub?(cn=Babs%20Jensen)
+
+ The next example is an LDAP URL referring to all children of the c=GB
+ entry:
+
+ ldap://ldap.itd.umich.edu/c=GB?objectClass?one
+
+ The objectClass attribute is requested to be returned along with the
+ entries, and the default filter of "(objectclass=*)" is used.
+
+ The next example is an LDAP URL to retrieve the mail attribute for
+ the LDAP entry named "o=Question?,c=US" is given below, illustrating
+ the use of the escaping mechanism on the reserved character '?'.
+
+ ldap://ldap.question.com/o=Question%3f,c=US?mail
+
+ The next example illustrates the interaction between LDAP and URL
+ quoting mechanisms.
+
+ ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
+
+ The filter in this example uses the LDAP escaping mechanism of \ to
+ encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (int=\00\00\00\04). Because the \ character must
+ be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
+
+ The final example shows the use of the bindname extension to specify
+ the dn a client should use for authentication when resolving the URL.
+
+ ldap:///??sub??bindname=cn=Manager%2co=Foo
+ ldap:///??sub??!bindname=cn=Manager%2co=Foo
+
+ The two URLs are the same, except that the second one marks the
+ bindname extension as critical. Notice the use of the % encoding
+ method to encode the comma in the distinguished name value in the
+
+
+
+Howes & Smith Standards Track [Page 7]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+ bindname extension.
+
+7. Security Considerations
+
+ General URL security considerations discussed in [5] are relevant for
+ LDAP URLs.
+
+ The use of security mechanisms when processing LDAP URLs requires
+ particular care, since clients may encounter many different servers
+ via URLs, and since URLs are likely to be processed automatically,
+ without user intervention. A client SHOULD have a user-configurable
+ policy about which servers to connect to using which security
+ mechanisms, and SHOULD NOT make connections that are inconsistent
+ with this policy.
+
+ Sending authentication information, no matter the mechanism, may
+ violate a user's privacy requirements. In the absence of specific
+ policy permitting authentication information to be sent to a server,
+ a client should use an anonymous connection. (Note that clients
+ conforming to previous LDAP URL specifications, where all connections
+ are anonymous and unprotected, are consistent with this
+ specification; they simply have the default security policy.)
+
+ Some authentication methods, in particular reusable passwords sent to
+ the server, may reveal easily-abused information to the remote server
+ or to eavesdroppers in transit, and should not be used in URL
+ processing unless explicitly permitted by policy. Confirmation by
+ the human user of the use of authentication information is
+ appropriate in many circumstances. Use of strong authentication
+ methods that do not reveal sensitive information is much preferred.
+
+ The LDAP URL format allows the specification of an arbitrary LDAP
+ search operation to be performed when evaluating the LDAP URL.
+ Following an LDAP URL may cause unexpected results, for example, the
+ retrieval of large amounts of data, the initiation of a long-lived
+ search, etc. The security implications of resolving an LDAP URL are
+ the same as those of resolving an LDAP search query.
+
+8. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 8]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+ Several people have made valuable comments on this document. In
+ particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
+ their contributions.
+
+9. References
+
+ [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished Names",
+ RFC 2253, December 1997.
+
+ [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+ 2252, December 1997.
+
+ [4] Howes, T., "A String Representation of LDAP Search Filters", RFC
+ 2254, December 1997.
+
+ [5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+ Locators (URL)," RFC 1738, December 1994.
+
+ [6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels," RFC 2119, March 1997.
+
+Authors' Addresses
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3419
+ EMail: howes@netscape.com
+
+
+ Mark Smith
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3477
+ EMail: mcs@netscape.com
+
+
+
+
+
+Howes & Smith Standards Track [Page 9]
+\f
+RFC 2255 LDAP URL Format December 1997
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 10]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2256 Critical Angle Inc.
+Category: Standards Track December 1997
+
+
+ A Summary of the X.500(96) User Schema for use with LDAPv3
+
+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.
+
+ 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.
+
+
+
+Wahl Standards Track [Page 1]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ 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.
+
+2. Abstract
+
+ This document provides an overview of the attribute types and object
+ classes defined by the ISO and ITU-T committees in the X.500
+ documents, in particular those intended for use by directory clients.
+ This is the most widely used schema for LDAP/X.500 directories, and
+ many other schema definitions for white pages objects use it as a
+ basis. This document does not cover attributes used for the
+ administration of X.500 directory servers, nor does it include
+ attributes defined by other ISO/ITU-T documents.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [6].
+
+3. General Issues
+
+ This document references syntaxes given in section 6 of this document
+ and section 6 of [1]. Matching rules are listed in section 8 of this
+ document and section 8 of [1].
+
+ The attribute type and object class definitions are written using the
+ BNF form of AttributeTypeDescription and ObjectClassDescription given
+ in [1]. Lines have been folded for readability.
+
+4. Source
+
+ The schema definitions in this document are based on those found in
+ X.500 [2],[3],[4],[5], and updates to these documents, specifically:
+
+ Sections Source
+ ============ ============
+ 5.1 - 5.2 X.501(93)
+ 5.3 - 5.36 X.520(88)
+ 5.37 - 5.41 X.509(93)
+ 5.42 - 5.52 X.520(93)
+ 5.53 - 5.54 X.509(96)
+ 5.55 X.520(96)
+ 6.1 RFC 1274
+ 6.2 (new syntax)
+ 6.3 - 6.6 RFC 1274
+ 7.1 - 7.2 X.501(93)
+ 7.3 - 7.18 X.521(93)
+
+
+
+Wahl Standards Track [Page 2]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ 7.19 - 7.21 X.509(96)
+ 7.22 X.521(96)
+
+ Some attribute names are different from those found in X.520(93).
+
+ Three new attributes supportedAlgorithms, deltaRevocationList and
+ dmdName, and the objectClass dmd, are defined in the X.500(96)
+ documents.
+
+5. Attribute Types
+
+ An LDAP server implementation SHOULD recognize the attribute types
+ described in this section.
+
+5.1. objectClass
+
+ The values of the objectClass attribute describe the kind of object
+ which an entry represents. The objectClass attribute is present in
+ every entry, with at least two values. One of the values is either
+ "top" or "alias".
+
+ ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+5.2. aliasedObjectName
+
+ The aliasedObjectName attribute is used by the directory service if
+ the entry containing this attribute is an alias.
+
+ ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+5.3. knowledgeInformation
+
+ This attribute is no longer used.
+
+ ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.4. cn
+
+ This is the X.500 commonName attribute, which contains a name of an
+ object. If the object corresponds to a person, it is typically the
+ person's full name.
+
+ ( 2.5.4.3 NAME 'cn' SUP name )
+
+
+
+
+
+Wahl Standards Track [Page 3]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.5. sn
+
+ This is the X.500 surname attribute, which contains the family name
+ of a person.
+
+ ( 2.5.4.4 NAME 'sn' SUP name )
+
+5.6. serialNumber
+
+ This attribute contains the serial number of a device.
+
+ ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+
+5.7. c
+
+ This attribute contains a two-letter ISO 3166 country code
+ (countryName).
+
+ ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
+
+5.8. l
+
+ This attribute contains the name of a locality, such as a city,
+ county or other geographic region (localityName).
+
+ ( 2.5.4.7 NAME 'l' SUP name )
+
+5.9. st
+
+ This attribute contains the full name of a state or province
+ (stateOrProvinceName).
+
+ ( 2.5.4.8 NAME 'st' SUP name )
+
+5.10. street
+
+ This attribute contains the physical address of the object to which
+ the entry corresponds, such as an address for package delivery
+ (streetAddress).
+
+ ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+
+Wahl Standards Track [Page 4]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.11. o
+
+ This attribute contains the name of an organization
+ (organizationName).
+
+ ( 2.5.4.10 NAME 'o' SUP name )
+
+5.12. ou
+
+ This attribute contains the name of an organizational unit
+ (organizationalUnitName).
+
+ ( 2.5.4.11 NAME 'ou' SUP name )
+
+5.13. title
+
+ This attribute contains the title, such as "Vice President", of a
+ person in their organizational context. The "personalTitle"
+ attribute would be used for a person's title independent of their job
+ function.
+
+ ( 2.5.4.12 NAME 'title' SUP name )
+
+5.14. description
+
+ This attribute contains a human-readable description of the object.
+
+ ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+5.15. searchGuide
+
+ This attribute is for use by X.500 clients in constructing search
+ filters. It is obsoleted by enhancedSearchGuide, described below in
+ 5.48.
+
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+5.16. businessCategory
+
+ This attribute describes the kind of business performed by an
+ organization.
+
+ ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+Wahl Standards Track [Page 5]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.17. postalAddress
+
+ ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+5.18. postalCode
+
+ ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+5.19. postOfficeBox
+
+ ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+5.20. physicalDeliveryOfficeName
+
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+5.21. telephoneNumber
+
+ ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+5.22. telexNumber
+
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+5.23. teletexTerminalIdentifier
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+5.24. facsimileTelephoneNumber
+
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+
+
+
+
+
+
+Wahl Standards Track [Page 6]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.25. x121Address
+
+ ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+5.26. internationaliSDNNumber
+
+ ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+
+5.27. registeredAddress
+
+ This attribute holds a postal address suitable for reception of
+ telegrams or expedited documents, where it is necessary to have the
+ recipient accept delivery.
+
+ ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+5.28. destinationIndicator
+
+ This attribute is used for the telegram service.
+
+ ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+5.29. preferredDeliveryMethod
+
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+5.30. presentationAddress
+
+ This attribute contains an OSI presentation address.
+
+ ( 2.5.4.29 NAME 'presentationAddress'
+ EQUALITY presentationAddressMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
+ SINGLE-VALUE )
+
+
+
+
+
+
+
+
+Wahl Standards Track [Page 7]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.31. supportedApplicationContext
+
+ This attribute contains the identifiers of OSI application contexts.
+
+ ( 2.5.4.30 NAME 'supportedApplicationContext'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+5.32. member
+
+ ( 2.5.4.31 NAME 'member' SUP distinguishedName )
+
+5.33. owner
+
+ ( 2.5.4.32 NAME 'owner' SUP distinguishedName )
+
+5.34. roleOccupant
+
+ ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )
+
+5.35. seeAlso
+
+ ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )
+
+5.36. userPassword
+
+ ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ Passwords are stored using an Octet String syntax and are not
+ encrypted. Transfer of cleartext passwords are strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the password to
+ unauthorized parties.
+
+5.37. userCertificate
+
+ This attribute is to be stored and requested in the binary form, as
+ 'userCertificate;binary'.
+
+ ( 2.5.4.36 NAME 'userCertificate'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+5.38. cACertificate
+
+ This attribute is to be stored and requested in the binary form, as
+ 'cACertificate;binary'.
+
+
+
+
+Wahl Standards Track [Page 8]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ ( 2.5.4.37 NAME 'cACertificate'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+5.39. authorityRevocationList
+
+ This attribute is to be stored and requested in the binary form, as
+ 'authorityRevocationList;binary'.
+
+ ( 2.5.4.38 NAME 'authorityRevocationList'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.40. certificateRevocationList
+
+ This attribute is to be stored and requested in the binary form, as
+ 'certificateRevocationList;binary'.
+
+ ( 2.5.4.39 NAME 'certificateRevocationList'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.41. crossCertificatePair
+
+ This attribute is to be stored and requested in the binary form, as
+ 'crossCertificatePair;binary'.
+
+ ( 2.5.4.40 NAME 'crossCertificatePair'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+5.42. name
+
+ The name attribute type is the attribute supertype from which string
+ attribute types typically used for naming may be formed. It is
+ unlikely that values of this type itself will occur in an entry. LDAP
+ server implementations which do not support attribute subtyping need
+ not recognize this attribute in requests. Client implementations
+ MUST NOT assume that LDAP servers are capable of performing attribute
+ subtyping.
+
+ ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.43. givenName
+
+ The givenName attribute is used to hold the part of a person's name
+ which is not their surname nor middle name.
+
+ ( 2.5.4.42 NAME 'givenName' SUP name )
+
+
+
+
+Wahl Standards Track [Page 9]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.44. initials
+
+ The initials attribute contains the initials of some or all of an
+ individuals names, but not the surname(s).
+
+ ( 2.5.4.43 NAME 'initials' SUP name )
+
+5.45. generationQualifier
+
+ The generationQualifier attribute contains the part of the name which
+ typically is the suffix, as in "IIIrd".
+
+ ( 2.5.4.44 NAME 'generationQualifier' SUP name )
+
+5.46. x500UniqueIdentifier
+
+ The x500UniqueIdentifier attribute is used to distinguish between
+ objects when a distinguished name has been reused. This is a
+ different attribute type from both the "uid" and "uniqueIdentifier"
+ types.
+
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+5.47. dnQualifier
+
+ The dnQualifier attribute type specifies disambiguating information
+ to add to the relative distinguished name of an entry. It is
+ intended for use when merging data from multiple sources in order to
+ prevent conflicts between entries which would otherwise have the same
+ name. It is recommended that the value of the dnQualifier attribute
+ be the same for all entries from a particular source.
+
+ ( 2.5.4.46 NAME 'dnQualifier' EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+5.48. enhancedSearchGuide
+
+ This attribute is for use by X.500 clients in constructing search
+ filters.
+
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+
+
+
+
+
+
+Wahl Standards Track [Page 10]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.49. protocolInformation
+
+ This attribute is used in conjunction with the presentationAddress
+ attribute, to provide additional information to the OSI network
+ service.
+
+ ( 2.5.4.48 NAME 'protocolInformation'
+ EQUALITY protocolInformationMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+5.50. distinguishedName
+
+ This attribute type is not used as the name of the object itself, but
+ it is instead a base type from which attributes with DN syntax
+ inherit.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+
+ ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+5.51. uniqueMember
+
+ ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+5.52. houseIdentifier
+
+ This attribute is used to identify a building within a location.
+
+ ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.53. supportedAlgorithms
+
+ This attribute is to be stored and requested in the binary form, as
+ 'supportedAlgorithms;binary'.
+
+ ( 2.5.4.52 NAME 'supportedAlgorithms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+
+
+
+
+
+Wahl Standards Track [Page 11]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.54. deltaRevocationList
+
+ This attribute is to be stored and requested in the binary form, as
+ 'deltaRevocationList;binary'.
+
+ ( 2.5.4.53 NAME 'deltaRevocationList'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.55. dmdName
+
+ The value of this attribute specifies a directory management domain
+ (DMD), the administrative authority which operates the directory
+ server.
+
+ ( 2.5.4.54 NAME 'dmdName' SUP name )
+
+6. Syntaxes
+
+ Servers SHOULD recognize the syntaxes defined in this section. Each
+ syntax begins with a sample value of the ldapSyntaxes attribute which
+ defines the OBJECT IDENTIFIER of the syntax. The descriptions of
+ syntax names are not carried in protocol, and are not guaranteed to
+ be unique.
+
+6.1. Delivery Method
+
+ ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
+
+ pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+ "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+ Example:
+
+ telephone
+
+6.2. Enhanced Guide
+
+ ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset
+
+ subset = "baseobject" / "oneLevel" / "wholeSubtree"
+
+
+
+Wahl Standards Track [Page 12]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ The criteria production is defined in the Guide syntax below. This
+ syntax has been added subsequent to RFC 1778.
+
+ Example:
+
+ person#(sn)#oneLevel
+
+6.3. Guide
+
+ ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ guide-value = [ object-class "#" ] criteria
+
+ object-class = woid
+
+ criteria = criteria-item / criteria-set / ( "!" criteria )
+
+ criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) /
+ ( [ "(" ] criteria "|" criteria-set [ ")" ] )
+
+ criteria-item = [ "(" ] attributetype "$" match-type [ ")" ]
+
+ match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+
+ This syntax should not be used for defining new attributes.
+
+6.4. Octet String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+ Values in this syntax are encoded as octet strings.
+
+
+ Example:
+
+ secret
+
+6.5. Teletex Terminal Identifier
+
+ ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ teletex-id = ttx-term 0*("$" ttx-param)
+
+ ttx-term = printablestring
+
+
+
+Wahl Standards Track [Page 13]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ ttx-param = ttx-key ":" ttx-value
+
+ ttx-key = "graphic" / "control" / "misc" / "page" / "private"
+
+ ttx-value = octetstring
+
+ In the above, the first printablestring is the encoding of the first
+ portion of the teletex terminal identifier to be encoded, and the
+ subsequent 0 or more octetstrings are subsequent portions of the
+ teletex terminal identifier.
+
+6.6. Telex Number
+
+ ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ telex-number = actual-number "$" country "$" answerback
+
+ actual-number = printablestring
+
+ country = printablestring
+
+ answerback = printablestring
+
+ In the above, actual-number is the syntactic representation of the
+ number portion of the TELEX number being encoded, country is the
+ TELEX country code, and answerback is the answerback code of a TELEX
+ terminal.
+
+6.7. Supported Algorithm
+
+ ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' )
+
+ No printable representation of values of the supportedAlgorithms
+ attribute is defined in this document. Clients which wish to store
+ and retrieve this attribute MUST use "supportedAlgorithms;binary", in
+ which the value is transferred as a binary encoding.
+
+7. Object Classes
+
+ LDAP servers MUST recognize the object classes "top" and "subschema".
+ LDAP servers SHOULD recognize all the other object classes listed
+ here as values of the objectClass attribute.
+
+7.1. top
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+
+
+Wahl Standards Track [Page 14]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+7.2. alias
+
+ ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
+
+7.3. country
+
+ ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+ MAY ( searchGuide $ description ) )
+
+7.4. locality
+
+ ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
+ MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
+
+7.5. organization
+
+ ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+7.6. organizationalUnit
+
+ ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+7.7. person
+
+ ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
+ MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
+
+7.8. organizationalPerson
+
+ ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $
+ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+
+
+
+Wahl Standards Track [Page 15]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l ) )
+
+7.9. organizationalRole
+
+ ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+
+7.10. groupOfNames
+
+ ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+7.11. residentialPerson
+
+ ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+
+7.12. applicationProcess
+
+ ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn
+ MAY ( seeAlso $ ou $ l $ description ) )
+
+7.13. applicationEntity
+
+ ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
+ MUST ( presentationAddress $ cn )
+ MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
+ description ) )
+
+7.14. dSA
+
+ ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
+ MAY knowledgeInformation )
+
+
+
+
+Wahl Standards Track [Page 16]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+7.15. device
+
+ ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn
+ MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
+
+7.16. strongAuthenticationUser
+
+ ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
+ MUST userCertificate )
+
+7.17. certificationAuthority
+
+ ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
+ MUST ( authorityRevocationList $ certificateRevocationList $
+ cACertificate ) MAY crossCertificatePair )
+
+7.18. groupOfUniqueNames
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
+ MUST ( uniqueMember $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+7.19. userSecurityInformation
+
+ ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+
+7.20. certificationAuthority-V2
+
+ ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP
+ certificationAuthority
+ AUXILIARY MAY ( deltaRevocationList ) )
+
+7.21. cRLDistributionPoint
+
+ ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
+ MUST ( cn ) MAY ( certificateRevocationList $
+ authorityRevocationList $
+ deltaRevocationList ) )
+
+7.22. dmd
+
+ ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName )
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+
+
+
+Wahl Standards Track [Page 17]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+8. Matching Rules
+
+ Servers MAY implement additional matching rules.
+
+8.1. octetStringMatch
+
+ Servers which implement the extensibleMatch filter SHOULD allow the
+ matching rule listed in this section to be used in the
+ extensibleMatch. In general these servers SHOULD allow matching
+ rules to be used with all attribute types known to the server, when
+ the assertion syntax of the matching rule is the same as the value
+ syntax of the attribute.
+
+ ( 2.5.13.17 NAME 'octetStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+9. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords are strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+10. Acknowledgements
+
+ The definitions on which this document have been developed by
+ committees for telecommunications and international standards. No
+ new attribute definitions have been added. The syntax definitions
+ are based on the ISODE "QUIPU" implementation of X.500.
+
+11. Bibliography
+
+ [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight X.500 Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [2] The Directory: Models. ITU-T Recommendation X.501, 1996.
+
+ [3] The Directory: Authentication Framework. ITU-T Recommendation
+ X.509, 1996.
+
+
+
+
+Wahl Standards Track [Page 18]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ [4] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 1996.
+
+ [5] The Directory: Selected Object Classes. ITU-T Recommendation
+ X.521, 1996.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+12. Author's Address
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 West Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 372 3160
+ EMail: M.Wahl@critical-angle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Standards Track [Page 19]
+\f
+RFC 2256 LDAPv3 Schema December 1997
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Standards Track [Page 20]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Kille
+Request for Comments: 2293 Isode Ltd.
+Obsoletes: 1837 March 1998
+Category: Standards Track
+
+
+ Representing Tables and Subtrees in the X.500 Directory
+
+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.
+
+Abstract
+
+ This document defines techniques for representing two types of
+ information mapping in the OSI Directory [1].
+
+ 1. Mapping from a key to a value (or set of values), as might
+ be done in a table lookup.
+
+ 2. Mapping from a distinguished name to an associated
+ value (or values), where the values are not defined by the owner
+ of the entry. This is achieved by use of a directory subtree.
+
+ These techniques were developed for supporting MHS use of Directory
+ [2], but are specified separately as they have more general
+ applicability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 1]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+1 Representing Flat Tables
+
+ Before considering specific function, a general purpose technique for
+ representing tables in the directory is introduced. The schema for
+ this is given in Figure 1. A table can be considered as an unordered
+ set of key to (single or multiple) value mappings, where the key
+ cannot be represented as a global name. There are four reasons why
+ this may occur:
+
+ 1. The object does not have a natural global name.
+
+ 2. The object can only be named effectively in the context of
+ being a key to a binding. In this case, the object will be given
+ a natural global name by the table.
+
+ 3. The object has a global name, and the table is being used
+ to associate parameters with this object, in cases where they
+ cannot be placed in the objects global entry. Reasons why they
+ might not be so placed include:
+
+ o The object does not have a directory entry
+
+ o There is no authority to place the parameters in the
+ global entry
+
+ o The parameters are not global --- they only make sense
+ in the context of the table.
+
+ 4. It is desirable to group information together as a
+ performance optimization, so that the block of information may be
+ widely replicated.
+
+ A table is represented as a single level subtree. The root of the
+ subtree is an entry of object class Table. This is named with a
+ common name descriptive of the table. The table will be located
+ somewhere appropriate to its function. If a table is private to an
+ MTA, it will be below the MTA's entry. If it is shared by MTA's in
+ an organization, it will be located under the organization.
+
+ The generic table entry contains only a description. All instances
+ will be subclassed, and the subclass will define the naming
+ attribute. Two subclasses are defined:
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 2]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+table OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {commonName}
+ MAY CONTAIN {manager}
+ ID oc-table}
+
+
+tableEntry OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MAY CONTAIN {description} 10
+ ID oc-table-entry}
+
+textTableEntry OBJECT-CLASS ::= {
+ SUBCLASS OF {tableEntry}
+ MUST CONTAIN {textTableKey}
+ MAY CONTAIN {textTableValue}
+ ID oc-text-table-entry}
+
+textTableKey ATTRIBUTE ::= {
+ SUBTYPE OF name 20
+ WITH SYNTAX DirectoryString {ub-name}
+ ID at-text-table-key}
+
+textTableValue ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-description}
+ ID at-text-table-value}
+
+distinguishedNameTableEntry OBJECT-CLASS ::= {
+ SUBCLASS OF {tableEntry} 30
+ MUST CONTAIN {distinguishedNameTableKey}
+ ID oc-distinguished-name-table-entry}
+
+distinguishedNameTableKey ATTRIBUTE ::= {
+ SUBTYPE OF distinguishedName
+ ID at-distinguished-name-table-key}
+
+ Figure 1: Representing Tables
+
+
+ 1. TextEntry, which define table entries with text keys,
+ which may have single or multiple values of any type. An
+ attribute is defined to allow a text value, to support the
+ frequent text key to text value mapping. Additional values may
+ be defined.
+
+
+
+
+
+
+Kille Standards Track [Page 3]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+ 2. DistinguishedNameEntry. This is used for associating
+ information with globally defined objects. This approach should
+ be used where the number of objects in the table is small or very
+ sparsely spread over the DIT. In other cases where there are many
+ objects or the objects are tightly clustered in the DIT, the
+ subtree approach defined in Section 2 will be preferable. No
+ value attributes are defined for this type of entry. An
+ application of this will make appropriate subtyping to define the
+ needed values.
+
+ This is best illustrated by example. Consider the MTA:
+
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ Suppose that the MTA needs a table mapping from private keys to fully
+ qualified domain names (this example is fictitious). The table might
+ be named as:
+
+ CN=domain-nicknames,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ To represent a mapping in this table from "euclid" to
+ "bloomsbury.ac.uk", the entry:
+
+ TextTableKey=euclid, CN=domain-nicknames,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ will contain the attribute:
+
+ TextTableValue=bloomsbury.ac.uk
+
+ A second example, showing the use of DistinguishedNameEntry is now
+ given. Consider again the MTA:
+
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ Suppose that the MTA needs a table mapping from MTA Name to bilateral
+ agreement information of that MTA. The table might be named as:
+
+ CN=MTA Bilateral Agreements,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+
+
+
+
+Kille Standards Track [Page 4]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+ To represent information on the MTA which has the Distinguished Name:
+
+ CN=Q3T21, ADMD=Gold 400, C=GB
+
+ There would be an entry in this table with the Relative Distinguished
+ Name of the table entry being the Distinguished Name of the MTA being
+ referred to. The MTA Bilateral information would be an attribute in
+ this entry. Using a non-standard notation, the Distinguished Name of
+ the table entry is:
+
+ DistinguishedNameTableKey=<CN=Q3T21, ADMD=Gold 400, C=GB>,
+ CN=MTA Bilateral Agreements,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+2 Representing Subtrees
+
+ A subtree is similar to a table, except that the keys are constructed
+ as a distinguished name hierarchy relative to the location of the
+ subtree in the DIT. The subtree effectively starts a private "root",
+ and has distinguished names relative to this root. Typically, this
+ approach is used to associate local information with global objects.
+ The schema used is defined in Figure 2. Functionally, this is
+ equivalent to a table with distinguished name keys. The table
+ approach is best when the tree is very sparse. This approach is
+ better for subtrees which are more populated.
+
+ The subtree object class defines the root for a subtree in an
+ analogous means to the table. Information within the subtree will
+ generally be defined in the same way as for the global object, and so
+
+ subtree OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {commonName}
+ MAY CONTAIN {manager}
+ ID oc-subtree}
+
+ Figure 2: Representing Subtrees
+
+
+ no specific object classes for subtree entries are needed.
+
+ For example consider University College London.
+
+ O=University College London, C=GB
+
+
+
+
+
+
+Kille Standards Track [Page 5]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+ Suppose that the UCL needs a private subtree, with interesting
+ information about directory objects. The table might be named as:
+
+ CN=private subtree,
+ O=University College London, C=GB
+
+ UCL specific information on Inria might be stored in the entry:
+
+ O=Inria, C=FR,
+ CN=private subtree,
+ O=University College London, C=GB
+
+ Practical examples of this mapping are given in [2].
+
+3 Acknowledgments
+
+ Acknowledgments for work on this document are given in [2].
+
+References
+
+ [1] The Directory --- overview of concepts, models and services,
+ 1993. CCITT X.500 Series Recommendations.
+
+ [2] Kille, S.E., "X.400-MHS use of the X.500 directory to support
+ X.400-MHS routing," RFC 1801, June 1995.
+
+4 Security Considerations
+
+ Security considerations are not discussed in this memo.
+
+5 Author's Address
+
+ Steve Kille
+ Isode Ltd
+ The Dome
+ The Square
+ Richmond
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille@ISODE.COM
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 6]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 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)}
+
+tables OBJECT IDENTIFIER ::= {mhs-ds 1}
+
+oc OBJECT IDENTIFIER ::= {tables 1}
+at OBJECT IDENTIFIER ::= {tables 2}
+
+oc-subtree OBJECT IDENTIFIER ::= {oc 1}
+oc-table OBJECT IDENTIFIER ::= {oc 2} 10
+oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
+oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
+oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5}
+
+at-text-table-key OBJECT IDENTIFIER ::= {at 1}
+at-text-table-value OBJECT IDENTIFIER ::= {at 2}
+at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
+
+ Figure 3: Object Identifier Assignment
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 7]
+\f
+RFC 2293 Table and Subtrees in the X.500 March 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 8]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Kille
+Request for Comments: 2294 Isode Ltd.
+Obsoletes: 1836 March 1998
+Category: Standards Track
+
+
+ Representing the O/R Address hierarchy in the
+ X.500 Directory Information Tree
+
+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.
+
+Abstract
+
+ This document defines a representation of the O/R Address hierarchy
+ in the Directory Information Tree [6, 1]. This is useful for a range
+ of purposes, including:
+
+ o Support for MHS Routing [4].
+
+ o Support for X.400/RFC 822 address mappings [2, 5].
+
+ Please send comments to the author or to the discussion group <mhs-
+ ds@mercury.udev.cdc.com>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 1]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+ Object Class Mandatory
+ ------------ ---------
+ mHSCountry M
+ aDMD M
+ pRMD O
+ mHSX121 O
+ mHSNumericUserIdentifier O
+ mHSOrganization O
+ mHSOrganizationalUnit O
+ mHSPerson O
+ mHSNamedObject O
+ mHSTerminalID O
+ mHSDomainDefinedAttribute O
+
+ Table 1: Order of O/R Address Directory Components
+
+1 The O/R Address Hierarchy
+
+ An O/R Address hierarchy is represented in the X.500 directory by
+ associating directory name components with O/R Address components.
+ An example of this is given in Figure 1. The object classes and
+ attributes required to support this representation are defined in
+ Figure 2. The schema, which defines the hierarchy in which these
+ objects are represented in the directory information tree is
+ specified in Table 1. A given object class defined in the table will
+ always be higher in the DIT than an object class defined lower down
+ the table. Valid combinations of O/R Address components are defined
+ in X.400.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 2]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+ /\
+ / \
+ C=GB / \ Numeric-C=234
+ / \
+ / \
+ / \
+ +------------+<----------------+----+
+ | Country | | |
+ +------------+ +----+
+ /\
+ / \
+ / \
+ / \
+ ADMD=" " / \ ADMD=Gold 400
+ +-------------+ +------------+
+ | ADMD | | ADMD |
+ +-------------+ +------------+
+ \ \
+ \ \
+ \ PRMD=UK.AC \ PRMD=UK.AC
+ \ \
+ +----------+ +----+
+ | PRMD |< -----------| |
+ +----------+ +----+
+ /
+ /
+ O=UCL
+ /
+ /
+ +------------+
+ | MHS-Org |
+ +------------+
+ \
+ \ OU=CS
+ \
+ \
+ +-----------+
+ | MHS-OU |
+ +-----------+
+
+
+ Figure 1: Example O/R Address Tree
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 3]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+IMPORTS
+ ub-domain-name-length, ub-organization-name-length,
+ ub-organizational-unit-name-length, ub-common-name-length,
+ ub-x121-address-length, ub-domain-defined-attribute-type-length,
+ ub-domain-defined-attribute-value-length, ub-terminal-id-length,
+ ub-numeric-user-id-length, ub-country-name-numeric-length,
+ ub-surname-length, ub-given-name-length, ub-initials-length,
+ ub-generation-qualifier-length
+
+ FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) 10
+ modules(0) upper-bounds(3) };
+
+mHSCountry OBJECT-CLASS ::= {
+ SUBCLASS OF {country}
+ MAY CONTAIN {mHSNumericCountryName}
+ ID oc-mhs-country}
+
+mHSNumericCountryName ATTRIBUTE ::= {
+ WITH SYNTAX NumericString (SIZE (1..ub-country-name-numeric-length))
+ SINGLE VALUE 20
+ ID at-mhs-numeric-country-name}
+
+aDMD OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {aDMDName}
+ ID oc-admd}
+
+aDMDName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-domain-name-length} 30
+ ID at-admd-name}
+
+pRMD OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {pRMDName}
+ ID oc-prmd}
+
+pRMDName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-domain-name-length} 40
+ ID at-prmd-name}
+
+mHSOrganization OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSOrganizationName }
+ ID oc-mhs-organization}
+
+
+
+
+
+Kille Standards Track [Page 4]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+mHSOrganizationName ATTRIBUTE ::= {
+ SUBTYPE OF organizationName
+ WITH SYNTAX DirectoryString {ub-organization-name-length} 50
+ ID at-mhs-organization-name}
+
+mHSOrganizationalUnit OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSOrganizationalUnitName}
+ ID oc-mhs-organizational-unit}
+
+mHSOrganizationalUnitName ATTRIBUTE ::= {
+ SUBTYPE OF organizationalUnitName 60
+ WITH SYNTAX DirectoryString {ub-organizational-unit-name-length}
+ ID at-mhs-organizational-unit-name}
+
+mHSPerson OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSSurname}
+ MAY CONTAIN {mHSGivenName|
+ mHSInitials|
+ mHSGenerationalQualifier}
+ ID oc-mhs-person} 70
+
+mHSSurname ATTRIBUTE ::= {
+ SUBTYPE OF surname
+ WITH SYNTAX DirectoryString {ub-surname-length}
+ ID at-mhs-surname}
+
+mHSGivenName ATTRIBUTE ::= {
+ SUBTYPE OF givenName
+ WITH SYNTAX DirectoryString {ub-given-name-length}
+ ID at-mhs-given-name} 80
+
+mHSInitials ATTRIBUTE ::= {
+ SUBTYPE OF initials
+ WITH SYNTAX DirectoryString {ub-initials-length}
+ ID at-mhs-initials}
+
+mHSGenerationQualifier ATTRIBUTE ::= {
+ SUBTYPE OF generationQualifier
+ WITH SYNTAX DirectoryString {ub-generation-qualifier-length}
+ ID at-mhs-generation-qualifier} 90
+
+mHSNamedObject OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSCommonName}
+ ID oc-mhs-named-object}
+
+
+
+
+Kille Standards Track [Page 5]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+mHSCommonName ATTRIBUTE ::= {
+ SUBTYPE OF commonName
+ WITH SYNTAX DirectoryString {ub-common-name-length}
+ ID at-mhs-common-name} 100
+
+mHSX121 OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSX121Address}
+ ID oc-mhs-x121}
+
+mHSX121Address ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-x121-address-length}
+ ID at-x121-address} 110
+
+mHSDomainDefinedAttribute OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {
+ mHSDomainDefinedAttributeType|
+ mHSDomainDefinedAttributeValue}
+ ID oc-mhs-domain-defined-attribute}
+
+mHSDomainDefinedAttributeType ATTRIBUTE ::= {
+ SUBTYPE OF name 120
+ WITH SYNTAX DirectoryString {ub-domain-defined-attribute-type-length}
+ SINGLE VALUE
+ ID at-mhs-domain-defined-attribute-type}
+
+mHSDomainDefinedAttributeValue ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-domain-defined-attribute-value-length}
+ SINGLE VALUE
+ ID at-mhs-domain-defined-attribute-value}
+ 130
+
+mHSTerminalID OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSTerminalIDName}
+ ID oc-mhs-terminal-id}
+
+mHSTerminalIDName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-terminal-id-length}
+ ID at-mhs-terminal-id-name} 140
+
+
+
+
+
+
+
+Kille Standards Track [Page 6]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+mHSNumericUserIdentifier OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSNumericUserIdentifierName}
+ ID oc-mhs-numeric-user-id}
+
+mHSNumericeUserIdentifierName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-numeric-user-id-length} 150
+ ID at-mhs-numeric-user-id-name}
+
+ Figure 2: O/R Address Hierarchy
+
+ The hierarchy is defined so that:
+
+ 1. The representation is defined so that it is straightforward to
+ make a mechanical transformation in either direction. This
+ requires that each node is named by an attribute whose type can
+ determine the mapping.
+
+ 2. Where there are multiple domain defined attributes, the first
+ in the sequence is the most significant.
+
+ 3. Physical Delivery (postal) addresses are not represented in
+ this hierarchy. This is primarily because physical delivery can
+ be handled by the Access Unit routing mechanisms defined in [4],
+ and there is no need for this representation.
+
+ 4. Terminal and network forms of address are not handled, except
+ for X.121 form, which is useful for addressing faxes.
+
+ 5. MHSCountry is defined as a subclass of Country, and so the
+ same entry will be used for MHS Routing as for the rest of the
+ DIT.
+
+ 6. The numeric country code will be an alias.
+
+ 7. ADMD will always be present in the hierarchy. This is true
+ in the case of " " and of "0". This facilitates an easy
+ mechanical transformation between the two forms of address.
+
+ 8. Each node is named by the relevant part of the O/R Address.
+
+ 9. Aliases may be used in other parts of the tree, in order to
+ normalize alternate values. Where an alias is used, the value of
+ the alias should be present as an alternate value in the node
+ aliased to. Aliases may not be used for domain defined
+ attributes.
+
+
+
+
+Kille Standards Track [Page 7]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+ 10. Domain Defined Attributes are named by a multi-valued RDN
+ (Relative Distinguished Name), consisting of the type and value.
+ This is done so that standard attribute syntaxes can be used.
+
+ 11. Where an O/R Address has a valid Printable String and T.61 form,
+ both must be present, with one as an alias for the other. This
+ is so that direct lookup of the name will work, independent of
+ the variant used. When both are present in an O/R Address being
+ looked up, either may be used to construct the distinguished
+ name.
+
+ 12. Personal name is handled by use of the mHSPerson object class.
+ Each of the components of the personal name will be present in
+ the relative distinguished name, which will usually be multi-
+ valued.
+
+ The relationship between X.400 O/R Addresses and the X.400 Entries
+ (Attribute Type and Object Class) are given in Table 2. Where there
+ are multiple Organizational Units or Domain Defined Attributes, each
+ component is mapped onto a single X.500 entry.
+
+ Note: When an X.121 address is used for addressing fax transmission,
+ this may only be done relative to the PRMD or ADMD. This is in
+ line with the current X.400 standards position. This means that
+ it is not possible to use this form of addressing for an
+ organizational or departmental fax gateway service.
+
+O/R Address Object Class Naming Attribute
+----------- ------------ ----------------
+C mHSCountry countryName
+ or
+ mHSNumericCountryName
+A aDMD aDMDName
+P pRMD pRMDName
+O mHSOrganization mHSOrganizationName
+OU/OU1/OU2 mHSOrganizationalUnit mHSOrganizationalUnitName
+OU3/OU4
+PN mHSPerson personName
+CN mHSNamedObject mHSCommonName
+X121 mHSX121 mHSX121Address
+T-ID mHSTerminalID mHSTerminalIDName
+UA-ID mHSNumericUserIdentifier mHSNumericUserIdentifierName
+DDA mHSDomainDefinedAttribute mHSDomainDefinedAttributeType
+ and
+ mHSDomainDefinedAttributeValue
+
+
+ Table 2: O/R Address relationship to Directory Name
+
+
+
+Kille Standards Track [Page 8]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+2 Notation
+
+ O/R Addresses are written in the standard X.400 Notation.
+ Distinguished Names use the string representation of distinguished
+ names defined in [3]. The keywords used for the attributes defined
+ in this specification are given in Table 3.
+
+3 Example Representation
+
+ The O/R Address:
+
+ I=S; S=Kille; OU1=CS; O=UCL,
+ P=UK.AC; A=Gold 400; C=GB;
+
+
+ would be represented in the directory as:
+
+ MHS-I=S + MHS-S=Kille, MHS-OU=CS, MHS-O=UCL,
+
+
+ Attribute Keyword
+ --------- -------
+ mHSNumericCountryName MHS-Numeric-Country
+ aDMDName ADMD
+ pRMDName PRMD
+ mHSOrganizationName MHS-O
+ mHSOrganizationalUnitName MHS-OU
+ mHSSurname MHS-S
+ mHSGivenName MHS-G
+ mHSInitials MHS-I
+ mHSGenerationalQualifier MHS-GQ
+ mHSCommonName MHS-CN
+ mHSX121Address MHS-X121
+ mHSDomainDefinedAttributeType MHS-DDA-Type
+ mHSDomainDefinedAttributeValue MHS-DDA-Value
+ mHSTerminalIDName MHS-T-ID
+ mHSNumericeUserIdentifierName MHS-UA-ID
+
+ Table 3: Keywords for String DN Representation
+
+
+ PRMD=UK.AC, ADMD=Gold 400, C=GB
+
+4 Mapping from O/R Address to Directory Name
+
+ The primary application of this mapping is to take an X.400 encoded
+ O/R Address and to generate an equivalent directory name. This
+ mapping is only used for selected types of O/R Address:
+
+
+
+Kille Standards Track [Page 9]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+ o Mnemonic form
+
+ o Numeric form
+
+ o Terminal form, where country is present and X121 addressing
+ is used
+
+ Other forms of O/R address are handled by Access Unit mechanisms.
+ The O/R Address is treated as an ordered list, with the order as
+ defined in Table 1. For each O/R Address attribute, generate the
+ equivalent directory naming attribute. In most cases, the mapping is
+ mechanical. Printable String or Teletex encodings are chosen as
+ appropriate. Where both forms are present in the O/R Address, either
+ form may be used to generate the distinguished name. Both will be
+ represented in the DIT. There are two special cases:
+
+ 1. A DDA generates a multi-valued RDN
+
+ 2. The Personal Name is mapped to a multi-valued RDN
+
+ In many cases, an O/R Address will be provided, and only the higher
+ components of the address will be represented in the DIT. In this
+ case, the "longest possible match" should be returned.
+
+5 Mapping from Directory Name to O/R Address
+
+ The reverse mapping is also needed in some cases. All of the naming
+ attributes are unique, so the mapping is mechanically reversible.
+
+6 Acknowledgments
+
+ Acknowledgments for work on this document are given in [4].
+
+References
+
+ [1] The Directory --- overview of concepts, models and services,
+ 1993. CCITT X.500 Series Recommendations.
+
+ [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+ between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+ [3] Kille, S., "A String Representation of Distinguished Names",
+ RFC 1779, March 1995.
+
+ [4] Kille, S., "Use of an X.500/LDAP directory to support MIXER address
+ mapping", RFC 2164, January 1998.
+
+
+
+
+
+Kille Standards Track [Page 10]
+\f
+RFC 2294 Directory Information Tree March 1998
+
+
+ [5] Kille, S., "X.400-MHS use of the X.500 directory to support
+ X.400-MHS routing", RFC 1801, June 1995.
+
+ [6] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
+ SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service
+ Overview.
+
+7 Security Considerations
+
+ This protocol introduces no known security risks.
+
+8 Author's Address
+
+ Steve Kille
+ Isode Ltd.
+ The Dome
+ The Square
+ Richmond
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille@ISODE.COM
+
+ X.400: I=S; S=Kille; P=ISODE; A=Mailnet; C=FI;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 11]
+\f
+RFC 2294 Directory Information Tree March 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)}
+
+
+tree OBJECT IDENTIFIER ::= {mhs-ds 2}
+
+oc OBJECT IDENTIFIER ::= {tree 1}
+at OBJECT IDENTIFIER ::= {tree 2}
+
+oc-admd OBJECT IDENTIFIER ::= {oc 1} 10
+oc-mhs-country OBJECT IDENTIFIER ::= {oc 2}
+oc-mhs-domain-defined-attribute OBJECT IDENTIFIER ::= {oc 3}
+oc-mhs-named-object OBJECT IDENTIFIER ::= {oc 4}
+oc-mhs-organization OBJECT IDENTIFIER ::= {oc 5}
+oc-mhs-organizational-unit OBJECT IDENTIFIER ::= {oc 6}
+oc-mhs-person OBJECT IDENTIFIER ::= {oc 7}
+oc-mhs-x121 OBJECT IDENTIFIER ::= {oc 8}
+oc-prmd OBJECT IDENTIFIER ::= {oc 9}
+oc-mhs-terminal-id OBJECT IDENTIFIER ::= {oc 10}
+oc-mhs-numeric-user-id OBJECT IDENTIFIER ::= {oc 11} 20
+
+at-admd-name OBJECT IDENTIFIER ::= {at 1}
+at-mhs-common-name OBJECT IDENTIFIER ::= {at 2}
+at-mhs-domain-defined-attribute-type OBJECT IDENTIFIER ::= {at 3}
+at-mhs-domain-defined-attribute-value OBJECT IDENTIFIER ::= {at 4}
+at-mhs-numeric-country-name OBJECT IDENTIFIER ::= {at 5}
+at-mhs-organization-name OBJECT IDENTIFIER ::= {at 6}
+at-mhs-organizational-unit-name OBJECT IDENTIFIER ::= {at 7}
+at-prmd-name OBJECT IDENTIFIER ::= {at 10}
+at-x121-address OBJECT IDENTIFIER ::= {at 12} 30
+at-mhs-terminal-id-name OBJECT IDENTIFIER ::= {at 13}
+at-mhs-numeric-user-id-name OBJECT IDENTIFIER ::= {at 14}
+at-mhs-surname OBJECT IDENTIFIER ::= {at 15}
+at-mhs-given-name OBJECT IDENTIFIER ::= {at 16}
+at-mhs-initials OBJECT IDENTIFIER ::= {at 17}
+at-mhs-generation-qualifier OBJECT IDENTIFIER ::= {at 18}
+
+ Figure 3: Object Identifier Assignment
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 12]
+\f
+RFC 2294 Directory Information Tree March 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 13]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group L. Howard
+Request for Comments: 2307 Independent Consultant
+Category: Experimental March 1998
+
+
+ An Approach for Using LDAP as a Network Information Service
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This document describes an experimental mechanism for mapping
+ entities related to TCP/IP and the UNIX system into X.500 [X500]
+ entries so that they may be resolved with the Lightweight Directory
+ Access Protocol [RFC2251]. A set of attribute types and object
+ classes are proposed, along with specific guidelines for interpreting
+ them.
+
+ The intention is to assist the deployment of LDAP as an
+ organizational nameservice. No proposed solutions are intended as
+ standards for the Internet. Rather, it is hoped that a general
+ consensus will emerge as to the appropriate solution to such
+ problems, leading eventually to the adoption of standards. The
+ proposed mechanism has already been implemented with some success.
+
+1. Background and Motivation
+
+ The UNIX (R) operating system, and its derivatives (specifically,
+ those which support TCP/IP and conform to the X/Open Single UNIX
+ specification [XOPEN]) require a means of looking up entities, by
+ matching them against search criteria or by enumeration. (Other
+ operating systems that support TCP/IP may provide some means of
+ resolving some of these entities. This schema is applicable to those
+ environments also.)
+
+ These entities include users, groups, IP services (which map names to
+ IP ports and protocols, and vice versa), IP protocols (which map
+ names to IP protocol numbers and vice versa), RPCs (which map names
+ to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS
+
+
+
+Howard Experimental [Page 1]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ netgroups, booting information (boot parameters and MAC address
+ mappings), filesystem mounts, IP hosts and networks, and RFC822 mail
+ aliases.
+
+ Resolution requests are made through a set of C functions, provided
+ in the UNIX system's C library. For example, the UNIX system utility
+ "ls", which enumerates the contents of a filesystem directory, uses
+ the C library function getpwuid() in order to map user IDs to login
+ names. Once the request is made, it is resolved using a "nameservice"
+ which is supported by the client library. The nameservice may be, at
+ its simplest, a collection of files in the local filesystem which are
+ opened and searched by the C library. Other common nameservices
+ include the Network Information Service (NIS) and the Domain Name
+ System (DNS). (The latter is typically used for resolving hosts,
+ services and networks.) Both these nameservices have the advantage of
+ being distributed and thus permitting a common set of entities to be
+ shared amongst many clients.
+
+ LDAP is a distributed, hierarchical directory service access protocol
+ which is used to access repositories of users and other network-
+ related entities. Because LDAP is often not tightly integrated with
+ the host operating system, information such as users may need to be
+ kept both in LDAP and in an operating system supported nameservice
+ such as NIS. By using LDAP as the the primary means of resolving
+ these entities, these redundancy issues are minimized and the
+ scalability of LDAP can be exploited. (By comparison, NIS services
+ based on flat files do not have the scalability or extensibility of
+ LDAP or X.500.)
+
+ The object classes and attributes defined below are suitable for
+ representing the aforementioned entities in a form compatible with
+ LDAP and X.500 directory services.
+
+2. General Issues
+
+2.1. Terminology
+
+ The key words "MUST", "SHOULD", and "MAY" used in this document are
+ to be interpreted as described in [RFC2119].
+
+ For the purposes of this document, the term "nameservice" refers to a
+ service, such as NIS or flat files, that is used by the operating
+ system to resolve entities within a single, local naming context.
+ Contrast this with a "directory service" such as LDAP, which supports
+ extensible schema and multiple naming contexts.
+
+
+
+
+
+
+Howard Experimental [Page 2]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ The term "NIS-related entities" broadly refers to entities which are
+ typically resolved using the Network Information Service. (NIS was
+ previously known as YP.) Deploying LDAP for resolving these entities
+ does not imply that NIS be used, as a gateway or otherwise. In
+ particular, the host and network classes are generically applicable,
+ and may be implemented on any system that wishes to use LDAP or X.500
+ for host and network resolution.
+
+ The "DUA" (directory user agent) refers to the LDAP client querying
+ these entities, such as an LDAP to NIS gateway or the C library. The
+ "client" refers to the application which ultimately makes use of the
+ information returned by the resolution. It is irrelevant whether the
+ DUA and the client reside within the same address space. The act of
+ the DUA making this information to the client is termed
+ "republishing".
+
+ To avoid confusion, the term "login name" refers to the user's login
+ name (being the value of the uid attribute) and the term "user ID"
+ refers to he user's integer identification number (being the value of
+ the uidNumber attribute).
+
+ The phrases "resolving an entity" and "resolution of entities" refer
+ respectively to enumerating NIS-related entities of a given type, and
+ matching them against a given search criterion. One or more entities
+ are returned as a result of successful "resolutions" (a "match"
+ operation will only return one entity).
+
+ The use of the term UNIX does not confer upon this schema the
+ endorsement of owners of the UNIX trademark. Where necessary, the
+ term "TCP/IP entity" is used to refer to protocols, services, hosts,
+ and networks, and the term "UNIX entity" to its complement. (The
+ former category does not mandate the host operating system supporting
+ the interfaces required for resolving UNIX entities.)
+
+ The OIDs defined below are derived from iso(1) org(3) dod(6)
+ internet(1) directory(1) nisSchema(1).
+
+2.2. Attributes
+
+ The attributes and classes defined in this document are summarized
+ below.
+
+ The following attributes are defined in this document:
+
+ uidNumber
+ gidNumber
+ gecos
+ homeDirectory
+
+
+
+Howard Experimental [Page 3]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ loginShell
+ shadowLastChange
+ shadowMin
+ shadowMax
+ shadowWarning
+ shadowInactive
+ shadowExpire
+ shadowFlag
+ memberUid
+ memberNisNetgroup
+ nisNetgroupTriple
+ ipServicePort
+ ipServiceProtocol
+ ipProtocolNumber
+ oncRpcNumber
+ ipHostNumber
+ ipNetworkNumber
+ ipNetmaskNumber
+ macAddress
+ bootParameter
+ bootFile
+ nisMapName
+ nisMapEntry
+
+ Additionally, some of the attributes defined in [RFC2256] are
+ required.
+
+2.3. Object classes
+
+ The following object classes are defined in this document:
+
+ posixAccount
+ shadowAccount
+ posixGroup
+ ipService
+ ipProtocol
+ oncRpc
+ ipHost
+ ipNetwork
+ nisNetgroup
+ nisMap
+ nisObject
+ ieee802Device
+ bootableDevice
+
+ Additionally, some of the classes defined in [RFC2256] are required.
+
+
+
+
+
+Howard Experimental [Page 4]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+2.4. Syntax definitions
+
+ The following syntax definitions [RFC2252] are used by this schema.
+ The nisNetgroupTripleSyntax represents NIS netgroup triples:
+
+ ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax'
+ DESC 'NIS netgroup triple' )
+
+ Values in this syntax are represented by the following:
+
+ nisnetgrouptriple = "(" hostname "," username "," domainname ")"
+ hostname = "" / "-" / keystring
+ username = "" / "-" / keystring
+ domainname = "" / "-" / keystring
+
+ X.500 servers may use the following representation of the above
+ syntax:
+
+ nisNetgroupTripleSyntax ::= SEQUENCE {
+ hostname [0] IA5String OPTIONAL,
+ username [1] IA5String OPTIONAL,
+ domainname [2] IA5String OPTIONAL
+ }
+
+ The bootParameterSyntax syntax represents boot parameters:
+
+ ( nisSchema.0.1 NAME 'bootParameterSyntax'
+ DESC 'Boot parameter' )
+
+ where:
+
+ bootparameter = key "=" server ":" path
+ key = keystring
+ server = keystring
+ path = keystring
+
+ X.500 servers may use the following representation of the above
+ syntax:
+
+ bootParameterSyntax ::= SEQUENCE {
+ key IA5String,
+ server IA5String,
+ path IA5String
+ }
+
+ Values adhering to these syntaxes are encoded as strings by LDAP
+ servers.
+
+
+
+
+Howard Experimental [Page 5]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+3. Attribute definitions
+
+ This section contains attribute definitions to be implemented by DUAs
+ supporting this schema.
+
+ ( nisSchema.1.0 NAME 'uidNumber'
+ DESC 'An integer uniquely identifying a user in an
+ administrative domain'
+ EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.1 NAME 'gidNumber'
+ DESC 'An integer uniquely identifying a group in an
+ administrative domain'
+ EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.2 NAME 'gecos'
+ DESC 'The GECOS field; the common name'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTRINGS caseIgnoreIA5SubstringsMatch
+ SYNTAX 'IA5String' SINGLE-VALUE )
+
+ ( nisSchema.1.3 NAME 'homeDirectory'
+ DESC 'The absolute path to the home directory'
+ EQUALITY caseExactIA5Match
+ SYNTAX 'IA5String' SINGLE-VALUE )
+
+ ( nisSchema.1.4 NAME 'loginShell'
+ DESC 'The path to the login shell'
+ EQUALITY caseExactIA5Match
+ SYNTAX 'IA5String' SINGLE-VALUE )
+
+ ( nisSchema.1.5 NAME 'shadowLastChange'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.6 NAME 'shadowMin'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.7 NAME 'shadowMax'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.8 NAME 'shadowWarning'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.9 NAME 'shadowInactive'
+
+
+
+Howard Experimental [Page 6]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.10 NAME 'shadowExpire'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.11 NAME 'shadowFlag'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.12 NAME 'memberUid'
+ EQUALITY caseExactIA5Match
+ SUBSTRINGS caseExactIA5SubstringsMatch
+ SYNTAX 'IA5String' )
+
+ ( nisSchema.1.13 NAME 'memberNisNetgroup'
+ EQUALITY caseExactIA5Match
+ SUBSTRINGS caseExactIA5SubstringsMatch
+ SYNTAX 'IA5String' )
+
+ ( nisSchema.1.14 NAME 'nisNetgroupTriple'
+ DESC 'Netgroup triple'
+ SYNTAX 'nisNetgroupTripleSyntax' )
+
+ ( nisSchema.1.15 NAME 'ipServicePort'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.16 NAME 'ipServiceProtocol'
+ SUP name )
+
+ ( nisSchema.1.17 NAME 'ipProtocolNumber'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.18 NAME 'oncRpcNumber'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.19 NAME 'ipHostNumber'
+ DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
+ omitting leading zeros'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' )
+
+ ( nisSchema.1.20 NAME 'ipNetworkNumber'
+ DESC 'IP network as a dotted decimal, eg. 192.168,
+
+
+
+Howard Experimental [Page 7]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ omitting leading zeros'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' SINGLE-VALUE )
+
+ ( nisSchema.1.21 NAME 'ipNetmaskNumber'
+ DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
+ omitting leading zeros'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' SINGLE-VALUE )
+
+ ( nisSchema.1.22 NAME 'macAddress'
+ DESC 'MAC address in maximal, colon separated hex
+ notation, eg. 00:00:92:90:ee:e2'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' )
+
+ ( nisSchema.1.23 NAME 'bootParameter'
+ DESC 'rpc.bootparamd parameter'
+ SYNTAX 'bootParameterSyntax' )
+
+ ( nisSchema.1.24 NAME 'bootFile'
+ DESC 'Boot image name'
+ EQUALITY caseExactIA5Match
+ SYNTAX 'IA5String' )
+
+ ( nisSchema.1.26 NAME 'nisMapName'
+ SUP name )
+
+ ( nisSchema.1.27 NAME 'nisMapEntry'
+ EQUALITY caseExactIA5Match
+ SUBSTRINGS caseExactIA5SubstringsMatch
+ SYNTAX 'IA5String{1024}' SINGLE-VALUE )
+
+4. Class definitions
+
+ This section contains class definitions to be implemented by DUAs
+ supporting the schema.
+
+ The rfc822MailGroup object class MAY be used to represent a mail
+ group for the purpose of alias expansion. Several alternative schemes
+ for mail routing and delivery using LDAP directories, which are
+ outside the scope of this document.
+
+ ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
+ DESC 'Abstraction of an account with POSIX attributes'
+ MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
+ MAY ( userPassword $ loginShell $ gecos $ description ) )
+
+
+
+
+Howard Experimental [Page 8]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY
+ DESC 'Additional attributes for shadow passwords'
+ MUST uid
+ MAY ( userPassword $ shadowLastChange $ shadowMin
+ shadowMax $ shadowWarning $ shadowInactive $
+ shadowExpire $ shadowFlag $ description ) )
+
+ ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
+ DESC 'Abstraction of a group of accounts'
+ MUST ( cn $ gidNumber )
+ MAY ( userPassword $ memberUid $ description ) )
+
+ ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL
+ DESC 'Abstraction an Internet Protocol service.
+ Maps an IP port and protocol (such as tcp or udp)
+ to one or more names; the distinguished value of
+ the cn attribute denotes the service's canonical
+ name'
+ MUST ( cn $ ipServicePort $ ipServiceProtocol )
+ MAY ( description ) )
+
+ ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
+ DESC 'Abstraction of an IP protocol. Maps a protocol number
+ to one or more names. The distinguished value of the cn
+ attribute denotes the protocol's canonical name'
+ MUST ( cn $ ipProtocolNumber $ description )
+ MAY description )
+
+ ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL
+ DESC 'Abstraction of an Open Network Computing (ONC)
+ [RFC1057] Remote Procedure Call (RPC) binding.
+ This class maps an ONC RPC number to a name.
+ The distinguished value of the cn attribute denotes
+ the RPC service's canonical name'
+ MUST ( cn $ oncRpcNumber $ description )
+ MAY description )
+
+ ( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
+
+ DESC 'Abstraction of a host, an IP device. The distinguished
+ value of the cn attribute denotes the host's canonical
+ name. Device SHOULD be used as a structural class'
+ MUST ( cn $ ipHostNumber )
+ MAY ( l $ description $ manager ) )
+
+ ( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
+ DESC 'Abstraction of a network. The distinguished value of
+ the cn attribute denotes the network's canonical name'
+
+
+
+Howard Experimental [Page 9]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ MUST ( cn $ ipNetworkNumber )
+ MAY ( ipNetmaskNumber $ l $ description $ manager ) )
+
+ ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
+ DESC 'Abstraction of a netgroup. May refer to other netgroups'
+ MUST cn
+ MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
+
+ ( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL
+ DESC 'A generic abstraction of a NIS map'
+ MUST nisMapName
+ MAY description )
+
+ ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
+ DESC 'An entry in a NIS map'
+ MUST ( cn $ nisMapEntry $ nisMapName )
+ MAY description )
+
+ ( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY
+ DESC 'A device with a MAC address; device SHOULD be
+ used as a structural class'
+ MAY macAddress )
+
+ ( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY
+ DESC 'A device with boot parameters; device SHOULD be
+ used as a structural class'
+ MAY ( bootFile $ bootParameter ) )
+
+5. Implementation details
+
+5.1. Suggested resolution methods
+
+ The preferred means of directing a client application (one using the
+ shared services of the C library) to use LDAP as its information
+ source for the functions listed in 5.2 is to modify the source code
+ to directly query LDAP. As the source to commercial C libraries and
+ applications is rarely available to the end-user, one could emulate a
+ supported nameservice (such as NIS). (This is also an appropriate
+ opportunity to perform caching of entries across process address
+ spaces.) In the case of NIS, reference implementations are widely
+ available and the RPC interface is well known.
+
+ The means by which the operating system is directed to use LDAP is
+ implementation dependent. For example, some operating systems and C
+ libraries support end-user extensible resolvers using dynamically
+ loadable libraries and a nameservice "switch". The means in which the
+ DUA locates LDAP servers is also implementation dependent.
+
+
+
+
+Howard Experimental [Page 10]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+5.2. Affected library functions
+
+ The following functions are typically found in the C libraries of
+ most UNIX and POSIX compliant systems. An LDAP search filter
+ [RFC2254] which may be used to satisfy the function call is included
+ alongside each function name. Parameters are denoted by %s and %d for
+ string and integer arguments, respectively. Long lines are broken.
+
+ getpwnam() (&(objectClass=posixAccount)(uid=%s))
+ getpwuid() (&(objectClass=posixAccount)
+ (uidNumber=%d))
+ getpwent() (objectClass=posixAccount)
+
+ getspnam() (&(objectClass=shadowAccount)(uid=%s))
+ getspent() (objectClass=shadowAccount)
+
+ getgrnam() (&(objectClass=posixGroup)(cn=%s))
+ getgrgid() (&(objectClass=posixGroup)
+ (gidNumber=%d))
+ getgrent() (objectClass=posixGroup)
+
+ getservbyname() (&(objectClass=ipService)
+ (cn=%s)(ipServiceProtocol=%s))
+ getservbyport() (&(objectClass=ipService)
+ (ipServicePort=%d)
+ (ipServiceProtocol=%s))
+ getservent() (objectClass=ipService)
+
+ getrpcbyname() (&(objectClass=oncRpc)(cn=%s))
+ getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d))
+ getrpcent() (objectClass=oncRpc)
+
+ getprotobyname() (&(objectClass=ipProtocol)(cn=%s))
+ getprotobynumber() (&(objectClass=ipProtocol)
+ (ipProtocolNumber=%d))
+ getprotoent() (objectClass=ipProtocol)
+
+ gethostbyname() (&(objectClass=ipHost)(cn=%s))
+ gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s))
+ gethostent() (objectClass=ipHost)
+
+ getnetbyname() (&(objectClass=ipNetwork)(cn=%s))
+ getnetbyaddr() (&(objectClass=ipNetwork)
+ (ipNetworkNumber=%s))
+ getnetent() (objectClass=ipNetwork)
+
+ setnetgrent() (&(objectClass=nisNetgroup)(cn=%s))
+
+
+
+
+Howard Experimental [Page 11]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+5.3. Interpreting user and group entries
+
+ User and group resolution is initiated by the functions prefixed by
+ getpw and getgr respectively. The uid attribute contains the user's
+ login name. The cn attribute, in posixGroup entries, contains the
+ group's name.
+
+ The account object class provides a convenient structural class for
+ posixAccount, and SHOULD be used where additional attributes are not
+ required.
+
+ It is suggested that uid and cn are used as the RDN attribute type
+ for posixAccount and posixGroup entries, respectively.
+
+ An account's GECOS field is preferably determined by a value of the
+ gecos attribute. If no gecos attribute exists, the value of the cn
+ attribute MUST be used. (The existence of the gecos attribute allows
+ information embedded in the GECOS field, such as a user's telephone
+ number, to be returned to the client without overloading the cn
+ attribute. It also accommodates directories where the common name
+ does not contain the user's full name.)
+
+ An entry of class posixAccount, posixGroup, or shadowAccount without
+ a userPassword attribute MUST NOT be used for authentication. The
+ client should be returned a non-matchable password such as "x".
+
+ userPassword values MUST be represented by following syntax:
+
+ passwordvalue = schemeprefix encryptedpassword
+ schemeprefix = "{" scheme "}"
+ scheme = "crypt" / "md5" / "sha" / altscheme
+ altscheme = "x-" keystring
+ encryptedpassword = encrypted password
+
+ The encrypted password contains of a plaintext key hashed using the
+ algorithm scheme.
+
+ userPassword values which do not adhere to this syntax MUST NOT be
+ used for authentication. The DUA MUST iterate through the values of
+ the attribute until a value matching the above syntax is found. Only
+ if encryptedpassword is an empty string does the user have no
+ password. DUAs are not required to consider encryption schemes which
+ the client will not recognize; in most cases, it may be sufficient to
+ consider only "crypt".
+
+ Below is an example of a userPassword attribute:
+
+ userPassword: {crypt}X5/DBrWPOQQaI
+
+
+
+Howard Experimental [Page 12]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ A future standard may specify LDAP v3 attribute descriptions to
+ represent hashed userPasswords, as noted below. This schema MUST NOT
+ be used with LDAP v2 DUAs and DSAs.
+
+ attributetype = attributename sep attributeoption
+ attributename = "userPassword"
+ sep = ";"
+ attributeoption = schemeclass "-" scheme
+ schemeclass = "hash" / altschemeclass
+ scheme = "crypt" / "md5" / "sha" / altscheme
+ altschemeclass = "x-" keystring
+ altscheme = keystring
+
+
+ Below is an example of a userPassword attribute, represented with an
+ LDAP v3 attribute description:
+
+ userPassword;hash-crypt: X5/DBrWPOQQaI
+
+
+ A DUA MAY utilise the attributes in the shadowAccount class to
+ provide shadow password service (getspnam() and getspent()). In such
+ cases, the DUA MUST NOT make use of the userPassword attribute for
+ getpwnam() et al, and MUST return a non-matchable password (such as
+ "x") to the client instead.
+
+5.4. Interpreting hosts and networks
+
+ The ipHostNumber and ipNetworkNumber attributes are defined in
+ preference to dNSRecord (defined in [RFC1279]), in order to simplify
+ the DUA's role in interpreting entries in the directory. A dNSRecord
+ expresses a complete resource record, including time to live and
+ class data, which is extraneous to this schema.
+
+ Additionally, the ipHost and ipNetwork classes permit a host or
+ network (respectively) and all its aliases to be represented by a
+ single entry in the directory. This is not necessarily possible if a
+ DNS resource record is mapped directly to an LDAP entry.
+ Implementations that wish to use LDAP to master DNS zone information
+ are not precluded from doing so, and may simply avoid the ipHost and
+ ipNetwork classes.
+
+ This document redefines, although not exclusively, the ipNetwork
+ class defined in [RFC1279], in order to achieve consistent naming
+ with ipHost. The ipNetworkNumber attribute is also used in the
+ siteContact object class [ROSE].
+
+
+
+
+
+Howard Experimental [Page 13]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ The trailing zeros in a network address MUST be omitted. CIDR-style
+ network addresses (eg. 192.168.1/24) MAY be used.
+
+ Hosts with IPv6 addresses MUST be written in their "preferred" form
+ as defined in section 2.2.1 of [RFC1884], such that all components of
+ the address are indicated and leading zeros are omitted. This
+ provides a consistent means of resolving ipHosts by address.
+
+5.5. Interpreting other entities
+
+ In general, a one-to-one mapping between entities and LDAP entries is
+ proposed, in that each entity has exactly one representation in the
+ DIT. In some cases this is not feasible; for example, a service which
+ is represented in more than one protocol domain. Consider the
+ following entry:
+
+ dn: cn=domain, dc=aja, dc=com
+ cn: domain
+ cn: nameserver
+ objectClass: top
+ objectClass: ipService
+ ipServicePort: 53
+ ipServiceProtocol: tcp
+ ipServiceProtocol: udp
+
+ This entry MUST map to the following two (2) services entities:
+
+ domain 53/tcp nameserver
+ domain 53/udp nameserver
+
+ While the above two entities may be represented as separate LDAP
+ entities, with different distinguished names (such as
+ cn=domain+ipServiceProtocol=tcp, ... and
+ cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent
+ them as a single entry. (If a service is represented in multiple
+ protocol domains with different ports, then multiple entries are
+ required; multivalued RDNs may be used to distinguish them.)
+
+ With the exception of userPassword values, which are parsed according
+ to the syntax considered in section 5.2, any empty values (consisting
+ of a zero length string) are returned by the DUA to the client. The
+ DUA MUST reject any entries which do not conform to the schema
+ (missing mandatory attributes). Non-conforming entries SHOULD be
+ ignored while enumerating entries.
+
+ The nisObject object class MAY be used as a generic means of
+ representing NIS entities. Its use is not encouraged; where support
+ for entities not described in this schema is desired, an appropriate
+
+
+
+Howard Experimental [Page 14]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ schema should be devised. Implementors are strongly advised to
+ support end-user extensible mappings between NIS entities and object
+ classes. (Where the nisObject class is used, the nisMapName attribute
+ may be used as a RDN.)
+
+5.6. Canonicalizing entries with multi-valued naming attributes
+
+ For entities such as hosts, services, networks, protocols, and RPCs,
+ where there may be one or more aliases, the respective entry's
+ relative distinguished name SHOULD be used to determine the canonical
+ name. Any other values for the same attribute are used as aliases.
+ For example, the service described in section 5.5 has the canonical
+ name "domain" and exactly one alias, "nameserver".
+
+ The schema in this document generally only defines one attribute per
+ class which is suitable for distinguishing an entity (excluding any
+ attributes with integer syntax; it is assumed that entries will be
+ distinguished on name). Usually, this is the common name (cn)
+ attribute. This aids the DUA in determining the canonical name of an
+ entity, as it can examine the value of the relative distinguished
+ name. Aliases are thus any values of the distinguishing attribute
+ (such as cn) which do not match the canonical name of the entity.
+
+ In the event that a different attribute is used to distinguish the
+ entry, as may be the case where these object classes are used as
+ auxiliary classes, the entry's canonical name may not be present in
+ the RDN. In this case, the DUA MUST choose one of the non-
+ distinguished values to represent the entity's canonical name. As the
+ directory server guarantees no ordering of attribute values, it may
+ not be possible to distinguish an entry deterministically. This
+ ambiguity SHOULD NOT be resolved by mapping one directory entry into
+ multiple entities.
+
+6. Implementation focus
+
+ A NIS server which uses LDAP instead of local files has been
+ developed which supports the schema defined in this document.
+
+ A reference implementation of the C library resolution code has been
+ written for the Free Software Foundation. It may support other C
+ libraries which support the Name Service Switch (NSS) or the
+ Information Retrieval Service (IRS).
+
+ The author has made available a freely distributable set of scripts
+ which parses local databases such as /etc/passwd and /etc/hosts into
+ a form suitable for loading into an LDAP server.
+
+
+
+
+
+Howard Experimental [Page 15]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+7. Security Considerations
+
+ The entirety of related security considerations are outside the scope
+ of this document. It is noted that making passwords encrypted with a
+ widely understood hash function (such as crypt()) available to non-
+ privileged users is dangerous because it exposes them to dictionary
+ and brute-force attacks. This is proposed only for compatibility
+ with existing UNIX system implementations. Sites where security is
+ critical SHOULD consider using a strong authentication service for
+ user authentication.
+
+ Alternatively, the encrypted password could be made available only to
+ a subset of privileged DUAs, which would provide "shadow" password
+ service to client applications. This may be difficult to enforce.
+
+ Because the schema represents operating system-level entities, access
+ to these entities SHOULD be granted on a discretionary basis. (There
+ is little point in restricting access to data which will be
+ republished without restriction, however.) It is particularly
+ important that only administrators can modify entries defined in this
+ schema, with the exception of allowing a principal to change their
+ password (which may be done on behalf of the user by a client bound
+ as a superior principal, such that password restrictions may be
+ enforced). For example, if a user were allowed to change the value of
+ their uidNumber attribute, they could subvert security by
+ equivalencing their account with the superuser account.
+
+ A subtree of the DIT which is to be republished by a DUA (such as a
+ NIS gateway) SHOULD be within the same administrative domain that the
+ republishing DUA represents. (For example, principals outside an
+ organization, while conceivably part of the DIT, should not be
+ considered with the same degree of authority as those within the
+ organization.)
+
+ Finally, care should be exercised with integer attributes of a
+ sensitive nature (particularly the uidNumber and gidNumber
+ attributes) which contain zero-length values. DUAs MAY treat such
+ values as corresponding to the "nobody" or "nogroup" user and group,
+ respectively.
+
+8. Acknowledgements
+
+ Thanks to Leif Hedstrom of Netscape Communications Corporation,
+ Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of
+ Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable
+ contributions to the development of this schema. Thanks to Andrew
+ Josey of The Open Group for clarifying the use of the UNIX trademark,
+ and to Tim Howes and Peter J. Cherny for their support.
+
+
+
+Howard Experimental [Page 16]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ UNIX is a registered trademark of The Open Group.
+
+9. References
+
+ [RFC1057]
+ Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol
+ Specification Version 2", RFC 1057, June 1988.
+
+ [RFC1279]
+ Kille, S., "X.500 and Domains", RFC 1279, November 1991.
+
+ [RFC1884]
+ Hinden, R., and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 1884, December 1995.
+
+ [RFC2119]
+ Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251]
+ Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252]
+ Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [RFC2254]
+ Howes, T., "The String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+ [RFC2256]
+ Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [ROSE]
+ M. T. Rose, "The Little Black Book: Mail Bonding with OSI
+ Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc.,
+ 1992.
+
+ [X500]
+ "Information Processing Systems - Open Systems Interconnection -
+ The Directory: Overview of Concepts, Models and Service",
+ ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988.
+
+
+
+
+
+
+Howard Experimental [Page 17]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ [XOPEN]
+ ISO/IEC 9945-1:1990, Information Technology - Portable Operating
+ Systems Interface (POSIX) - Part 1: Systems Application
+ Programming Interface (API) [C Language]
+
+10. Author's Address
+
+ Luke Howard
+ PO Box 59
+ Central Park Vic 3145
+ Australia
+
+ EMail: lukeh@xedoc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Experimental [Page 18]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+A. Example entries
+
+ The examples described in this section are provided to illustrate the
+ schema described in this memo. They are not meant to be exhaustive.
+
+ The following entry is an example of the posixAccount class:
+
+ dn: uid=lester, dc=aja, dc=com
+ objectClass: top
+ objectClass: account
+ objectClass: posixAccount
+ uid: lester
+ cn: Lester the Nightfly
+ userPassword: {crypt}X5/DBrWPOQQaI
+ gecos: Lester
+ loginShell: /bin/csh
+ uidNumber: 10
+ gidNumber: 10
+ homeDirectory: /home/lester
+
+
+ This corresponds the UNIX system password file entry:
+
+ lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
+
+ The following entry is an example of the ipHost class:
+
+ dn: cn=peg.aja.com, dc=aja, dc=com
+ objectClass: top
+ objectClass: device
+ objectClass: ipHost
+ objectClass: bootableDevice
+ objectClass: ieee802Device
+ cn: peg.aja.com
+ cn: www.aja.com
+ ipHostNumber: 10.0.0.1
+ macAddress: 00:00:92:90:ee:e2
+ bootFile: mach
+ bootParameter: root=fs:/nfsroot/peg
+ bootParameter: swap=fs:/nfsswap/peg
+ bootParameter: dump=fs:/nfsdump/peg
+
+ This entry represents the host canonically peg.aja.com, also known as
+ www.aja.com. The Ethernet address and four boot parameters are also
+ specified.
+
+
+
+
+
+
+Howard Experimental [Page 19]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ An example of the nisNetgroup class:
+
+ dn: cn=nightfly, dc=aja, dc=com
+ objectClass: top
+ objectClass: nisNetgroup
+ cn: nightfly
+ nisNetgroupTriple: (charlemagne,peg,dunes.aja.com)
+ nisNetgroupTriple: (lester,-,)
+ memberNisNetgroup: kamakiriad
+
+ This entry represents the netgroup nightfly, which contains two
+ triples (the user charlemagne, the host peg, and the domain
+ dunes.aja.com; and, the user lester, no host, and any domain) and one
+ netgroup (kamakiriad).
+
+ Finally, an example of the nisObject class:
+
+ dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com
+ objectClass: top
+ objectClass: nisMap
+ nisMapName: tracks
+
+ dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com
+ objectClass: top
+ objectClass: nisObject
+ cn: Maxine
+ nisMapName: tracks
+ nisMapEntry: Nightfly$4
+
+ This entry represents the NIS map tracks, and a single map entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Experimental [Page 20]
+\f
+RFC 2307 Using LDAP as a Network Information Service March 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Experimental [Page 21]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group A. Grimstad
+Request for Comments: 2377 R. Huber
+Category: Informational AT&T
+ S. Sataluri
+ Lucent Technologies
+ M. Wahl
+ Critical Angle Inc.
+ September 1998
+
+
+ Naming Plan for Internet Directory-Enabled Applications
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ Application of the conventional X.500 approach to naming has
+ heretofore, in the experience of the authors, proven to be an
+ obstacle to the wide deployment of directory-enabled applications on
+ the Internet. We propose a new directory naming plan that leverages
+ the strengths of the most popular and successful Internet naming
+ schemes for naming objects in a hierarchical directory. This plan
+ can, we believe, by extending the X.500 approach to naming,
+ facilitate the creation of an Internet White Pages Service (IWPS) and
+ other directory-enabled applications by overcoming the problems
+ encountered by those using the conventional X.500 approach.
+
+1.0 Executive Summary
+
+ Application of the conventional X.500 approach to naming has
+ heretofore, in the experience of the authors, proven to be an
+ obstacle to the wide deployment of directory-enabled applications on
+ the Internet. The required registration infrastructure is either
+ non-existent or largely ignored. The infrastructure that does exist
+ is cumbersome to use and tends to produce counterproductive results.
+ The attributes used for naming have been confusing for users and
+ inflexible to managers and operators of directory servers.
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 1]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ This paper describes a directory naming plan for the construction of
+ an Internet directory infrastructure to support directory-enabled
+ applications that can serve as an alternative (or extension) to the
+ conventional X.500 approach.
+
+ The plan has the following two main features. First, it bases the
+ root and upper portions of the name hierarchy on the existing
+ infrastructure of names from the Domain Name System (DNS). This
+ component of the plan makes use of the ideas described in the
+ companion paper to this plan, "Using Domains in LDAP Distinguished
+ Names" [1]. And second, it provides a number of options for the
+ assignment of names to directory leaf objects such as person objects,
+ including an option that allows the reuse of existing Internet
+ identifiers for people.
+
+ Just as the conventional X.500 style of naming is not a formal
+ standard, use of the naming plan described here is not obligatory for
+ directory-enabled applications on the Internet. Other approaches are
+ permissible. However, we believe widespread use of this plan will
+ largely eliminate naming as a typically thorny issue when
+ administrators set up an LDAP-based directory service. Further, we
+ strongly encourage developers of directory-enabled products,
+ especially LDAP clients and user interfaces, to assume that this
+ naming plan will see widespread use and design their products
+ accordingly.
+
+ Here, in summary, is our proposal.
+
+ The upper portions of the hierarchical directory tree should be
+ constructed using the components of registered DNS names using the
+ domain component attribute "dc". The directory name for the
+ organization having the domain name "acme.com" will then be, e.g.,
+
+ dc=acme, dc=com
+
+ Organizations can add additional directory structure, for example to
+ support implementation of access control lists or partitioning of
+ their directory information, by using registered subdomains of DNS
+ names, e.g., the subdomain "corporate.acme.com" can be used as the
+ basis for the directory name
+
+ dc=corporate, dc=acme, dc=com
+
+ For naming directory leaf objects such as persons, groups, server
+ applications and certification authorities in a hierarchical
+ directory, we propose the use of either the "uid" (user identifier)
+ or the "cn" (common name) attribute for the relative distinguished
+ name. This plan does not constrain how these two attributes are used.
+
+
+
+Grimstad, et. al. Informational [Page 2]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ One approach to their use, for example, is to employ the uid
+ attribute as the RDN when reusing an existing store of identifiers
+ and the cn attribute as the RDN when creating new identifiers
+ specifically for the directory. A convenient existing identification
+ scheme for person objects is the RFC822 mailbox identifier. So an RDN
+ for person employing this store of identifiers would be, e.g.,
+
+ uid=John.Smith@acme.com
+
+ For leaf objects not conveniently identified with such a scheme, the
+ "cn" attribute is used, e.g.,
+
+ cn=Reading Room
+
+ Directory distinguished names will thus have the following structure,
+ e.g.,
+
+ uid=John.Smith@acme.com, dc=acme, dc=com
+ uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
+ uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
+ cn=Reading Room, dc=physics, dc=national-lab, dc=edu
+
+2.0 The Problem
+
+ The X.500 Directory model [2] can be used to create a world-wide
+ distributed directory. The Internet X.500 Directory Pilot has been
+ operational for several years and has grown to a size of about 1.5
+ million entries of varying quality. The rate of growth of the pilot
+ is far lower than the rate of growth of the Internet during the pilot
+ period.
+
+ There are a substantial number of contributing factors that have
+ inhibited the growth of this pilot. The common X.500 approach to
+ naming, while not the preponderant problem, has contributed in
+ several ways to limit the growth of an Internet White Pages Service
+ based on X.500.
+
+ The conventional way to construct names in the X.500 community is
+ documented as an informative (i.e., not officially standardized)
+ Annex B to X.521. The relative distinguished name (RDN) of a user
+ consists of a common name (cn) attribute. This is meant to be what --
+ in the user's particular society -- is customarily understood to be
+ the name of that user. The distinguished name of a user is the
+ combination of the name of some general object, such as an
+ organization or a geographical unit, with the common name. There are
+ two main problems with this style of name construction.
+
+
+
+
+
+Grimstad, et. al. Informational [Page 3]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ First, the common name attribute, while seeming to be user-friendly,
+ cannot be used generally as an RDN in practice. In any significant
+ set of users to be named under the same Directory Information Tree
+ (DIT) node there will be collisions on common name. There is no way
+ to overcome this other than either by forcing uniqueness on common
+ names, something they do not possess, or by using an additional
+ attribute to prevent collisions. This additional attribute normally
+ needs to be unique in a much larger context to have any practical
+ value. The end result is a RDN that is very long and unpopular with
+ users.
+
+ Second, and more serious, X.500 has not been able to use any
+ significant number of pre-existing names. Since X.500 naming models
+ typically use organization names as part of the hierarchy [2, 3],
+ organization names must be registered. As organization names are
+ frequently tied to trademarks and are used in sales and promotions,
+ registration can be a difficult and acrimonious process.
+
+ The North American Directory Forum (NADF, now the North Atlantic
+ Directory Forum but still the NADF) proposed to avoid the problem of
+ registration by using names that were already registered in the
+ "civil naming infrastructure" [4][5]. Directory distinguished names
+ would be based on an organization's legal name as recognized by some
+ governmental agency (county clerk, state secretary of state, etc.) or
+ other registering entity such as ANSI.
+
+ This scheme has the significant advantage of keeping directory
+ service providers out of disputes about the right to use a particular
+ name, but it leads to rather obscure names. Among these obscurities,
+ the legal name almost invariably takes a form that is less familiar
+ and longer than what users typically associate with the organization.
+ For example, in the US a large proportion of legal organization names
+ end with the text ", Inc." as in "Acme, Inc." Moreover, in the case
+ of the US, the civil naming infrastructure does not operate
+ nationally, so the organization names it provides must be located
+ under state and regional DIT nodes, making them difficult to find
+ while browsing the directory. NADF proposes a way to algorithmically
+ derive multi-attribute RDNs which would allow placement of entries or
+ aliases in more convenient places in the DIT, but these derived names
+ are cumbersome and unpopular. For example, suppose Nadir is an
+ organization that is registered in New Jersey civil naming
+ infrastructure under the name "Nadir Networks, Inc." Its civil
+ distinguished name (DN) would then be
+
+ o="Nadir Networks, Inc.", st=New Jersey, c=US
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 4]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ while its derived name which is unambiguous under c=US directly is
+
+ o="Nadir Networks, Inc." + st=New Jersey, c=US
+
+ More generally, the requirement for registration of organizations in
+ X.500 naming has led to the establishment of national registration
+ authorities whose function is mainly limited to assignment of X.500
+ organization names. Because of the very limited attraction of X.500,
+ interest in registering an organization with one of these national
+ authorities has been minimal. Finally, multi-national organizations
+ are frustrated by a lack of an international registration authority.
+
+3.0 Requirements
+
+ A directory naming plan must provide a guide for the construction of
+ names (identifiers, labels) for directory objects that are
+ unambiguous (identify only one directory object) within some context
+ (namespace), at a minimum within one isolated directory server.
+
+ A directory object is simply a set of attribute values. The
+ association between a real-world object and a directory object is
+ made by directory-enabled applications and is, in the general case,
+ one to many.
+
+ The following additional naming characteristics are requirements that
+ this naming plan seeks to satisfy:
+
+ a) hierarchical
+
+ The Internet, consisting of a very large number of objects and
+ management domains, requires hierarchical names. Such names permit
+ delegation in the name assignment process and partitioning of
+ directory information among directory servers.
+
+ b) friendly to loose coupling of directory servers
+
+ One purpose of this naming plan is to define a naming pattern that
+ will facilitate one form or another of loose coupling of potentially
+ autonomous directory servers into a larger system.
+
+ A name in such a loosely-coupled system should unambiguously identify
+ one real-world object. The real-world object may, however, be
+ represented differently (i.e. by different directory objects having
+ different attributes but the same DN) in different (e.g.
+ independently managed) servers in the loosely-coupled system. The
+ plan does not attempt to produce names to overcome this likely
+ scenario. That is, it does not attempt to produce a single namespace
+ for all directory objects. (This issue is considered in more detail
+
+
+
+Grimstad, et. al. Informational [Page 5]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ in Section 5.1.)
+
+ c) readily usable by LDAP clients and servers
+
+ As of this writing, a substantial number of the Lightweight Directory
+ Access Protocol (LDAP) [6][7] implementations are currently available
+ or soon will be. The names specified by this naming plan should be
+ readily usable by these implementations and applications based on
+ them.
+
+ d) friendly to re-use of existing Internet name registries
+
+ As described in Section 2 above, creation of new global name
+ registries has been highly problematic. Therefore, a fundamental
+ requirement this plan addresses is to enable the reuse of existing
+ Internet name registries such as DNS names and RFC822 mailbox
+ identifiers when constructing directory names.
+
+ e) minimally user-friendly
+
+ Although we expect that user interfaces of directory-enabled
+ applications will avoid exposing users to DNs, it is unlikely that
+ users can be totally insulated from them. For this reason, the
+ naming plan should permit use of familiar information in name
+ construction. Minimally, a user should be capable of recognizing the
+ information encoded in his/her own DN. Names that are totally opaque
+ to users cannot meet this requirement.
+
+4.0 Name Construction
+
+ The paper assumes familiarity with the terminology and concepts
+ behind the terms distinguished name (DN) and relative distinguished
+ name (RDN) [2][8][9].
+
+ We describe how DNs can be constructed using three attribute types,
+ domainComponent (dc), userID (uid) and commonName (cn). They are
+ each described in turn.
+
+4.1 Domain Component (dc)
+
+ The domain component attribute is defined and registered in RFC1274
+ [3][10]. It is used in the construction of a DN from a domain name.
+ Details of the construction algorithm is described in "Using Domains
+ in LDAP Distinguished Names" [1].
+
+ An organization wishing to deploy a directory following this naming
+ plan would proceed as follows. Consider an organization, for example
+ "Acme, Inc.", having the registered domain name "acme.com". It would
+
+
+
+Grimstad, et. al. Informational [Page 6]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ construct the DN
+
+ dc=acme, dc=com
+
+ from its domain name. It would then use this DN as the root of its
+ subtree of directory information.
+
+ The DN itself can be used to identify a directory organization object
+ that represents information about the organization. The directory
+ schema required to enable this is described below in section 5.2.
+
+ The subordinates of the DN will be directory objects related to the
+ organization. The domain component attribute can be used to name
+ subdivisions of the organization such as organizational units and
+ localities. Acme, for example, might use the domain names
+ "corporate.acme.com" and "richmond.acme.com" to construct the names
+
+ dc=corporate, dc=acme, dc=com
+ dc=richmond, dc=acme, dc=com
+
+ under which to place its directory objects. The directory schema
+ required to name organizationalUnit and locality objects in this way
+ is described below in section 5.2.
+
+ Note that subdivisions of the organization such as organizational
+ units and localities could also be assigned RDNs using the
+ conventional X.500 naming attributes, e.g.
+
+ ou=corporate, dc=acme, dc=com
+ l=richmond, dc=acme, dc=com.
+
+ Use of the dc attribute for the RDN of directory objects of class
+ "domain" is also possible [1].
+
+4.2 User ID (uid)
+
+ The userid (uid) attribute is defined and registered in RFC1274
+ [3][10].
+
+ This attribute may be used to construct the RDN for directory objects
+ subordinate to objects named according to the procedure described in
+ Section 4.1. This plan does not constrain how this attribute is
+ used.
+
+4.3 Common Name (cn)
+
+ The commonName (cn) attribute is defined and registered in X.500
+ [3][11].
+
+
+
+Grimstad, et. al. Informational [Page 7]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ This attribute may be used to construct the RDN for directory objects
+ subordinate to objects named according to the procedure described in
+ Section 4.1. This plan does not constrain how this attribute is
+ used.
+
+4.4 Examples of uid and cn Usage
+
+ Although this plan places no constraints on the use of the uid and cn
+ attributes for name construction, we would like to offer some
+ suggestions by way of examples.
+
+ In practice, we have used uid for the RDN for person objects were we
+ could make use of an existing registry of names and cn for other
+ objects.
+
+ Examples of existing registries of identifiers for person objects are
+ RFC822 mailbox identifiers, employee numbers and employee "handles".
+ Aside from the convenience to administrators of re-use of an existing
+ store of identifiers, if it is ever necessary to display to a user
+ his/her DN, there is some hope that it will be recognizable when such
+ identifiers are used.
+
+ We have found RFC822 mailbox identifiers a particularly convenient
+ source for name construction. When a person has several e-mail
+ addresses, one will be selected for the purpose of user
+ identification. We call this the "distinguished" e-mail address or
+ the "distinguished" RFC822 mailbox identifier for the user.
+
+ For example, if there is a user affiliated with the organization Acme
+ having distinguished e-mail address J.Smith@acme.com, the uid
+ attribute will be:
+
+ uid=J.Smith@acme.com
+
+ The domain component attributes of a user's DN will normally be
+ constructed from the domain name of his/her distinguished e-mail
+ address. That is, for the user uid=J.Smith@acme.com the domain
+ component attributes would typically be:
+
+ dc=acme, dc=com
+
+ The full LDAP DN for this user would then be:
+
+ uid=J.Smith@acme.com, dc=acme, dc=com
+
+ Directory administrators having several RFC822 identifiers to choose
+ from when constructing a DN for a user should consider the following
+ factors:
+
+
+
+Grimstad, et. al. Informational [Page 8]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ o Machine-independent addresses are likely to be more stable,
+ resulting in directory names that change less. Thus an
+ identifier such as:
+
+ js@acme.com
+
+ may well be preferable to one such as:
+
+ js@blaster.third-floor.acme.com.
+
+ o Use of some form of "handle" for the "local" part that is
+ distinct from a user's real name may result in fewer collisions
+ and thereby lessen user pain and suffering. Thus the
+ identifier:
+
+ js@acme.com
+
+ may well be preferable to one such as:
+
+ J.Smith@acme.com
+
+ Practical experience with use of the RFC822 mailbox identifier scheme
+ described here has shown that there are situations where it is
+ convenient to use such identifies for all users in a particular
+ population, although a few users do not, in fact, possess working
+ mailboxes. For example, an organization may have a existing unique
+ identification scheme for all employees that is used as a alias to
+ the employees' real mailboxes -- which may be quite heterogeneous in
+ structure. The identification scheme works for all employees to
+ identify unambiguously each employee; it only works as an e-mail
+ alias for those employees having real mailboxes. For this reason it
+ would be a bad assumption for directory-enabled applications to
+ assume the uid to be a valid mailbox; the value(s) of the mail
+ attribute should always be checked.
+
+ It is important to emphasize that the elements of the domain name of
+ an RFC822 identifier may, BUT NEED NOT, be the same as the domain
+ components of the DN. This means that the domain components provide
+ a degree of freedom to support access control or other directory
+ structuring requirements that need not be mechanically reflected in
+ the user's e-mail address. We do not want under any condition to
+ force the user's e-mail address to change just to facilitate a new
+ system requirement such as a modification in an access control
+ structure. It should also be noted that while we do not require that
+ the domain components match the RFC822 identifier, we DO require that
+ the concatenated domain components form a registered domain name,
+ that is, one that is represented in the DNS. This automatically
+ avoids name conflicts in the directory hierarchy.
+
+
+
+Grimstad, et. al. Informational [Page 9]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ To provide an example of a DN which deviates from what might be
+ considered the default structure, consider the following scenario.
+
+ Suppose that J.Smith needs to be granted special permissions to
+ information in the dc=acme, dc=com part of the LDAP DIT. Since it
+ will be, in general, easier to organize special users by their name
+ structure than via groups (an arbitrary collection of DNs), we use
+ subdomains for this purpose. Suppose the special permissions were
+ required by users in the MIS organizational unit. A subdomain
+ "mis.acme.com" is established, if it does not already exist,
+ according to normal DNS procedures. The special permissions will be
+ granted to users with the name structure:
+
+ uid=*, dc=mis, dc=acme, dc=com
+
+ The DN of J.Smith in this case will be:
+
+ uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
+
+ In principal, there is nothing to prevent the domain name elements of
+ the RFC822 identifier from being completely different from the domain
+ components of the DN. For instance, the DN for a J.Smith could be:
+
+ uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
+
+ While we do not REQUIRE that the domain name part of the uid match
+ the dc components of the directory distinguished name, we suggest
+ that this be done where possible. At a minimum, if the most
+ significant pieces of the DN and the uid are the same (i.e.,
+ "dc=acme, dc=com" and "acme.com") the likelihood, based on a
+ knowledge of a user's e-mail address, of discovering an appropriate
+ directory system to contact to find information about the user is
+ greatly enhanced.
+
+ The example above represents a situation where this suggestion isn't
+ possible because some of the users in a population have mailbox
+ identifiers that differ from the pattern of the rest of the users,
+ e.g., most mailboxes are of the form local@acme.com, but a
+ subpopulation have mailboxes from an ISP and therefore mailboxes of
+ the form local@worldnet.att.net.
+
+5.0 Naming Plan and Directories
+
+5.1 Directory Services Considerations
+
+ We envision the deployment of LDAP-based directory services on the
+ Internet to take the form of loosely coupled LDAP servers. This
+ coupling will occur at two levels.
+
+
+
+Grimstad, et. al. Informational [Page 10]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ Firstly, LDAP servers will be loosely connected into islands (i.e. a
+ set of servers sharing a single DN namespace). The glue connecting
+ the islands will be LDAP referral [12] information configured into
+ the LDAP servers. An LDAP search directed to any server in such an
+ island can be answered, if the information is not available to that
+ server, by an LDAP referral to another, more appropriate server
+ within the same island.
+
+ Secondly, various techniques will be used span LDAP islands. The
+ concept that enables such techniques is the LDAP URL [13]. By
+ combining a DNS host name and port (corresponding to one or more LDAP
+ servers) with a DN, the LDAP URL provides unified high-level
+ identification scheme (an LDAP URL namespace) for directory objects.
+
+ Because an LDAP referral is expressed as one or more LDAP URL, these
+ two levels of coupling may not sharply distinguished in practice.
+
+ We do not envision the X.500 model of a single DIT (i.e. a single DN
+ namespace) to be viable in an environment of competing service
+ providers. This naming plan does not attempt to produce DNs to hide
+ the possibility that a given real-world object may have independently
+ managed directory objects with the same DN associated with it.
+
+5.2 Directory Schema Implications of the Naming Plan
+
+ The traditional directory schema(s) developed for the X.500 standard
+ and its application to the Internet [4] require extension to be used
+ with the naming plan developed here. The extensions described below
+ attempt to reuse existing schema elements as much as possible. The
+ directory objects for which extensions are required are:
+ organization, organizational unit, and various classes of leaf
+ objects. We describe the schema modifications below for organization,
+ organizationalUnit and selected leaf classes.
+
+ So as to continue to use existing structural object classes to the
+ extent possible, we propose supplementing entries based on these
+ classes with additional information from two new auxiliary object
+ classes, dcObject and uidObject. They are specified using the
+ notation in Section 4 of [14].
+
+ The auxiliary object class dcObject is defined in "Using Domains in
+ LDAP Distinguished Names" [1].
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 11]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ The auxiliary object class uidObject is defined as:
+
+ ( 1.3.6.1.1.3.1
+ NAME uidObject
+ SUP top
+ AUXILIARY
+ MUST uid )
+
+5.2.1 Organization Schema
+
+ The dc attribute is employed to construct the RDN of an organization
+ object. This is enabled by adding the auxiliary class dcObject to
+ the organization's objectClass attribute.
+
+5.2.2 Organizational Unit Schema
+
+ The dc attribute is employed to construct the RDN of an
+ organizationalUnit object (which is subordinate in the DIT to either
+ an organization or an organizationalUnit object). This is enabled by
+ adding the auxiliary class dcObject to the organizational unit's
+ objectClass attribute.
+
+5.2.3 Person Schema
+
+ No schema extensions are required for person objects if either the
+ inetOrgPerson [15] (preferred) or the newPilotPerson object classes
+ are used. The attribute uid is permissible in each class. For
+ consistency, the uidObject could be added to person entry objectClass
+ attributes to assist applications filtering on this object class
+ attribute value. Use of other classes for person objects with RDN
+ constructed with the uid attribute such as organizationalPerson
+ requires the use of the uidObject class.
+
+ It has been traditional in X.500 and LDAP directory services to
+ employ the common name (cn) attribute in naming. While this naming
+ plan doesn't require use of the cn attribute in naming, it should be
+ stressed that it is a required attribute in any class derived from
+ the person class and is still quite important. It will play a
+ significant role in enabling searches to find user entries of
+ interest.
+
+5.2.4 Certification Authority Schema
+
+ The certification authority (CA) object class is an auxiliary class,
+ meaning it is essentially a set of additional attributes for a base
+ class such as organizationalRole, organization, organizationalUnit or
+ person. Except in the case where the base structural class is
+ inetOrgPerson, use of the uid attribute to construct the RDN of a CA
+
+
+
+Grimstad, et. al. Informational [Page 12]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ will require the auxiliary class uidObject to permit the uid
+ attribute to be used. In the cases where organizationalUnit or
+ organization is the base class for a CA, use of the auxiliary class
+ dcObject will permit the RDN of the CA to be a domain component.
+
+5.2.5 Server and Server Application Schema
+
+ Servers and server applications are typically represented, for want
+ of anything better, by entries of the object class applicationProcess
+ (or a class derived from it). Sometimes the class applicationEntity
+ is used. In either case, the uid attribute should probably not be
+ employed to construct the RDN of a server or server application
+ object. The standard schema uses the attribute cn for such RDNs.
+
+ Suppose one wants to use this naming plan both in the construction of
+ DNs for SSL server certificates and for their storage in a directory.
+ It is customary for clients connecting via SSL to compare the
+ server's domain name (e.g. from the URL used to contact the server)
+ with the value of the cn attribute in the subject field (i.e.
+ subject's DN) of the server's certificate. For this reason, it is
+ common practice to set the cn attribute to the server's domain name.
+
+ The naming and schema to handle this situation is best explained by
+ an example. Consider the server "host.acme.com". Following the
+ algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
+ dc=host, dc=acme, dc=com is constructed. To conform to the existing
+ practices just described, the server's subject DN for the SSL server
+ certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
+ the server's certificate should be stored in a directory entry with
+ this name. This entry should use application process or application
+ entity as its structural object class and strong authentication user
+ as is auxiliary class.
+
+5.2.6 Name Forms
+
+ For X.500 servers or LDAP servers following the X.500 model, our
+ schema requires the definition of new name forms, structure rules,
+ and DIT content rules. Structure rules and DIT content rules are
+ locally defined, and do not involve a globally significant object
+ identifier.
+
+ The following name forms are defined using the syntax of section 6.22
+ of [14] for the convenience of those using such servers.
+
+ Note that since the structural object classes organization,
+ organizationalUnit, locality and organizationalPerson do not permit
+ inclusion of the dc attribute, an auxiliary object class such as
+ dcObject [1] must be used for instances of these classes.)
+
+
+
+Grimstad, et. al. Informational [Page 13]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+5.2.6.1 Name Form for Domain Objects
+
+ The OIDs in this group are under the
+ iso.org.dod.internet.directory.NameForm branch of the OID tree
+ (1.3.6.1.1.2).
+
+ ( 1.3.6.1.1.2.1
+ NAME domainNameForm
+ OC domain
+ MUST dc )
+
+ The domainNameForm name form indicates that objects of structural
+ object class domain have their RDN constructed from a value of the
+ attribute dc.
+
+5.2.6.2 Name Form for Organization Objects
+
+ ( 1.3.6.1.1.2.2
+ NAME dcOrganizationNameForm
+ OC organization
+ MUST dc )
+
+ The dcOrganizationNameForm name form indicates that objects of
+ structural object class organization have their RDN constructed from
+ a value of the attribute dc.
+
+5.2.6.3 Name Form for Organizational Unit Objects
+
+ ( 1.3.6.1.1.2.3
+ NAME dcOrganizationalUnitNameForm
+ OC organizationalUnit
+ MUST dc )
+
+ The dcOrganizationalUnitNameForm name form indicates that objects of
+ structural object class organizationalUnit have their RDN constructed
+ from a value of the attribute dc.
+
+5.2.6.4 Name Form for Locality Objects
+
+ ( 1.3.6.1.1.2.4
+ NAME dcLocalityNameForm
+ OC locality
+ MUST dc )
+
+ The dcLocalityNameForm name form indicates that objects of structural
+ object class locality have their RDN constructed from a value of the
+ attribute dc.
+
+
+
+
+Grimstad, et. al. Informational [Page 14]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+5.2.6.5 Name Form for Organizational Person Objects
+
+ ( 1.3.6.1.1.2.5
+ NAME uidOrganizationalPersonNameForm
+ OC organizationalPerson
+ MUST uid )
+
+ The uidOrganizationalPersonNameForm name form indicates that objects
+ of structural object class organizationalPerson have their RDN
+ constructed from a value of the attribute uid.
+
+6.0 Security Considerations
+
+ Although access controls may be placed on portions of the DIT to deny
+ browse access to unauthorized clients, it may be possible to infer
+ directory names and DIT structure in such sensitive portions of the
+ DIT from the results of DNS queries. Providing public visibility to
+ some portions of the DIT may assist those make such inferences.
+
+7.0 Acknowledgments
+
+ This plan has emerged in the course of a number of fruitful
+ discussions, especially with David Chadwick, John Dale, Joe Gajewski,
+ Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
+
+8.0 References
+
+ [1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+ Sataluri, "Using Domains in LDAP Distinguished Names", RFC
+ 2247, January 1998.
+
+ [2] X.500: The Directory -- Overview of Concepts, Models, and
+ Service, CCITT Recommendation X.500, December, 1988.
+
+ [3] Barker, P., and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [4] The North American Directory Forum, "A Naming Scheme for
+ c=US", RFC 1255, September 1991.
+
+ [5] The North American Directory Forum, "NADF Standing Documents:
+ A Brief Overview", RFC 1417, February 1993.
+
+ [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+
+
+Grimstad, et. al. Informational [Page 15]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ [8] Kille, S., "A String Representation of Distinguished Names",
+ RFC 1779, March 1995.
+
+ [9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [10] Wahl, M., "A Summary of the Pilot X.500 Schema for use
+ in LDAPv3", Work in Progress.
+
+ [11] Wahl, M., "A Summary of the X.500 User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [12] Howes, T., and M. Wahl, "Referrals and Knowledge References
+ in LDAP Directories", Work in Progress.
+
+ [13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+ [15] Smith, M., "Definition of the inetOrgPerson Object Class",
+ Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 16]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+12. Authors' Addresses
+
+ 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
+ Lucent Technologies
+ Room 4D-335, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: srs@lucent.com
+
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 W Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ EMail: M.Wahl@critical-angle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 17]
+\f
+RFC 2377 A Directory Naming Plan September 1998
+
+
+13. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 18]
+\f
projects / openldap / commitdiff