Network Working Group                                           M. Wahl
INTERNET-DRAFT                                         ISODE Consortium
Obsoletes: RFC 1778                                         A. Coulbeck
                                                       ISODE Consortium
                                                               T. Howes
                                          Netscape Communications Corp.
                                                               S. Kille
                                                       ISODE Consortium
Expires in six months from                                  5 June 1996
Intended Category: Standards Track


                   Lightweight Directory Access Protocol:
                  Standard and Pilot Attribute Definitions
                 <draft-ietf-asid-ldapv3-attributes-01.txt>



1. Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

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 the requirements that must be
   satisfied by encoding rules used to render X.500 directory attribute
   syntaxes into a form suitable for use in the LDAP, then goes on to
   define the encoding rules for the standard set of attribute syntaxes
   of [2],[3] and [4].

3. Table of LDAP Attributes

   This section lists all Attribute Type names defined for this version of
   LDAP.  Servers may support additional names and attributes not listed
   here.  Later documents may define additional types.

3.1 Standard User Attributes

   The attributes listed in this section are those defined in X.520(1993),
   likely to be present in user entries.  Servers must recognize all the
   attributes of this section.

INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

   Attribute Type Name             X.500 OID       Syntax
   ====================            =============== ================
   objectClass                     2.5.4.0         OID
   aliasedObjectName               2.5.4.1         DN
   knowledgeInformation            2.5.4.2         DirectoryString
   cn                              2.5.4.3         DirectoryString
   sn                              2.5.4.4         DirectoryString
   serialNumber                    2.5.4.5         PrintableString
   c                               2.5.4.6         CountryString
   l                               2.5.4.7         DirectoryString
   st                              2.5.4.8         DirectoryString
   o                               2.5.4.10        DirectoryString
   ou                              2.5.4.11        DirectoryString
   title                           2.5.4.12        DirectoryString
   description                     2.5.4.13        DirectoryString
   searchGuide                     2.5.4.14        Guide
   businessCategory                2.5.4.15        DirectoryString
   postalAddress                   2.5.4.16        PostalAddress
   postalCode                      2.5.4.17        DirectoryString
   postOfficeBox                   2.5.4.18        DirectoryString
   physicalDeliveryOfficeName      2.5.4.19        DirectoryString
   telephoneNumber                 2.5.4.20        TelephoneNumber
   telexNumber                     2.5.4.21        TelexNumber
   teletexTerminalIdentifier       2.5.4.22        TeletexTerminalIdentifier
   facsimileTelephoneNumber        2.5.4.23        FacsimileTelephoneNumber
   x121Address                     2.5.4.24        NumericString
   internationaliSDNNumber         2.5.4.25        NumericString
   registeredAddress               2.5.4.26        PostalAddress
   destinationIndicator            2.5.4.27        PrintableString
   preferredDeliveryMethod         2.5.4.28        DeliveryMethod
   presentationAddress             2.5.4.29        PresentationAddress
   supportedApplicationContext     2.5.4.30        OID
   member                          2.5.4.31        DN
   owner                           2.5.4.32        DN
   roleOccupant                    2.5.4.33        DN
   seeAlso                         2.5.4.34        DN
   userPassword                    2.5.4.35        Password
   userCertificate                 2.5.4.36        Certificate
   cACertificate                   2.5.4.37        Certificate
   authorityRevocationList         2.5.4.38        CertificateList
   certificateRevocationList       2.5.4.39        CertificateList
   crossCertificatePair            2.5.4.40        CertificatePair
   name                            2.5.4.41        DirectoryString
   givenName                       2.5.4.42        DirectoryString
   initials                        2.5.4.43        DirectoryString
   generationQualifier             2.5.4.44        DirectoryString
   x500UniqueIdentifier            2.5.4.45        BitString
   dnQualifier                     2.5.4.46        PrintableString
   enhancedSearchGuide             2.5.4.47        EnhancedGuide
   protocolInformation             2.5.4.48        ProtocolInformation
   distinguishedName               2.5.4.49        DN
   uniqueMember                    2.5.4.50        NameAndOptionalUID
   houseIdentifier                 2.5.4.51        DirectoryString


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

