idnits 2.17.1 draft-ietf-asid-ldapv3-attributes-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 7) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 80 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1778, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 29 has weird spacing: '...listing conta...' == Line 429 has weird spacing: '... syntax are e...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 February 1996) is 10280 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 926 looks like a reference -- Missing reference section? '2' on line 929 looks like a reference -- Missing reference section? '3' on line 932 looks like a reference -- Missing reference section? '4' on line 934 looks like a reference -- Missing reference section? '5' on line 937 looks like a reference -- Missing reference section? '6' on line 940 looks like a reference -- Missing reference section? '8' on line 947 looks like a reference -- Missing reference section? '7' on line 943 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT ISODE Consortium 3 Obsoletes: RFC 1778 A. Coulbeck 4 ISODE Consortium 5 T. Howes 6 University of Michigan 7 S. Kille 8 ISODE Consortium 9 Expires in six months from 23 February 1996 10 Intended Category: Standards Track 12 Lightweight Directory Access Protocol: 13 Standard and Pilot Attribute Definitions 14 16 1. Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 2. Abstract 35 The Lightweight Directory Access Protocol (LDAP) [1] requires that the 36 contents of AttributeValue fields in protocol elements be octet 37 strings. This document defines the requirements that must be 38 satisfied by encoding rules used to render X.500 Directory attribute 39 syntaxes into a form suitable for use in the LDAP, then goes on to 40 define the encoding rules for the standard set of attribute syntaxes 41 of [2],[3] and [4]. 43 3. Table of LDAP Attributes 45 This section lists all Attribute Type names defined for this version of 46 LDAP. Servers may support additional names and attributes not listed 47 here. Later documents may define additional types. 49 3.1 Standard User Attributes 50 The attributes listed in this section are those defined in X.520(1993), 51 likely to be present in user entries. 53 Attribute Type Name OID Syntax 54 ==================== =============== ================ 55 objectClass 2.5.4.0 OID 56 aliasedObjectName 2.5.4.1 DN 57 knowledgeInformation 2.5.4.2 DirectoryString 58 commonName 2.5.4.3 DirectoryString 59 cn 2.5.4.3 DirectoryString 60 surname 2.5.4.4 DirectoryString 61 sn 2.5.4.4 DirectoryString 62 serialNumber 2.5.4.5 PrintableString 63 countryName 2.5.4.6 CountryString 64 c 2.5.4.6 CountryString 65 localityName 2.5.4.7 DirectoryString 66 l 2.5.4.7 DirectoryString 67 stateOrProvinceName 2.5.4.8 DirectoryString 68 st 2.5.4.8 DirectoryString 69 streetAddress 2.5.4.9 DirectoryString 70 street 2.5.4.9 DirectoryString 71 organizationName 2.5.4.10 DirectoryString 72 o 2.5.4.10 DirectoryString 73 organizationalUnitName 2.5.4.11 DirectoryString 74 ou 2.5.4.11 DirectoryString 75 title 2.5.4.12 DirectoryString 76 description 2.5.4.13 DirectoryString 77 searchGuide 2.5.4.14 Guide 78 businessCategory 2.5.4.15 DirectoryString 79 postalAddress 2.5.4.16 PostalAddress 80 postalCode 2.5.4.17 DirectoryString 81 postOfficeBox 2.5.4.18 DirectoryString 82 physicalDeliveryOfficeName 2.5.4.19 DirectoryString 83 telephoneNumber 2.5.4.20 TelephoneNumber 84 telexNumber 2.5.4.21 TelexNumber 85 teletexTerminalIdentifier 2.5.4.22 TeletexTerminalIdentifier 86 facsimileTelephoneNumber 2.5.4.23 FacsimileTelephoneNumber 87 x121Address 2.5.4.24 NumericString 88 internationaliSDNNumber 2.5.4.25 NumericString 89 registeredAddress 2.5.4.26 PostalAddress 90 destinationIndicator 2.5.4.27 PrintableString 91 preferredDeliveryMethod 2.5.4.28 DeliveryMethod 92 presentationAddress 2.5.4.29 PresentationAddress 93 supportedApplicationContext 2.5.4.30 OID 94 member 2.5.4.31 DN 95 owner 2.5.4.32 DN 96 roleOccupant 2.5.4.33 DN 97 seeAlso 2.5.4.34 DN 98 userPassword 2.5.4.35 Password 99 userCertificate 2.5.4.36 Certificate 100 cACertificate 2.5.4.37 Certificate 101 authorityRevocationList 2.5.4.38 CertificateList 102 certificateRevocationList 2.5.4.39 CertificateList 103 crossCertificatePair 2.5.4.40 CertificatePair 104 name 2.5.4.41 DirectoryString 105 givenName 2.5.4.42 DirectoryString 106 initials 2.5.4.43 DirectoryString 107 generationQualifier 2.5.4.44 DirectoryString 108 ds.4.45 2.5.4.45 BitString 109 dnQualifier 2.5.4.46 PrintableString 110 enhancedSearchGuide 2.5.4.47 EnhancedGuide 111 protocolInformation 2.5.4.48 ProtocolInformation 112 distinguishedName 2.5.4.49 DN 113 uniqueMember 2.5.4.50 NameAndOptionalUID 114 houseIdentifier 2.5.4.51 DirectoryString 116 3.2. Pilot User Attributes 118 These attributes are defined in RFC 1274. 120 Attribute Type Name OID Syntax 121 ==================== =============================== ================ 122 userid 0.9.2342.19200300.100.1.1 CaseIgnoreString 123 uid 0.9.2342.19200300.100.1.1 CaseIgnoreString 124 textEncodedORaddress 0.9.2342.19200300.100.1.2 CaseIgnoreString 125 rfc822Mailbox 0.9.2342.19200300.100.1.3 CaseIgnoreIA5String 126 mail 0.9.2342.19200300.100.1.3 CaseIgnoreIA5String 127 info 0.9.2342.19200300.100.1.4 CaseIgnoreString 128 favouriteDrink 0.9.2342.19200300.100.1.5 CaseIgnoreString 129 drink 0.9.2342.19200300.100.1.5 CaseIgnoreString 130 roomNumber 0.9.2342.19200300.100.1.6 CaseIgnoreString 131 photo 0.9.2342.19200300.100.1.7 Fax 132 userClass 0.9.2342.19200300.100.1.8 CaseIgnoreString 133 host 0.9.2342.19200300.100.1.9 CaseIgnoreString 134 manager 0.9.2342.19200300.100.1.10 DN 135 documentIdentifier 0.9.2342.19200300.100.1.11 CaseIgnoreString 136 documentTitle 0.9.2342.19200300.100.1.12 CaseIgnoreString 137 documentVersion 0.9.2342.19200300.100.1.13 CaseIgnoreString 138 documentAuthor 0.9.2342.19200300.100.1.14 DN 139 documentLocation 0.9.2342.19200300.100.1.15 CaseIgnoreString 140 homePhone 0.9.2342.19200300.100.1.20 TelephoneNumber 141 secretary 0.9.2342.19200300.100.1.21 DN 142 otherMailbox 0.9.2342.19200300.100.1.22 OtherMailbox 143 lastModifiedTime 0.9.2342.19200300.100.1.23 UTCTime 144 lastModifiedBy 0.9.2342.19200300.100.1.24 DN 145 domainComponent 0.9.2342.19200300.100.1.25 CaseIgnoreIA5String 146 dc 0.9.2342.19200300.100.1.25 CaseIgnoreIA5String 147 dNSRecord 0.9.2342.19200300.100.1.26 IA5String 148 mXRecord 0.9.2342.19200300.100.1.28 IA5String 149 nSRecord 0.9.2342.19200300.100.1.29 IA5String 150 sOARecord 0.9.2342.19200300.100.1.30 IA5String 151 cNAMERecord 0.9.2342.19200300.100.1.31 IA5String 152 associatedDomain 0.9.2342.19200300.100.1.37 CaseIgnoreIA5String 153 associatedName 0.9.2342.19200300.100.1.38 DN 154 homePostalAddress 0.9.2342.19200300.100.1.39 PostalAddress 155 personalTitle 0.9.2342.19200300.100.1.40 CaseIgnoreString 156 mobileTelephoneNumber 0.9.2342.19200300.100.1.41 TelephoneNumber 157 mobile 0.9.2342.19200300.100.1.41 TelephoneNumber 158 pagerTelephoneNumber 0.9.2342.19200300.100.1.42 TelephoneNumber 159 pager 0.9.2342.19200300.100.1.42 TelephoneNumber 160 friendlyCountryName 0.9.2342.19200300.100.1.43 CaseIgnoreString 161 co 0.9.2342.19200300.100.1.43 CaseIgnoreString 162 ccitt.9.2342.19200300.100.1.44 0.9.2342.19200300.100.1.44 CaseIgnoreString 163 organizationalStatus 0.9.2342.19200300.100.1.45 CaseIgnoreString 164 janetMailbox 0.9.2342.19200300.100.1.46 CaseIgnoreIA5String 165 mailPreferenceOption 0.9.2342.19200300.100.1.47 MailPreference 166 buildingName 0.9.2342.19200300.100.1.48 CaseIgnoreString 167 dSAQuality 0.9.2342.19200300.100.1.49 DSAQualitySyntax 168 singleLevelQuality 0.9.2342.19200300.100.1.50 DataQualitySyntax 169 subtreeMinimumQuality 0.9.2342.19200300.100.1.51 DataQualitySyntax 170 subtreeMaximumQuality 0.9.2342.19200300.100.1.52 DataQualitySyntax 171 personalSignature 0.9.2342.19200300.100.1.53 Fax 172 dITRedirect 0.9.2342.19200300.100.1.54 DN 173 audio 0.9.2342.19200300.100.1.55 Audio 174 documentPublisher 0.9.2342.19200300.100.1.56 CaseIgnoreString 175 jpegPhoto 0.9.2342.19200300.100.1.60 JPEG 177 3.3. Collective Attributes 179 These attributes are stored in collective attribute subentries, but may 180 be visible in user entries if requested. 182 Attribute Type Name OID Syntax 183 ==================== =============== ================ 184 collectiveLocalityName 2.5.4.7.1 DirectoryString 185 collectiveStateOrProvinceName 2.5.4.8.1 DirectoryString 186 collectiveStreetAddress 2.5.4.9.1 DirectoryString 187 collectiveOrganizationName 2.5.4.10.1 DirectoryString 188 collectiveOrganizationalUnitName 2.5.4.11.1 DirectoryString 189 collectivePostalAddress 2.5.4.16.1 PostalAddress 190 collectivePostalCode 2.5.4.17.1 DirectoryString 191 collectivePostOfficeBox 2.5.4.18.1 DirectoryString 192 collectivePhysicalDeliveryOfficeName 2.5.4.19.1 DirectoryString 193 collectiveTelephoneNumber 2.5.4.20.1 TelephoneNumber 194 collectiveTelexNumber 2.5.4.21.1 TelexNumber 195 collectiveTeletexTerminalIdentifier 2.5.4.22.1 TeletexTerminalIdentifier 196 collectiveFacsimileTelephoneNumber 2.5.4.23.1 FacsimileTelephoneNumber 197 collectiveInternationaliSDNNumber 2.5.4.25.1 NumericString 199 3.4. Standard Operational Attributes 201 These attributes are defined in X.501(1993) Annexes B through E. 203 Attribute Type Name OID Syntax 204 ==================== =============== ================ 205 createTimestamp 2.5.18.1 GeneralizedTime 206 modifyTimestamp 2.5.18.2 GeneralizedTime 207 creatorsName 2.5.18.3 DN 208 modifiersName 2.5.18.4 DN 209 administrativeRole 2.5.18.5 OID 210 subtreeSpecification 2.5.18.6 SubtreeSpecification 211 collectiveExclusions 2.5.18.7 OID 212 dITStructureRules 2.5.21.1 DITStructureRuleDescription 213 dITContentRules 2.5.21.2 DITContentRuleDescription 214 matchingRules 2.5.21.4 MatchingRuleDescription 215 attributeTypes 2.5.21.5 AttributeTypeDescription 216 objectClasses 2.5.21.6 ObjectClassDescription 217 nameForms 2.5.21.7 NameFormDescription 218 matchingRuleUse 2.5.21.8 MatchingRuleUseDescription 219 structuralObjectClass 2.5.21.9 OID 220 governingStructureRule 2.5.21.10 INTEGER 221 accessControlScheme 2.5.24.1 OID 222 prescriptiveACI 2.5.24.4 ACIItem 223 entryACI 2.5.24.5 ACIItem 224 subentryACI 2.5.24.6 ACIItem 225 dseType 2.5.12.0 DSEType 226 myAccessPoint 2.5.12.1 AccessPoint93 227 superiorKnowledge 2.5.12.2 AccessPoint93 228 specificKnowledge 2.5.12.3 MasterAndShadowAccessPoints 229 nonSpecificKnowledge 2.5.12.4 MasterAndShadowAccessPoints 230 supplierKnowledge 2.5.12.5 SupplierInformation 231 consumerKnowledge 2.5.12.6 SupplierOrConsumer 232 secondaryShadows 2.5.12.7 SupplierAndConsumers 234 4. Attribute Syntax Encoding Requirements 236 This section defines general requirements for LDAP attribute value 237 syntax encodings. All documents defining attribute syntax encodings for 238 use with LDAP are expected to conform to these requirements. 240 The encoding rules defined for a given attribute syntax must produce 241 octet strings. To the greatest extent possible, encoded octet 242 strings should be usable in their native encoded form for display 243 purposes. In particular, encoding rules for attribute syntaxes 244 defining non-binary values should produce strings that can be 245 displayed with little or no translation by clients implementing 246 LDAP. However, if it is necessary to obtain the a reversible encoding 247 in order to make of an attribute (e.g. userCertificate) then this 248 requirement takes precedence over the requirement for the attribute 249 to be human-readable. 251 4.1. Common BNF 253 For the purposes of defining the encoding rules for attribute syntaxes, 254 the following auxiliary BNF definitions will be used: 256 ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 257 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 258 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 259 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 260 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 261 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' 263 ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 265 ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 266 'A' | 'B' | 'C' | 'D' | 'E' | 'F' 268 ::= | | '-' 270

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 271 '/' | ':' | '?' | ' ' 273 ::= The ASCII newline character with hexadecimal value 0x0A 274 ::= | 276 ::= | 278 ::= | 280 ::= | 282 ::=

