Network Working Group M. Wahl INTERNET-DRAFT Critical Angle Inc. Obsoletes: RFC 1778 A. Coulbeck Isode Limited T. Howes Netscape Communications Corp. S. Kille Isode Limited Intended Category: Standards Track 24 March 1997 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions <draft-ietf-asid-ldapv3-attributes-04.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 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 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. 4. General Issues This document describes encodings used in an Internet protocol. Terms are defined in [4]. Wahl, Coulbeck, Howes, Kille Page 1 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 4.1. 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>, <DirectoryStrings> and <DirectoryString> are given in sections 4.2.1. <AttributeTypeDescription> ::= "(" <oid> -- AttributeType identifier [ "NAME" <DirectoryStrings> ] -- name used in AttributeType [ "DESC" <DirectoryString> ] [ "OBSOLETE" ] [ "SUP" <oid> ] -- derived from this other AttributeType [ "EQUALITY" <oid> ] -- Matching Rule name [ "ORDERING" <oid> ] -- Matching Rule name [ "SUBSTR" <oid> ] -- Matching Rule name [ "SYNTAX" <DirectoryString> ] -- see section 4.2 [ "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, 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 implement all the attribute types referenced in section 5: they MUST be able to perform equality matching of values, but need not perform any additional validity checks on attribute values. Servers MAY recognize additional names and attributes not listed in this document, and if they do so, SHOULD publish the definitions of the types in the attributeTypes attribute of their subschema subentries. AttributeDescriptions can be used as the value in a NAME part of an AttributeTypeDescription. Note that these are case insensitive. 4.2. 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. Wahl, Coulbeck, Howes, Kille Page 2 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 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. 4.2.1. Common Encoding Aspects In these encodings where an arbitrary string is used as part of a larger production (other than a Distinguished Name), a backslash quoting mechanism is used to encode 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'. 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> | ''' | '(' | ')' | '+' | ',' | '-' | '.' | '/' | ':' | '?' | ' ' <letterstring> ::= <a> | <a> <letterstring> <numericstring> ::= <d> | <d> <numericstring> <keystring> ::= <a> | <a> <anhstring> <anhstring> ::= <k> | <k> <anhstring> <printablestring> ::= <p> | <p> <printablestring> <space> ::= ' ' | ' ' <space> <whsp> ::= <space> | empty Wahl, Coulbeck, Howes, Kille Page 3 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 <utf8> ::= any sequence of octets formed from the UTF-8 [9] transformation of a character from ISO 10646 [10] <dstring> ::= <utf8> | <utf8> <dstring> <DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')' <DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | "" <DirectoryString> ::= ''' <dstring> ''' <oids> ::= <oid> | '(' <oidlist> ')' <oidlist> ::= <oidlist> '$' <oid> | <oid> 4.2.2 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 'Binary'. The value, an instance of the ASN.1 AttributeValue type, is BER-encoded, subject to the restrictions of section 5.1 of [1], and this sequence of octets is used as the value. 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 'Binary'. Clients MUST be prepared receiving values in binary (e.g. userCertificate or audio), and MUST NOT simply display binary or unrecognized values to users. 4.2.3. Syntax Names Names of syntaxes for use with LDAP are ASCII strings which either begin with a letter and contain only letters or digits. The names are case insensitive. Historically since syntaxes correspond to ASN.1 types, they have been named starting with a capital letter. A suggested minimum upper bound on the number of characters in value with a DirectoryString or IA5String 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. For instance, "DirectoryString{64}" suggests that server implementations should allow the string to be 64 characters long, althoough they may allow longer strings. Note that a single character of the DirectoryString may be encoded in more than one byte since UTF-8 is a variable-length encoding. Syntax names do not have global scope: two clients or servers may know of different syntaxes with the same name. The definition of additional arbitrary syntaxes is strongly depreciated 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 DirectoryString syntax. Wahl, Coulbeck, Howes, Kille Page 4 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 4.3. Object Classes Object class descriptions are written according to the following BNF: <ObjectClassDescription> ::= "(" <oid> -- ObjectClass identifier [ "NAME" <DirectoryStrings> ] [ "DESC" <DirectoryString> ] [ "OBSOLETE" ] [ "SUP" <oids> ] -- Superior ObjectClasses [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural [ "MUST" <oids> ] -- AttributeTypes [ "MAY" <oids> ] -- AttributeTypes ")" 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, SHOULD publish the definitions of the classes in the objectClasses attribute of their subschema subentries. Later documents may define additional object classes. 4.4. Matching Rules Matching rules are used by servers to compare attribute values against assertion values when performing Search and Compare operations. 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: <MatchingRuleDescription> ::= "(" <oid> -- MatchingRule identifier [ "NAME" <DirectoryStrings> ] [ "DESC" <DirectoryString> ] [ "OBSOLETE" ] "SYNTAX" <DirectoryString> ")" Servers 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, SHOULD publish the definitions of the matching rules in the matchingRules attribute of their subschema subentries. Wahl, Coulbeck, Howes, Kille Page 5 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 5. Attribute Types All LDAP server implementations MUST recognize the attribute types defined in this section. These types are based on definitions in X.501(93) [3]. Servers SHOULD also recognize all the attributes from section 5 of [12], from section 5 of [13]. 5.1. Standard Operational Attributes 5.1.1. createTimestamp ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 5.1.2. modifyTimestamp ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 5.1.3. creatorsName ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 'DN' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 5.1.4. modifiersName ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 'DN' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 5.1.5. subschemaSubentry The value of this attribute is the name of a subschema subentry, an entry in which the server makes available attributes specifying the schema. ( 2.5.18.10 NAME 'subschemaSubentry' EQUALITY distinguishedNameMatch SYNTAX 'DN' NO-USER-MODIFICATION SINGLE-VALUE USAGE directoryOperation ) 5.1.6. attributeTypes ( 2.5.21.5 NAME 'attributeTypes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 'AttributeTypeDescription' USAGE directoryOperation ) 5.1.7. objectClasses ( 2.5.21.6 NAME 'objectClasses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 'ObjectClassDescription' USAGE directoryOperation ) Wahl, Coulbeck, Howes, Kille Page 6 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 5.2. LDAP Operational Attributes These attributes are only present in the root DSE. 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 'DN' 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 'IA5String' 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. ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' SYNTAX 'OID' 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 'OID' USAGE dSAOperation ) Wahl, Coulbeck, Howes, Kille Page 7 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 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 'LDAPString' 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 'INTEGER' USAGE dSAOperation ) 6. Syntaxes Servers SHOULD recognize all the syntaxes described in this section (6.1 - 6.3). 6.1. AttributeTypeDescription Values with this syntax are encoded according to the BNF given at the start of section 4.1. For example, ( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' ) 6.2. 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.3. 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 Example: '0101111101'B Wahl, Coulbeck, Howes, Kille Page 8 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 6.4. 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.5. 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 with Certificate 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. CertificateList Because of the incompatibility of the X.509(1988) and X.509(1993) definitions of revocation lists, values with CertificateList 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. CertificatePair Because the Certificate is being carried in binary, values with CertificatePair 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. 6.8. CountryString A value of CountryString syntax is encoded the same as a value of DirectoryString syntax. Note that this syntax is limited to values of exactly two printable string characters. <CountryString> ::= <p> <p> Example: US Wahl, Coulbeck, Howes, Kille Page 9 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 6.9. DN Values with DN (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\C7 6.10. DirectoryString A string with DirectoryString 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, in values. 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]. 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. 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 ")" Wahl, Coulbeck, Howes, Kille Page 10 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 6.12. 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. 6.13. Fax Values with Fax syntax are encoded as if they were octet strings containing Group 3 Fax images as defined in [7]. 6.14. 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 6.15. IA5String The encoding of a value with IA5String syntax is the string value itself. 6.16. 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 number 1321 is represented by the character string "1321". 6.17. 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]. Wahl, Coulbeck, Howes, Kille Page 11 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 6.18. 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 ")" 6.19. MHSORAddress Values of type MHSORAddress are encoded as strings, according to the format defined in [11]. 6.20. NameAndOptionalUID The encoding of a value with the NameAndOptionalUID syntax is 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.21. 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 ")" Wahl, Coulbeck, Howes, Kille Page 12 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 6.22. NumericString The encoding of a string with the NumericString syntax is the string value itself. Example: 1997 6.23. ObjectClassDescription Values of this syntax are encoded according to the BNF in section 4.3. 6.24. OID Values with OID (Object Identifier) syntax are encoded according to the following BNF: <oid> ::= <descr> | <numericoid> <descr> ::= <keystring> <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid> In the above BNF, <descr> is the syntactic representation of an object descriptor, which consists of letters and digits, starting with a letter. When encoding values with OID syntax, the first encoding option MUST be used in preference to the second. That is, in encoding object identifiers, object descriptors (where assigned and known by the implementation) must be used in preference to numeric oids to the greatest extent possible. All permitted object descriptors for use in LDAP are given in this document. No other object descriptors may be used. (Note that clients should expect that LDAPv2 implementations will return object descriptors other than those listed.) Example: 1.2.3.4 cn 6.25. 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>. Wahl, Coulbeck, Howes, Kille Page 13 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 6.26. Password Values with Password syntax are encoded as octet strings. Example: secret 6.27. 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. Backslashes and dollar characters, if they occur in the component, are quoted as described in section 4.2. Example: 1234 Main St.$Anytown, CA 12345$USA \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 6.28. PresentationAddress Values with the PresentationAddress syntax are encoded to have the representation described in [6]. 6.29. PrintableString The encoding of a value with PrintableString 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. 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. Example: +1 512 305 0280 6.31. UTCTime Values with UTCTime syntax are encoded as if they were printable strings with the strings containing a UTCTime value. This is historical; new attribute definitions will use GeneralizedTime instead. Wahl, Coulbeck, Howes, Kille Page 14 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 7. Object Classes Servers SHOULD recognize all the names of standard classes from section 7 of [12], as well as the names of the Internet classes from section 7 of [13]. 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 known to the server. ( 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. 8. Matching Rules Servers which implement extensibleMatch SHOULD recognize the following matching rules, used for equality matching, and be capable of performing the matching rules. For all these rules, the assertion syntax is the same as the value syntax. ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 'OID' ) ( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 'DN' ) ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 'DirectoryString' ) ( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 'NumericString' ) ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 'PostalAddress' ) ( 2.5.13.14 NAME 'integerMatch' SYNTAX 'INTEGER' ) ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 'BitString' ) ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 'Password' ) ( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 'TelephoneNumber' ) ( 2.5.13.22 NAME 'presentationAddressMatch' SYNTAX 'PresentationAddress' ) ( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 'NameAndOptionalUID' ) ( 2.5.13.24 NAME 'protocolInformationMatch' SYNTAX 'ProtocolInformation' ) ( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 'GeneralizedTime' ) ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 'IA5String' ) ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 'IA5String' ) 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. 9. Security Considerations Security issues are not discussed in this memo. Wahl, Coulbeck, Howes, Kille Page 15 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 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 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. 11. Authors Addresses Mark Wahl Critical Angle Inc. 4815 West Braker Lane #502-385 Austin, TX 78759 USA EMail: M.Wahl@critical-angle.com Andy Coulbeck Isode Limited The Dome, The Square Richmond TW9 1DT United Kingdom Phone: +44 181-332-9091 EMail: A.Coulbeck@isode.com Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd Mountain View, CA 94043 USA Phone: +1 415 254-1900 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, Coulbeck, Howes, Kille Page 16 INTERNET-DRAFT LDAPv3 Attribute Syntax Definitions March 1997 12. Bibliography [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT <draft-ietf-asid-ldapv3-protocol-04.txt>, March 1997. [2] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1993. [3] The Directory: Models. ITU-T Recommendation X.501, 1993. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", INTERNET-DRAFT <draft-bradner-key-words-03.txt>. [5] M. Wahl, S. Kille, "A UTF-8 String Representation of Distinguished Names", INTERNET-DRAFT <draft-ietf-asid-ldapv3-dn-02.txt>, March 1997. [6] S. Kille, "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. [9] F. Yergeau, "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. [11] H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson, "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495, August 1993. [12] M. Wahl, "X.500(93) User Schema for use with LDAP", INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-x500-00.txt>, March 1997. [13] M. Wahl, "Pilot Internet Schema for use with LDAP", INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-pilot-00.txt>, March 1997. <draft-ietf-asid-ldapv3-attributes-04.txt> Expires: September 1997 Wahl, Coulbeck, Howes, Kille Page 17
Datatracker
draft-ietf-asid-ldapv3-attributes-04
Internet-Draft