3.2. Pilot User Attributes

   These attributes are defined in RFC 1274.

 Attribute Type Name     OID                         Syntax
 ====================    =========================== ================
 uid                     0.9.2342.19200300.100.1.1   CaseIgnoreString
 textEncodedORaddress    0.9.2342.19200300.100.1.2   CaseIgnoreString
 mail                    0.9.2342.19200300.100.1.3   CaseIgnoreIA5String
 info                    0.9.2342.19200300.100.1.4   CaseIgnoreString
 drink                   0.9.2342.19200300.100.1.5   CaseIgnoreString
 roomNumber              0.9.2342.19200300.100.1.6   CaseIgnoreString
 photo                   0.9.2342.19200300.100.1.7   Fax
 userClass               0.9.2342.19200300.100.1.8   CaseIgnoreString
 host                    0.9.2342.19200300.100.1.9   CaseIgnoreString
 manager                 0.9.2342.19200300.100.1.10  DN
 documentIdentifier      0.9.2342.19200300.100.1.11  CaseIgnoreString
 documentTitle           0.9.2342.19200300.100.1.12  CaseIgnoreString
 documentVersion         0.9.2342.19200300.100.1.13  CaseIgnoreString
 documentAuthor          0.9.2342.19200300.100.1.14  DN
 documentLocation        0.9.2342.19200300.100.1.15  CaseIgnoreString
 homePhone               0.9.2342.19200300.100.1.20  TelephoneNumber
 secretary               0.9.2342.19200300.100.1.21  DN
 otherMailbox            0.9.2342.19200300.100.1.22  OtherMailbox
 lastModifiedTime        0.9.2342.19200300.100.1.23  UTCTime
 lastModifiedBy          0.9.2342.19200300.100.1.24  DN
 dc                      0.9.2342.19200300.100.1.25  CaseIgnoreIA5String
 dNSRecord               0.9.2342.19200300.100.1.26  IA5String
 mXRecord                0.9.2342.19200300.100.1.28  IA5String
 nSRecord                0.9.2342.19200300.100.1.29  IA5String
 sOARecord               0.9.2342.19200300.100.1.30  IA5String
 cNAMERecord             0.9.2342.19200300.100.1.31  IA5String
 associatedDomain        0.9.2342.19200300.100.1.37  CaseIgnoreIA5String
 associatedName          0.9.2342.19200300.100.1.38  DN
 homePostalAddress       0.9.2342.19200300.100.1.39  PostalAddress
 personalTitle           0.9.2342.19200300.100.1.40  CaseIgnoreString
 mobile                  0.9.2342.19200300.100.1.41  TelephoneNumber
 pager                   0.9.2342.19200300.100.1.42  TelephoneNumber
 co                      0.9.2342.19200300.100.1.43  CaseIgnoreString
 pilotUniqueIdentifier   0.9.2342.19200300.100.1.44  CaseIgnoreString
 organizationalStatus    0.9.2342.19200300.100.1.45  CaseIgnoreString
 janetMailbox            0.9.2342.19200300.100.1.46  CaseIgnoreIA5String
 mailPreferenceOption    0.9.2342.19200300.100.1.47  MailPreference
 buildingName            0.9.2342.19200300.100.1.48  CaseIgnoreString
 dSAQuality              0.9.2342.19200300.100.1.49  DSAQualitySyntax
 singleLevelQuality      0.9.2342.19200300.100.1.50  DataQualitySyntax
 subtreeMinimumQuality   0.9.2342.19200300.100.1.51  DataQualitySyntax
 subtreeMaximumQuality   0.9.2342.19200300.100.1.52  DataQualitySyntax
 personalSignature       0.9.2342.19200300.100.1.53  Fax
 dITRedirect             0.9.2342.19200300.100.1.54  DN
 audio                   0.9.2342.19200300.100.1.55  Audio
 documentPublisher       0.9.2342.19200300.100.1.56  CaseIgnoreString
 jpegPhoto               0.9.2342.19200300.100.1.60  JPEG


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

3.3. Collective Attributes

   These attributes are stored in collective attribute subentries, but may
   be visible in user entries if requested.  Servers which do not support
   the X.500 protocols are not required to recognize these attributes, and
   non-management clients should not assume they are recognized by the
   server.

    Attribute Type Name                  OID          Syntax
    ====================                 ========== ================
    collectiveLocalityName               2.5.4.7.1  DirectoryString
    collectiveStateOrProvinceName        2.5.4.8.1  DirectoryString
    collectiveStreetAddress              2.5.4.9.1  DirectoryString
    collectiveOrganizationName           2.5.4.10.1 DirectoryString
    collectiveOrganizationalUnitName     2.5.4.11.1 DirectoryString
    collectivePostalAddress              2.5.4.16.1 PostalAddress
    collectivePostalCode                 2.5.4.17.1 DirectoryString
    collectivePostOfficeBox              2.5.4.18.1 DirectoryString
    collectivePhysicalDeliveryOfficeName 2.5.4.19.1 DirectoryString
    collectiveTelephoneNumber            2.5.4.20.1 TelephoneNumber
    collectiveTelexNumber                2.5.4.21.1 TelexNumber
    collectiveTeletexTerminalIdentifier  2.5.4.22.1 TeletexTerminalIdentifier
    collectiveFacsimileTelephoneNumber   2.5.4.23.1 FacsimileTelephoneNumber
    collectiveInternationaliSDNNumber    2.5.4.25.1 NumericString