|

284 ::= ' ' | ' ' 286 4.2. Undefined and Binary 288 Values of types not described in this document or not supported by 289 servers are be default encoded as if they were values of type Octet 290 String, with the string value being the BER-encoded transfer 291 representation of the value. This encoding format is also used if the 292 binary encoding is requested by the client for an attribute. 294 All servers must be capable of supporting this form for both generating 295 Search results and parsing Add and Modify requests. 297 4.3. Readable 299 If the client has requested that all attributes be transferred in a 300 readable form, then undefined values are pretty-printed in ASN.1 value 301 notation to make an IA5 string. If there are any character string 302 values which contain non-printing characters, these strings are pretty- 303 printed in the hexidecimal representation as used for octet strings. 305 Client applications should only use the readable form when retrieving 306 attributes from searches. Servers may not be able to handle this form 307 as input to Add and Modify operations. 309 5. Standard User Attribute Syntax Encodings 311 5.1. BitString 313 The encoding of a value with BitString syntax is according to the 314 following BNF: 316 ::= ''' ''B' 318 ::= '0' | '1' | 319 empty 321 5.2. PrintableString 323 The encoding of a value with PrintableString syntax is the string 324 value itself. 326 5.3. DirectoryString 328 A string with DirectoryString syntax is encoded depending on the ASN.1 329 form chosen in that string, and the setting of the preferredSyntax 330 Server Control made by the client earlier in this session. 332 If it is of the PrintableString form, the value is encoded as the 333 string value itself. 335 If it is of the TeletexString form, then characters which correspond 336 to the IA5 subset of TeletexString are mapped directly, those which 337 correspond to ISO-8859-1 are transliterated, and those for which there 338 is no direct mapping are replaced by a IA5 description of the glyph. 339 For example, should a TeletexString consist of the symbol for one-half, 340 this could be converted to the string 342 [1/2] 344 Client applications should avoid generating TeletexString characters 345 other than those of IA5. 347 If it is of the UniversalString or BMPString form, then implementations 348 may if they support these forms attempt to convert them to IA5. 349 Otherwise the encoding should be an empty string. 351 Subsequent documents may provide additional mechanisms for controlling 352 how a DirectoryString is transferred, based on alternative encoding 353 preferences. 355 5.4. Certificate 357 Because of the changes from X.509(1988) and X.509(1993) and additional 358 planned changes to the syntax to support certificate extensions, no 359 string representation is defined, and values with Certificate syntax 360 (userCertificate and caCertificate) are only transferred using the 361 Binary encoding. The BNF notation in RFC 1778 for "User Certificate" 362 is not permitted. 364 5.5. CertificateList 366 Because of the incompatibility of the X.509(1988) and X.509(1993) 367 definitions of revocation lists, values with CertificateList syntax 368 (certificateRevocationList and authorityRevocationList) are only 369 transferred using the Binary encoding. The BNF notation in RFC 1778 370 for "Authority Revocation List" is not permitted. 372 5.6. CertificatePair 374 Because the Certificate is being carried in binary, values with 375 CertificatePair syntax (crossCertificatePair) are only transferred 376 using the Binary encoding. The BNF notation in RFC 1778 for 377 "Certificate Pair" is not permitted. 379 5.7. CountryString 381 A value of CountryString syntax is encoded the same as a value of 382 DirectoryString syntax. 384 5.8. DN 386 Values with DN (Distinguished Name) syntax are encoded to have the 387 representation defined in [5]. Note that this representation is not 388 reversible to the original ASN.1 encoding as the CHOICE of any 389 DirectoryString element in an RDN is no longer known. 391 5.9. DeliveryMethod 393 Values with DeliveryMethod syntax are encoded according to the 394 following BNF: 396 ::= | '$' 398 ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' | 399 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone' 401 5.10. EnhancedGuide 403 Values with the EnhancedGuide syntax are encoded according to the 404 following BNF: 406 ::= '#' '#' 408 ::= "baseobject" | "oneLevel" | "wholeSubtree" 410 The production is defined in the Guide syntax below. 412 5.11. FacsimileTelephoneNumber 414 Values with the FacsimileTelephoneNumber syntax are encoded according 415 to the following BNF: 417 ::= [ '$' ] 419 ::= | '$' 421 ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | 422 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' 424 In the above, the first is the actual fax number, 425 and the tokens represent fax parameters. 427 5.12. Guide 429 Values with the Guide syntax are encoded according to the following 430 BNF: 432 ::= [ '#' ] 434 ::= an encoded value with OID syntax 436 ::= | | '!' 437 ::= [ '(' ] '&' [ ')' ] | 438 [ '(' ] '|' [ ')' ] 440 ::= [ '(' ] '$' [ ')' ] 442 ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" 444 5.13. NameAndOptionalUID 446 The encoding of a value with the NameAndOptionalUID syntax is according 447 to the following BNF: 449 ::= '(' ')' | 450 ['('] '#' [')'] 452 5.14. NumericString 454 The encoding of a string with the NumericString syntax is the string 455 value itself. 457 5.15. OID 459 Values with OID (Object Identifier) syntax are encoded according to the 460 following BNF: 462 ::= | '.' | 464 ::= 466 ::= | '.' 468 In the above BNF, is the syntactic representation of an 469 object descriptor, which must consist of letters and digits, starting 470 with a letter. When encoding values with OID syntax, the first encoding 471 option should be used in preference to the second, which should be used 472 in preference to the third wherever possible. That is, in encoding 473 object identifiers, object descriptors (where assigned and known by 474 the implementation) should be used in preference to numeric oids to 475 the greatest extent possible. For example, in encoding the object 476 identifier representing an organizationName, the descriptor 477 "organizationName" is preferable to "ds.4.10", which is in turn 478 preferable to the string "2.5.4.10". A list of descriptors is given 479 in Appendix A. 481 5.16. Password 483 Values with Password syntax are encoded as if they were of type 484 octetStringSyntax. 486 5.17. PostalAddress 488 Values with the PostalAddress syntax are encoded according to the 489 following BNF: 491 ::= | '$' 493 In the above, each component of a postal address value is 494 encoded as a value of type t61StringSyntax. 496 5.18. PresentationAddress 498 Values with the PresentationAddress syntax are encoded to have the 499 representation described in [6]. 501 5.19. ProtocolInformation 503 A value with the ProtocolInformation syntax is encoded according to the 504 following BNF: 506 ::= '#' 507 509 ::= As appears in PresentationAddress 511 ::= | 512 '(' ')' 514 ::= | 515 '$' 517 ::= 519 For example, 521 NS+12345678 # 1.2.3.4.5 523 5.20. TelephoneNumber 525 Values with the TelephoneNumber syntax are encoded as if they were 526 Printable String types. 528 5.21. TeletexTerminalIdentifier 530 Values with the TeletexTerminalIdentifier syntax are encoded according 531 to the following BNF: 533 ::= 0*('$' ) 535 ::= ':' 537 ::= 'graphic' | 'control' | 'misc' | 'page' | 'private' 539 ::= 541 In the above, the first is the encoding of the 542 first portion of the teletex terminal identifier to be encoded, and 543 the subsequent 0 or more are subsequent portions 544 of the teletex terminal identifier. 546 5.22. TelexNumber 548 Values with the TelexNumber syntax are encoded according to the 549 following BNF: 551 ::= '$' '$' 553 ::= 555 ::= 557 ::= 559 In the above, is the syntactic representation of the 560 number portion of the TELEX number being encoded, is the 561 TELEX country code, and is the answerback code of a 562 TELEX terminal. 564 6. Pilot Attribute Syntax Encodings 566 6.1. Audio 568 The encoding of a value with Audio syntax is the octets of the value 569 itself, a 8KHz encoding compatible with the sun 'play' utility. 571 6.2. CaseIgnoreIA5String 573 The encoding of a value with CaseIgnoreIA5String syntax is the string 574 value itself. 576 6.3. CaseIgnoreString 578 The encoding of a value with CaseIgnoreString syntax is the same as the 579 encoding of a value with DirectoryString syntax. Note that for 580 compatibility with X.500(1988) only the PrintableString and 581 TeletexString forms of DirectoryString should be used. 583 6.4. DSAQualitySyntax 585 Values with this syntax are encoded according to the following BNF: 587 ::= [ '#' ] 589 ::= 'DEFUNCT' | 'EXPERIMENTAL' | 'BEST-EFFORT' | 590 'PILOT-SERVICE' | 'FULL-SERVICE' 592 ::= encoded as a PrintableString 594 6.5. DataQualitySyntax 596 Values with this syntax are encoded according to the following BNF: 598 ::= '#' '#' 599 [ '#' ] 600 ::= '+' 602 ::= '$' 604 ::= '+' 606 ::= 'NONE' | 'SAMPLE' | 'SELECTED' | 607 'SUBSTANTIAL' | 'FULL' 609 ::= 'UNKNOWN' | 'EXTERNAL' | 'SYSTEM-MAINTAINED' | 610 'USER-SUPPLIED' 612 6.6. IA5String 614 The encoding of a value with IA5String syntax is the string value 615 itself. 617 6.7. JPEG 619 Values with JPEG syntax are encoded as if they were octet strings 620 containing JPEG images in the JPEG File Interchange Format (JFIF), as 621 described in [8]. 623 6.8. MailPreference 625 Values with MailPreference syntax are encoded according to the 626 following BNF: 628 ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS" 630 6.9. OtherMailbox 632 Values of the OtherMailbox syntax are encoded according to the 633 following BNF: 635 ::= '$' 637 ::= an encoded Printable String 639 ::= an encoded IA5 String 641 In the above, represents the type of mail system in 642 which the mailbox resides, for example "MCIMail"; and is the 643 actual mailbox in the mail system defined by . 645 6.10. Fax 647 Values with Fax syntax are encoded as if they were octet strings 648 containing Group 3 Fax images as defined in [7]. 650 6.11. UTCTime 652 Values with UTCTime syntax are encoded as if they were printable 653 strings with the strings containing a UTCTime value. 655 6.12. OctetString 657 The encoding of a value with OctetString syntax is the string 658 value itself. 660 6.13. T61String 662 The encoding of a value with T61String syntax is the string value 663 itself. 665 6.14. CaseIgnoreList 667 Values with CaseIgnoreList syntax are encoded according to the 668 following BNF: 670 ::= | 671 '$' 673 ::= a string encoded according to the rules for 674 DirectoryString as above. 676 6.15. CaseExactList 678 Values with CaseExactList syntax are encoded according to the 679 following BNF: 681 ::= | 682 '$' 684 ::= a string encoded according to the rules for 685 DirectoryString as above. 687 6.16. Boolean 689 Values with Boolean syntax are encoded according to the following 690 BNF: 692 ::= "TRUE" | "FALSE" 694 Boolean values have an encoding of "TRUE" if they are logically true, 695 and have an encoding of "FALSE" otherwise. 697 7. Standard Operational Attribute Syntax Encodings 699 7.1. ACIItem 701 This syntax appears too complicated for a compact string representation 702 be useful. Thus syntax will use the the binary encoding, which 703 contains a BER encoding of the value. It is recommended that clients 704 that wish to only determine whether they have been granted permission 705 to modify an entry use the modifyRightsReq field in the SearchRequest, 706 rather than attempt to parse this syntax. 708 7.2. AccessPoint93 710 Values with AccessPoint93 syntax are encoded according to the 711 following BNF: 713 ::= ( '(' '#' 714 ')' ) | 715 -- Optional protocol info absent, parenthesis required 717 ( '(' '#' 718 '#' 719 ::= | 722 '(' ')' 724 ::= | 725 '$' 726 728 7.3. AttributeTypeDescription 730 No printable representation is defined, this syntax uses the binary 731 encoding which contains a BER encoding of the value. 733 7.4. DITContentRuleDescription 735 No printable representation is defined, this syntax uses the binary 736 encoding which contains a BER encoding of the value. 738 7.5. DITStructureRuleDescription 740 No printable representation is defined, this syntax uses the binary 741 encoding which contains a BER encoding of the value. 743 7.6. DSEType 745 Values with DSEType syntax are encoded according to the following BNF: 747 ::= '(' ')' 749 ::= | '$' 751 ::= 'root' | 'glue' | 'cp' | 'entry' | 'alias' | 'subr' | 752 'nssr' | 'supr' | 'xr' | 'admPoint' | 'subentry' | 753 'shadow' | 'zombie' | 'immSupr' | 'rhob' | 'sa' | 754 'dsSubentry' 756 7.7. GeneralizedTime 758 Values of this syntax are encoded as printable strings, represented 759 as specified in X.208. Note that the time zone must be specified. 760 For example, 762 199412161032Z 763 7.8. INTEGER 765 Values with INTEGER syntax are encoded as the decimal representation 766 of their values, with each decimal digit represented by the its 767 character equivalent. So the digit 1 is represented by the character 768 "1". 770 7.9. MasterAndShadowAccessPoints 772 Values of this syntax are encoded according to the following BNF: 774 ::= | 775 '(' ::= | 778 '$' 780 ::= '#' 782 ::= 'master' | 'shadow' 784 7.10. MatchingRuleDescription 786 No printable representation is defined, this syntax uses the binary 787 encoding which contains a BER encoding of the value. 789 7.11. MatchingRuleUseDescription 791 No printable representation is defined, this syntax uses the binary 792 encoding which contains a BER encoding of the value. 794 7.12. NameFormDescription 796 No printable representation is defined, this syntax uses the binary 797 encoding which contains a BER encoding of the value. 799 7.13. ObjectClassDescription 801 No printable representation is defined, this syntax uses the binary 802 encoding which contains a BER encoding of the value. 804 7.14. SubtreeSpecification 806 Values of this syntax are encoded according to the following BNF: 808 ::= '(' [] '#' 809 [] '#' 810 [] '#' [] '#' 811 [] ')' 813 ::= 815 ::= '(' ')' 817 ::= | '$' 818 ::= ( 'before ' ) | 819 ( 'after ' ) 821 ::= 823 ::= 825 ::= | '!' | 826 '( &' ')' | 827 '( |' ')' 829 ::= | '$' 831 7.15. SupplierInformation 833 Values of this syntax are encoded according to the following BNF: 835 ::= 836 -- supplier is master -- 837 '(' 'master' '#' ')' | 839 -- supplier is not master, master unspecified -- 840 '(' 'shadow' '#' ')' | 842 -- supplier not master, master specified -- 843 ['('] 'shadow' '#' '#' [')'] 845 7.16. SupplierOrConsumer 847 Values of this syntax are encoded according to the following BNF: 849 ::= '#' 851 ::= '.' 853 ::= 855 ::= 857 7.17. SupplierAndConsumers 859 Values of this syntax are encoded according to the following BNF: 861 ::= '#' 863 ::= 865 ::= | '(' ')' 867 ::= | 868 '$' 870 8. Security Considerations 872 Security issues are not discussed in this memo. 874 9. Acknowledgements 876 This document is based heavily on RFC 1778, written by Tim Howes, 877 Steve Kille, Wengyik Yeong and Colin Robbins. 879 Many of the attribute syntax encodings defined in this document are 880 adapted from those used in the QUIPU and the IC R3 X.500 881 implementations. The contributions of the authors of both these 882 implementations in the specification of syntaxes in this document are 883 gratefully acknowledged. 885 10. Authors Addresses 887 Mark Wahl 888 ISODE Consortium Inc. 889 3925 West Braker Lane, Suite 333 890 Austin, TX 78759 891 USA 893 Phone: +1 512-305-0280 894 EMail: M.Wahl@isode.com 896 Andy Coulbeck 897 ISODE Consortium Ltd. 898 The Dome, The Square 899 Richmond TW9 1DT 900 United Kingdom 902 Phone: +44 181-332-9091 903 EMail: A.Coulbeck@isode.com 905 Tim Howes 906 University of Michigan 907 ITD Research Systems 908 535 W William St. 909 Ann Arbor, MI 48103-4943 910 USA 912 Phone: +1 313 747-4454 913 EMail: tim@umich.edu 915 Steve Kille 916 ISODE Consortium 917 The Dome, The Square 918 Richmond 919 TW9 1DT 920 UK 922 Phone: +44-181-332-9091 923 EMail: S.Kille@isode.com 924 11. Bibliography 926 [1] M.Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 927 Protocol (Version 3)". 929 [2] The Directory: Selected Attribute Types. ITU-T Recommendation 930 X.520, 1993. 932 [3] The Directory: Models. ITU-T Recommendation X.501, 1993. 934 [4] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC 935 1274, November 1991. 937 [5] Kille, S., "A String Representation of Distinguished Names", RFC 938 1779, ISODE Consortium, March 1995. 940 [6] Kille, S., "A String Representation for Presentation Addresses", 941 RFC 1278, University College London, November 1991. 943 [7] Terminal Equipment and Protocols for Telematic Services - 944 Standardization of Group 3 facsimile apparatus for document 945 transmission. CCITT, Recommendation T.4. 947 [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C- 948 Cube Microsystems, Milpitas, CA, September 1, 1992. 950 Appendix A- Permitted OID descriptors 952 Attribute type names listed above may be used as descriptions for OIDs, 953 as well as the following. 955 A.1. Object classes 957 Descriptor Value 958 ============================== =========================== 959 top 2.5.6.0 960 alias 2.5.6.1 961 country 2.5.6.2 962 locality 2.5.6.3 963 organization 2.5.6.4 964 organizationalUnit 2.5.6.5 965 person 2.5.6.6 966 organizationalPerson 2.5.6.7 967 organizationalRole 2.5.6.8 968 groupOfNames 2.5.6.9 969 residentialPerson 2.5.6.10 970 applicationProcess 2.5.6.11 971 applicationEntity 2.5.6.12 972 dSA 2.5.6.13 973 device 2.5.6.14 974 strongAuthenticationUser 2.5.6.15 975 certificationAuthority 2.5.6.16 976 groupOfUniqueNames 2.5.6.17 977 pilotObject 0.9.2342.19200300.100.4.3 978 newPilotPerson 0.9.2342.19200300.100.4.4 979 account 0.9.2342.19200300.100.4.5 980 document 0.9.2342.19200300.100.4.6 981 room 0.9.2342.19200300.100.4.7 982 documentSeries 0.9.2342.19200300.100.4.9 983 domain 0.9.2342.19200300.100.4.13 984 rFC822localPart 0.9.2342.19200300.100.4.14 985 dNSDomain 0.9.2342.19200300.100.4.15 986 domainRelatedObject 0.9.2342.19200300.100.4.17 987 friendlyCountry 0.9.2342.19200300.100.4.18 988 simpleSecurityObject 0.9.2342.19200300.100.4.19 989 pilotOrganization 0.9.2342.19200300.100.4.20 990 pilotDSA 0.9.2342.19200300.100.4.21 991 qualityLabelledData 0.9.2342.19200300.100.4.23 993 A.2. Other descriptors 995 In addition, servers should recognize at the minimum the following 996 descriptors as prefixes of other OIDs, e.g. "enterprises.453.13.3". 997 Clients should attempt to ensure that any OIDs they transmit are in 998 terms of only these descriptors, with additional components in numeric 999 form. 1001 Descriptor Value 1002 ============================== =========================== 1004 ccitt 0 1005 iso 1 1006 joint 2 1007 memberBody 1.2 1008 ansi 1.2.840 1009 identifiedOrganization 1.3 1010 dod 1.3.6 1011 internet 1.3.6.1 1012 private 1.3.6.1.4 1013 enterprises 1.3.6.1.4.1 1014 ds 2.5 1015 standardObjectClass 2.5.6