Network Working Group M. Wahl INTERNET-DRAFT ISODE Consortium Obsoletes: RFC 1778 A. Coulbeck ISODE Consortium T. Howes University of Michigan S. Kille ISODE Consortium Expires in six months from 23 February 1996 Intended Category: Standards Track Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions <draft-ietf-asid-ldapv3-attributes-00.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 INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 The attributes listed in this section are those defined in X.520(1993), likely to be present in user entries. Attribute Type Name OID Syntax ==================== =============== ================ objectClass 2.5.4.0 OID aliasedObjectName 2.5.4.1 DN knowledgeInformation 2.5.4.2 DirectoryString commonName 2.5.4.3 DirectoryString cn 2.5.4.3 DirectoryString surname 2.5.4.4 DirectoryString sn 2.5.4.4 DirectoryString serialNumber 2.5.4.5 PrintableString countryName 2.5.4.6 CountryString c 2.5.4.6 CountryString localityName 2.5.4.7 DirectoryString l 2.5.4.7 DirectoryString stateOrProvinceName 2.5.4.8 DirectoryString st 2.5.4.8 DirectoryString streetAddress 2.5.4.9 DirectoryString street 2.5.4.9 DirectoryString organizationName 2.5.4.10 DirectoryString o 2.5.4.10 DirectoryString organizationalUnitName 2.5.4.11 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 INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 initials 2.5.4.43 DirectoryString generationQualifier 2.5.4.44 DirectoryString ds.4.45 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 3.2. Pilot User Attributes These attributes are defined in RFC 1274. Attribute Type Name OID Syntax ==================== =============================== ================ userid 0.9.2342.19200300.100.1.1 CaseIgnoreString uid 0.9.2342.19200300.100.1.1 CaseIgnoreString textEncodedORaddress 0.9.2342.19200300.100.1.2 CaseIgnoreString rfc822Mailbox 0.9.2342.19200300.100.1.3 CaseIgnoreIA5String mail 0.9.2342.19200300.100.1.3 CaseIgnoreIA5String info 0.9.2342.19200300.100.1.4 CaseIgnoreString favouriteDrink 0.9.2342.19200300.100.1.5 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 domainComponent 0.9.2342.19200300.100.1.25 CaseIgnoreIA5String 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 mobileTelephoneNumber 0.9.2342.19200300.100.1.41 TelephoneNumber mobile 0.9.2342.19200300.100.1.41 TelephoneNumber pagerTelephoneNumber 0.9.2342.19200300.100.1.42 TelephoneNumber pager 0.9.2342.19200300.100.1.42 TelephoneNumber friendlyCountryName 0.9.2342.19200300.100.1.43 CaseIgnoreString co 0.9.2342.19200300.100.1.43 CaseIgnoreString INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 ccitt.9.2342.19200300.100.1.44 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 3.3. Collective Attributes These attributes are stored in collective attribute subentries, but may be visible in user entries if requested. 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. 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 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 INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 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 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 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. However, if it is necessary to obtain the a reversible encoding in order to make of an attribute (e.g. userCertificate) then this requirement takes precedence over the requirement for the attribute to be human-readable. 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' <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 INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 <letterstring> ::= <a> | <a> <letterstring> <numericstring> ::= <d> | <d> <numericstring> <keystring> ::= <a> | <a> <anhstring> <anhstring> ::= <k> | <k> <anhstring> <printablestring> ::= <p> | <p> <printablestring> <space> ::= ' ' | ' ' <space> 4.2. Undefined and Binary Values of types not described in this document or not supported by servers are be 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. 4.3. Readable If the client has requested that all attributes be transferred in a readable form, then undefined values are pretty-printed in ASN.1 value notation to make an IA5 string. If there are any character string values which contain non-printing characters, these strings are pretty- printed in the hexidecimal representation as used for octet strings. Client applications should only use the readable form when retrieving attributes from searches. Servers may not be able to handle this form as input to Add and Modify operations. 5. Standard User Attribute Syntax Encodings 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 5.2. PrintableString The encoding of a value with PrintableString syntax is the string value itself. INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 5.3. DirectoryString A string with DirectoryString syntax is encoded depending on the ASN.1 form chosen in that string, and the setting of the preferredSyntax Server Control made by the client earlier in this session. If it is of 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. For example, should a TeletexString consist of the symbol for one-half, this could be converted to the string [1/2] Client applications should avoid generating TeletexString characters other than those of IA5. If it is of the UniversalString or BMPString form, then implementations may if they support these forms attempt to convert them to IA5. Otherwise the encoding should be an empty string. Subsequent documents may provide additional mechanisms for controlling how a DirectoryString is transferred, based on alternative encoding preferences. 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 the 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 the 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 the 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. INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 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. 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> INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 <criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] | [ '(' ] <criteria> '|' <criteria-set> [ ')' ] <criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ] <match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" 5.13. NameAndOptionalUID The encoding of a value with the NameAndOptionalUID syntax is according to the following BNF: <NameAndOptionalUID> ::= '(' <DistinguishedName> ')' | ['('] <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 A. 5.16. Password Values with Password syntax are encoded as if they were of type octetStringSyntax. 5.17. PostalAddress Values with the PostalAddress syntax are encoded according to the following BNF: INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 <postal-address> ::= <t61string> | <t61string> '$' <postal-address> In the above, each <t61string> component of a postal address value is encoded as a value of type t61StringSyntax. 5.18. PresentationAddress Values with the PresentationAddress syntax are encoded to have the representation described in [6]. 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. 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. INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 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> <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. Pilot Attribute Syntax Encodings 6.1. Audio The encoding of a value with Audio syntax is the octets of the value itself, a 8KHz encoding compatible with the sun '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. Note that for compatibility with X.500(1988) only the PrintableString and TeletexString forms of DirectoryString should be used. 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 6.5. DataQualitySyntax Values with this syntax are encoded according to the following BNF: <DataQualitySyntax> ::= <compKeyword> '#' <attrQuality> '#' <listQuality> [ '#' <description> ] INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 <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]. 6.11. UTCTime Values with UTCTime syntax are encoded as if they were printable strings with the strings containing a UTCTime value. INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 6.12. OctetString The encoding of a value with OctetString syntax is the string value itself. 6.13. T61String The encoding of a value with T61String syntax is the string value itself. 6.14. 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.15. 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. 6.16. 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. 7. Standard Operational Attribute Syntax Encodings 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. INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 7.2. AccessPoint93 Values with AccessPoint93 syntax are encoded according to the following BNF: <AccessPoint93> ::= ( '(' <DistinguishedName> '#' <PresentationAddress> ')' ) | -- Optional protocol info absent, parenthesis required ( '(' <DistinguishedName> '#' <PresentationAddress> '#' <SetOfProtocolInformation ')' ) <SetOfProtocolInformation> ::= <ProtocolInformation> | '(' <ProtocolInformationList> ')' <ProtocolInformationList> ::= <ProtocolInformation> | <ProtocolInformation> '$' <ProtocolInformationList> 7.3. AttributeTypeDescription No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 7.4. DITContentRuleDescription No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 7.5. DITStructureRuleDescription No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 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 INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 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". 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 No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 7.11. MatchingRuleUseDescription No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 7.12. NameFormDescription No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 7.13. ObjectClassDescription No printable representation is defined, this syntax uses the binary encoding which contains a BER encoding of the value. 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> INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 <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> [')'] 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. INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 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 Ltd. The Dome, The Square Richmond TW9 1DT United Kingdom Phone: +44 181-332-9091 EMail: A.Coulbeck@isode.com Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943 USA Phone: +1 313 747-4454 EMail: tim@umich.edu Steve Kille ISODE Consortium The Dome, The Square Richmond TW9 1DT UK Phone: +44-181-332-9091 EMail: S.Kille@isode.com INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 11. Bibliography [1] M.Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)". <draft-ietf-asid-ldapv3-protocol-00.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. Appendix A- Permitted OID descriptors Attribute type names listed above may be used as descriptions for OIDs, as well as the following. A.1. Object classes Descriptor Value ============================== =========================== top 2.5.6.0 alias 2.5.6.1 country 2.5.6.2 INTERNET-DRAFT Standard and Pilot Attribute Definitions February 1996 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 A.2. Other 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 memberBody 1.2 ansi 1.2.840 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 ds 2.5 standardObjectClass 2.5.6
Datatracker
draft-ietf-asid-ldapv3-attributes-00
Internet-Draft