3.4. Standard Operational Attributes

   These attributes are defined in X.501(1993) Annexes B through E.  All
   servers must recognize the attributes "createTimestamp",
   "modifyTimestamp", "creatorsName", "modifiersName", "attributeTypes",
   "objectClasses" and "subschemaSubentry".  Servers implementing X.500
   protocols must recognize all of the attributes listed here.

   Attribute Type Name        OID          Syntax
   ====================       ============ ================
   createTimestamp            2.5.18.1     GeneralizedTime
   modifyTimestamp            2.5.18.2     GeneralizedTime
   creatorsName               2.5.18.3     DN
   modifiersName              2.5.18.4     DN
   administrativeRole         2.5.18.5     OID
   subtreeSpecification       2.5.18.6     SubtreeSpecification
   collectiveExclusions       2.5.18.7     OID
   subschemaSubentry          2.5.18.10    DN
   dITStructureRules          2.5.21.1     DITStructureRuleDescription
   dITContentRules            2.5.21.2     DITContentRuleDescription
   matchingRules              2.5.21.4     MatchingRuleDescription
   attributeTypes             2.5.21.5     AttributeTypeDescription
   objectClasses              2.5.21.6     ObjectClassDescription
   nameForms                  2.5.21.7     NameFormDescription
   matchingRuleUse            2.5.21.8     MatchingRuleUseDescription
   structuralObjectClass      2.5.21.9     OID
   governingStructureRule     2.5.21.10    INTEGER
   accessControlScheme        2.5.24.1     OID
   prescriptiveACI            2.5.24.4     ACIItem
   entryACI                   2.5.24.5     ACIItem
   subentryACI                2.5.24.6     ACIItem
   dseType                    2.5.12.0     DSEType

INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

   myAccessPoint              2.5.12.1     AccessPoint93
   superiorKnowledge          2.5.12.2     AccessPoint93
   specificKnowledge          2.5.12.3     MasterAndShadowAccessPoints
   nonSpecificKnowledge       2.5.12.4     MasterAndShadowAccessPoints
   supplierKnowledge          2.5.12.5     SupplierInformation
   consumerKnowledge          2.5.12.6     SupplierOrConsumer
   secondaryShadows           2.5.12.7     SupplierAndConsumers

3.5 LDAP-defined attributes

    These attributes are defined in [1].

    Attribute Type Name        Syntax
    ====================       ============
    entryName                  DN
    administratorAddress       IA5String
    currentTime                GeneralizedTime
    serverName                 DN
    certificationPath          CertificationPath
    namingContexts             DN
    altLdapServer              IA5String
    altX500Server              AccessPoint93
    supportedExtension         OID

4. Attribute Syntax Encoding Requirements

   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.

   In these examples where a user-specified string is used as part of a
   larger production (other than a Distinguished Name), a backslash quoting
   mechanism is used to permit encoding the following separator symbol
   character (such as ''' or '$').  The backslash is followed by a pair of
   hexidecimal digits representing the next character.  A backslash itself
   in the string is transmitted as '\5C' or '\5c'.

4.1. Common BNF

   For the purposes of defining the encoding rules for attribute syntaxes,
   the following auxiliary BNF definitions will be used:

     <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'


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

     <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> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
             '/' | ':' | '?' | ' '

     <CRLF> ::= The ASCII newline character with hexadecimal value 0x0A

     <letterstring> ::= <a> | <a> <letterstring>

     <numericstring> ::= <d> | <d> <numericstring>

     <keystring> ::= <a> | <a> <anhstring>

     <anhstring> ::= <k> | <k> <anhstring>

     <printablestring> ::= <p> | <p> <printablestring>

     <space> ::= ' ' | ' ' <space>

     <utf8> ::= any sequence of octets formed from the UTF-8 transformation
                of a BMP character

     <dstring> ::= <utf8> | <utf8> <dstring>

4.2. Undefined and Binary

   Values of types not described in this document or not supported by
   servers are by default encoded as if they were values of type Octet
   String, with the string value being the BER-encoded transfer
   representation of the value.  This encoding format is also used if the
   binary encoding is requested by the client for an attribute.

   All servers must be capable of supporting this form for both generating
   Search results and parsing Add and Modify requests.

5. Standard User Attribute Syntax Encodings

   Servers must recognize all the syntaxes described in this section.

5.1. BitString

   The encoding of a value with BitString syntax is according to the
   following BNF:

      <bitstring> ::= ''' <binary-digits> ''B'

      <binary-digits> ::= '0' <binary-digits> | '1' <binary-digits> |
      empty


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

5.2. PrintableString

   The encoding of a value with PrintableString syntax is the string
   value itself.

5.3. DirectoryString

   A string with DirectoryString syntax is encoded in the UTF-8 form of
   Unicode.  For characters in the PrintableString form, the value is
   encoded as the string value itself.

   If it is of the TeletexString form, then characters which correspond
   to the IA5 subset of TeletexString are mapped directly, those which
   correspond to ISO-8859-1 are transliterated, and those for which there
   is no direct mapping are replaced by a IA5 description of the glyph.

   If it is of the UniversalString or BMPString form, UTF-8 is used to
   encode them.

5.4. Certificate

   Because of the changes from X.509(1988) and X.509(1993) and additional
   planned changes to the syntax to support certificate extensions, no
   string representation is defined, and values with Certificate syntax
   (userCertificate and caCertificate) are only transferred using
   a binary encoding.  The BNF notation in RFC 1778 for "User Certificate"
   is not permitted.

5.5. CertificateList

   Because of the incompatibility of the X.509(1988) and X.509(1993)
   definitions of revocation lists, values with CertificateList syntax
   (certificateRevocationList and authorityRevocationList) are only
   transferred using a binary encoding.  The BNF notation in RFC 1778
   for "Authority Revocation List" is not permitted.

5.6. CertificatePair

   Because the Certificate is being carried in binary, values with
   CertificatePair syntax (crossCertificatePair) are only transferred
   using a binary encoding.  The BNF notation in RFC 1778 for
   "Certificate Pair" is not permitted.

5.7. CountryString

   A value of CountryString syntax is encoded the same as a value of
   DirectoryString syntax.

5.8. DN

   Values with DN (Distinguished Name) syntax are encoded to have the
   representation defined in [5].  Note that this representation is not
   reversible to the original ASN.1 encoding as the CHOICE of any
   DirectoryString element in an RDN is no longer known.


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

5.9. DeliveryMethod

   Values with DeliveryMethod syntax are encoded according to the
   following BNF:

      <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>

      <pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
                'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'

5.10. EnhancedGuide

   Values with the EnhancedGuide syntax are encoded according to the
   following BNF:

       <EnhancedGuide> ::= <objectclass> '#' <criteria> '#' <subset>

       <subset> ::= "baseobject" | "oneLevel" | "wholeSubtree"

    The <criteria> production is defined in the Guide syntax below.

5.11. FacsimileTelephoneNumber

   Values with the FacsimileTelephoneNumber syntax are encoded according
   to the following BNF:

      <fax-number> ::= <printablestring> [ '$' <faxparameters> ]

      <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>

      <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
                   'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'

   In the above, the first <printablestring> is the actual fax number,
   and the <faxparm> tokens represent fax parameters.

5.12. Guide

   Values with the Guide syntax  are encoded according to the following
   BNF:

      <guide-value> ::= [ <object-class> '#' ] <criteria>

     <object-class> ::= an encoded value with OID syntax

     <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"



INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

5.13. NameAndOptionalUID

   The encoding of a value with the NameAndOptionalUID syntax is according
   to the following BNF:

      <NameAndOptionalUID> ::=
                <DistinguishedName> [ '#'  <BitString> ]

5.14. NumericString

   The encoding of a string with the NumericString syntax is the string
   value itself.

5.15. OID

   Values with OID (Object Identifier) syntax are encoded according to the
   following BNF:

      <oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>

      <descr> ::= <keystring>

      <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>

   In the above BNF, <descr> is the syntactic representation of an
   object descriptor, which must consist of letters and digits, starting
   with a letter. When encoding values with OID syntax, the first encoding
   option should be used in preference to the second, which should be used
   in preference to the third wherever possible. That is, in encoding
   object identifiers, object descriptors (where assigned and known by
   the implementation) should be used in preference to numeric oids to
   the greatest extent possible. For example, in encoding the object
   identifier representing an organizationName, the descriptor
   "organizationName" is preferable to "ds.4.10", which is in turn
   preferable to the string "2.5.4.10".  A list of descriptors is given
   in Appendix B.

5.16. Password

   Values with Password syntax are encoded as octet strings.

5.17. PostalAddress

   Values with the PostalAddress syntax are encoded according to the
   following BNF:

      <postal-address> ::= <dstring> | <dstring> '$' <postal-address>

   In the above, each <dstring> component of a postal address value is
   encoded as a value of type DirectoryString syntax.

5.18. PresentationAddress

   Values with the PresentationAddress syntax are encoded to have the
   representation described in [6].


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

5.19. ProtocolInformation

   A value with the ProtocolInformation syntax is encoded according to the
   following BNF:

      <ProtocolInformation> ::= <NetworkAddress> <space> '#'
                                <SetOfProtocolIdentifier>

      <NetworkAddress> ::=   As appears in PresentationAddress

      <SetOfProtocolIdentifiers> ::= <ProtocolIdentifier> |
                                '(' <ProtocolIdentifiers> ')'

      <ProtoccolIdentifiers> ::= <ProtocolIdentifier> |
                           <ProtocolIdentifier> '$' <ProtocolIdentifiers>

      <ProtocolIdentifier> ::= <oid>

   For example,

        NS+12345678 # 1.2.3.4.5

5.20. TelephoneNumber

   Values with the TelephoneNumber syntax are encoded as if they were
   Printable String types.  Telephone numbers are recommended in X.520 to
   be in international form, e.g. "+1 512 305 0280".

5.21. TeletexTerminalIdentifier

   Values with the TeletexTerminalIdentifier syntax are encoded according
   to the following BNF:

      <teletex-id> ::= <ttex-param>  0*('$' <ttx-param>)

      <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 <printablestrings> are subsequent portions
   of the teletex terminal identifier.

5.22. TelexNumber

   Values with the TelexNumber syntax are encoded according to the
   following BNF:

      <telex-number> ::= <actual-number> '$' <country> '$' <answerback>

      <actual-number> ::= <printablestring>

      <country> ::= <printablestring>


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

      <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.

5.23. UTCTime

   Values with UTCTime syntax are encoded as if they were printable
   strings with the strings containing a UTCTime value.

5.24. Boolean

   Values with Boolean 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. Pilot Attribute Syntax Encodings

   Servers must recognize all the syntaxes described in this section.

6.1. Audio

   The encoding of a value with Audio syntax is the octets of the value
   itself, an 8KHz uncompressed encoding compatible with the SunOS
   4.1.3 'play' utility.

6.2. CaseIgnoreIA5String

   The encoding of a value with CaseIgnoreIA5String syntax is the string
   value itself.

6.3. CaseIgnoreString

   The encoding of a value with CaseIgnoreString syntax is the same as the
   encoding of a value with DirectoryString syntax.

6.4. DSAQualitySyntax

   Values with this syntax are encoded according to the following BNF:

      <DsaQualitySyntax> ::= <DSAKeyword> [ '#' <description> ]

      <DSAKeyword> ::= 'DEFUNCT' | 'EXPERIMENTAL' | 'BEST-EFFORT' |
                       'PILOT-SERVICE' | 'FULL-SERVICE'

      <description> ::= encoded as a PrintableString


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

6.5. DataQualitySyntax

   Values with this syntax are encoded according to the following BNF:

      <DataQualitySyntax> ::= <compKeyword> '#' <attrQuality> '#'
                              <listQuality> [ '#' <description> ]

      <attrQuality> ::= <levelKeyword> '+' <compKeyword>

      <listQuality> ::= <list> '$' <list><listQuality>

      <list> ::= <attribute> '+' <attrQuality>

      <compKeyword> ::= 'NONE' | 'SAMPLE' | 'SELECTED' |
                        'SUBSTANTIAL' | 'FULL'

      <levelKeyword> ::= 'UNKNOWN' | 'EXTERNAL' | 'SYSTEM-MAINTAINED' |
                        'USER-SUPPLIED'


6.6. IA5String

   The encoding of a value with IA5String syntax is the string value
   itself.

6.7. JPEG

   Values with JPEG syntax are encoded as if they were octet strings
   containing JPEG images in the JPEG File Interchange Format (JFIF), as
   described in [8].

6.8. MailPreference

   Values with MailPreference syntax are encoded according to the
   following BNF:

      <mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"

6.9. OtherMailbox

   Values of the OtherMailbox syntax are encoded according to the
   following BNF:

      <otherMailbox> ::= <mailbox-type> '$' <mailbox>

      <mailbox-type> ::= an encoded Printable String

      <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.10. Fax

   Values with Fax syntax are encoded as if they were octet strings
   containing Group 3 Fax images as defined in [7].


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

6.11. CaseIgnoreList

   Values with CaseIgnoreList syntax are encoded according to the
   following BNF:

      <caseignorelist> ::= <caseignorestring> |
                           <caseignorestring> '$' <caseignorelist>

      <caseignorestring> ::= a string encoded according to the rules for
                             DirectoryString as above.

6.12. CaseExactList

   Values with CaseExactList syntax are encoded according to the
   following BNF:

      <caseexactlist> ::= <caseexactstring> |
                          <caseexactstring> '$' <caseexactlist>

      <caseexactstring> ::= a string encoded according to the rules for
                            DirectoryString as above.

7. Standard Operational Attribute Syntax Encodings

   All servers must recognize the syntaxes of AttributeTypeDescription,
   GeneralizedTime, INTEGER, and ObjectClassDescription.

   In these syntax definitions the following productions should be used:

   <DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')'

   <DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | ""

   <DirectoryString> ::= ''' <dstring> '''

   <oids> ::= <oid> | '(' <oidlist> ')'

   <oidlist> ::= <oidlist> '$' <oid> | <oid>

7.1. ACIItem

   This syntax appears too complicated for a compact string representation
   be useful.  Thus syntax will use the the binary encoding, which
   contains a BER encoding of the value. It is recommended that clients
   that wish to only determine whether they have been granted permission
   to modify an entry use the modifyRightsReq field in the SearchRequest,
   rather than attempt to parse this syntax.

7.2. AccessPoint93

   Values with AccessPoint93 syntax are encoded according to the
   following BNF:


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

      <AccessPoint93> ::= ( '(' <DistinguishedName> '#'
                          <PresentationAddress> ')' ) |
                   -- Optional protocol info absent, parenthesis required
                          ( '(' <DistinguishedName> '#'
                                <PresentationAddress> '#'
                                <SetOfProtocolInformation ')' )

      <SetOfProtocolInformation> ::= <ProtocolInformation> |
                                 '(' <ProtocolInformationList> ')'

      <ProtocolInformationList> ::= <ProtocolInformation> |
                            <ProtocolInformation> '$'
                            <ProtocolInformationList>


7.3. AttributeTypeDescription

   Values with this syntax are encoded according to the following BNF:

      <AttributeTypeDescription> ::= "("
          <oid>   -- AttributeType identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
          [ "SUP" <oid> ]         -- derived from this AttributeType
          [ "EQUALITY" <oid> ]    -- MatchingRule
          [ "ORDERING" <oid> ]    -- MatchingRule
          [ "SUBSTR" <oid> ]      -- MatchingRule
          [ "SYNTAX" <DirectoryString> ]
          [ "SINGLE-VALUE" ]              -- default multi-valued
          [ "COLLECTIVE" ]                -- default not collective
          [ "NO-USER-MODIFICATION" ]      -- default user modifiable
          [ "USAGE" <AttributeUsage> ]    -- default user applications
          ")"

      <AttributeUsage> ::=
          "userApplications"
      |   "directoryOperation"
      |   "distributedOperation"  -- DSA-shared
      |   "dSAOperation"          -- DSA-specific

   For example,

        ( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' )

7.4. DITContentRuleDescription

   Values with this syntax are encoded according to the following BNF:

      <DITContentRuleDescription> ::= "("
          <oid>   -- Structural ObjectClass identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
          [ "AUX" <oids> ]    -- Auxiliary ObjectClasses
          [ "MUST" <oids> ]   -- AttributeType identifiers
          [ "MAY" <oids> ]    -- AttributeType identifiers
          [ "NOT" <oids> ]    -- AttributeType identifiers
         ")"

INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

7.5. DITStructureRuleDescription

   Values with this syntax are encoded according to the following BNF:

      <DITStructureRuleDescription> ::= "("
          <RuleIdentifier>    -- DITStructureRule identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
          "FORM" <oid>                -- NameForm
          [ "SUP" <RuleIdentifiers> ] -- superior DITStructureRules
      ")"

      <RuleIdentifier> ::= <integer>

      <RuleIdentifiers> ::=
          <RuleIdentifier>
      |
          "(" <RuleIdentifierList> ")"

      <RuleIdentifierList> ::=
          <RuleIdentifierList> <RuleIdentifier>
      |
          -- empty list

7.6. DSEType

   Values with DSEType syntax are encoded according to the following BNF:

      <DSEType> ::= '(' <DSEBitList> ')'

      <DSEBitList> ::= <DSEBit> | <DSEBit> '$' <DSEBitList>

      <DSEBit> ::= 'root' | 'glue' | 'cp' | 'entry' | 'alias' | 'subr' |
                   'nssr' | 'supr' | 'xr' | 'admPoint' | 'subentry' |
                   'shadow' | 'zombie' | 'immSupr' | 'rhob' | 'sa' |
                   'dsSubentry'

7.7. GeneralizedTime

   Values of this syntax are encoded as printable strings, represented
   as specified in X.208.  Note that the time zone must be specified.
   For example,

                199412161032Z


7.8. INTEGER

   Values with INTEGER syntax are encoded as the decimal representation
   of their values, with each decimal digit represented by the its
   character equivalent. So the digit 1 is represented by the character
   "1".


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

7.9. MasterAndShadowAccessPoints

   Values of this syntax are encoded according to the following BNF:

      <MasterAndShadowAccessPoints> ::= <MasterOrShadowAccessPoint> |
                                '(' <MasterAndShadowAccessPointList ')'

      <MasterAndShadowAccessPointList> ::= <MasterOrShadowAccessPoint> |
        <MasterOrShadowAccessPoint> '$' <MasterAndShadowAccessPointList>

      <MasterOrShadowAccessPoint> ::= <category> '#' <AccessPoint93>

      <category> ::= 'master' | 'shadow'

7.10. MatchingRuleDescription

   Values of this syntax are encoded according to the following BNF:

      <MatchingRuleDescription> ::= "("
          <oid>   -- MatchingRule identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
          "SYNTAX" <DirectoryString>
         ")"

7.11. MatchingRuleUseDescription

   Values of this syntax are encoded according to the following BNF:

      <MatchingRuleUseDescription> ::= "("
          <oid>   -- MatchingRule identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
         "APPLIES" <oids>    -- AttributeType identifiers
         ")"

7.12. NameFormDescription

   Values of this syntax are encoded according to the following BNF:

      <NameFormDescription> ::= "("
          <oid>   -- NameForm identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
          "OC" <oid>          -- Structural ObjectClass
          "MUST" <oids>       -- AttributeTypes
          [ "MAY" <oids> ]    -- AttributeTypes
      ")"

7.13. ObjectClassDescription

   Values of this syntax are encoded according to the following BNF:


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

      <ObjectClassDescription> ::= "("
          <oid>   -- ObjectClass identifier
          [ "NAME" <DirectoryStrings> ]
          [ "DESC" <DirectoryString> ]
          [ "OBSOLETE" ]
          [ "SUP" <oids> ]    -- Superior ObjectClasses
          [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural
          [ "MUST" <oids> ]   -- AttributeTypes
          [ "MAY" <oids> ]    -- AttributeTypes
      ")"


7.14. SubtreeSpecification

   Values of this syntax are encoded according to the following BNF:

      <SubtreeSpecification> ::= '(' [<localname>] '#'
                                 [<exclusionlist>] '#'
                                 [<minimum>] '#' [<maximum>] '#'
                                 [<refinement>] ')'

      <localname> ::= <DistinguishedName>

      <exclusionlist> ::= '(' <exclusions> ')'

      <exclusions> ::= <exclusion> | <exclusion> '$' <exclusionlist>



      <exclusion> ::= ( 'before ' <DistinguishedName> ) |
                      ( 'after ' <DistinguishedName> )

      <minimum> ::= <numericstring>

      <maximum> ::= <numericstring>

      <refinement> ::= <oid> | '!' <refinement> |
                       '( &' <refinements> ')' |
                       '( |' <refinements> ')'

      <refinements> ::= <refinement> | <refinement> '$' <refinements>

7.15. SupplierInformation

   Values of this syntax are encoded according to the following BNF:

      <SupplierInformation> ::=
         -- supplier is master --
         '(' 'master' '#' <SupplierOrConsumer> ')' |

         -- supplier is not master, master unspecified --
         '(' 'shadow' '#' <SupplierOrConsumer> ')' |

         -- supplier not master, master specified --
         ['('] 'shadow' '#' <SupplierOrConsumer> '#' <AccessPoint93> [')']


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

7.16. SupplierOrConsumer

   Values of this syntax are encoded according to the following BNF:

     <SupplierOrConsumer> ::= <Agreement> '#' <AccessPoint93>

     <Agreement> ::= <bindingid> '.' <bindingversion>

     <bindingid> ::= <numericstring>

     <bindingversion> ::= <numericstring>

7.17. SupplierAndConsumers

   Values of this syntax are encoded according to the following BNF:

      <SupplierAndConsumers> ::= <Supplier> '#' <Consumers>

      <Suppliers> ::= <AccessPoint93>

      <Consumers> ::= <AccessPoint93> | '(' <AccessPointList> ')'

      <AccessPointList> ::= <AccessPoint93> |
                            <AccessPoint93> '$' <AccessPointList>

8. Security Considerations

   Security issues are not discussed in this memo.

9. Acknowledgements

   This document is based heavily on RFC 1778, written by Tim Howes,
   Steve Kille, Wengyik Yeong and Colin Robbins.

   Many of the attribute syntax encodings defined in this document 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 in this document are
   gratefully acknowledged.

10. Authors Addresses

       Mark Wahl
       ISODE Consortium Inc.
       3925 West Braker Lane, Suite 333
       Austin, TX 78759
       USA

       Phone:  +1 512-305-0280
       EMail:  M.Wahl@isode.com


       Andy Coulbeck
       ISODE Consortium
       The Dome, The Square
       Richmond  TW9 1DT
       United Kingdom

INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

       Phone:  +44 181-332-9091
       EMail:  A.Coulbeck@isode.com


       Tim Howes
       Netscape Communications Corp.
       685 Middlefield
       Mountain View, CA 94043
       USA

       Phone:  +1 415 254-1900
       EMail:   howes@netscape.com


       Steve Kille
       ISODE Consortium
       The Dome, The Square
       Richmond
       TW9 1DT
       UK

       Phone:  +44-181-332-9091
       EMail:  S.Kille@isode.com


11. Bibliography

   [1] M.Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
       Protocol (Version 3)". <draft-ietf-asid-ldapv3-protocol-03.txt>

   [2] The Directory: Selected Attribute Types.  ITU-T Recommendation
       X.520, 1993.

   [3] The Directory: Models. ITU-T Recommendation X.501, 1993.

   [4] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
       1274, November 1991.

   [5] Kille, S., "A String Representation of Distinguished Names", RFC
       1779, ISODE Consortium, March 1995.

   [6] Kille, S., "A String Representation for Presentation Addresses",
       RFC 1278, University College London, 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.


INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996

Appendix A- Object Classes

        Descriptor                      X.500 OID Value
        ==============================  ===========================
        top                             2.5.6.0
        alias                           2.5.6.1
        country                         2.5.6.2
        locality                        2.5.6.3
        organization                    2.5.6.4
        organizationalUnit              2.5.6.5
        person                          2.5.6.6
        organizationalPerson            2.5.6.7
        organizationalRole              2.5.6.8
        groupOfNames                    2.5.6.9
        residentialPerson               2.5.6.10
        applicationProcess              2.5.6.11
        applicationEntity               2.5.6.12
        dSA                             2.5.6.13
        device                          2.5.6.14
        strongAuthenticationUser        2.5.6.15
        certificationAuthority          2.5.6.16
        groupOfUniqueNames              2.5.6.17
        pilotObject                     0.9.2342.19200300.100.4.3
        newPilotPerson                  0.9.2342.19200300.100.4.4
        account                         0.9.2342.19200300.100.4.5
        document                        0.9.2342.19200300.100.4.6
        room                            0.9.2342.19200300.100.4.7
        documentSeries                  0.9.2342.19200300.100.4.9
        domain                          0.9.2342.19200300.100.4.13
        rFC822localPart                 0.9.2342.19200300.100.4.14
        dNSDomain                       0.9.2342.19200300.100.4.15
        domainRelatedObject             0.9.2342.19200300.100.4.17
        friendlyCountry                 0.9.2342.19200300.100.4.18
        simpleSecurityObject            0.9.2342.19200300.100.4.19
        pilotOrganization               0.9.2342.19200300.100.4.20
        pilotDSA                        0.9.2342.19200300.100.4.21
        qualityLabelledData             0.9.2342.19200300.100.4.23

Appendix B. - Other OID descriptors

   In addition, servers should recognize at the minimum the following
   descriptors as prefixes of other OIDs, e.g. "enterprises.453.13.3".
   Clients should attempt to ensure that any OIDs they transmit are in
   terms of only these descriptors, with additional components in numeric
   form.

        Descriptor                      Value
        ==============================  ===========================

        ccitt                           0
        iso                             1
        joint                           2
        identifiedOrganization          1.3
        dod                             1.3.6
        internet                        1.3.6.1
        private                         1.3.6.1.4
        enterprises                     1.3.6.1.4.1

<draft-ietf-asid-ldapv3-attributes-01.txt> Expires: December 5, 1996
INTERNET-DRAFT   LDAPv3 Standard and Pilot Attribute Definitions   June 1996