idnits 2.17.1 draft-ietf-asid-ldapv3-attributes-04.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-18) 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 17 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 102 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 22 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '... Servers SHOULD implement all the at...' RFC 2119 keyword, line 94: '... they MUST be able to perform equali...' RFC 2119 keyword, line 97: '... Servers MAY recognize additional na...' RFC 2119 keyword, line 98: '...d if they do so, SHOULD publish the de...' RFC 2119 keyword, line 117: '...tion, and clients MUST NOT assume that...' (23 more instances...) == 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 28 has weird spacing: '...listing conta...' -- 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 (24 March 1997) is 9887 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 839 looks like a reference -- Missing reference section? '4' on line 848 looks like a reference -- Missing reference section? '9' on line 865 looks like a reference -- Missing reference section? '10' on line 868 looks like a reference -- Missing reference section? '3' on line 846 looks like a reference -- Missing reference section? '12' on line 875 looks like a reference -- Missing reference section? '13' on line 879 looks like a reference -- Missing reference section? '5' on line 851 looks like a reference -- Missing reference section? '7' on line 858 looks like a reference -- Missing reference section? '8' on line 862 looks like a reference -- Missing reference section? '11' on line 871 looks like a reference -- Missing reference section? '6' on line 855 looks like a reference -- Missing reference section? '2' on line 843 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Critical Angle Inc. 3 Obsoletes: RFC 1778 A. Coulbeck 4 Isode Limited 5 T. Howes 6 Netscape Communications Corp. 7 S. Kille 8 Isode Limited 9 Intended Category: Standards Track 24 March 1997 11 Lightweight Directory Access Protocol (v3): 12 Attribute Syntax Definitions 13 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 2. Abstract 34 The Lightweight Directory Access Protocol (LDAP) [1] requires that the 35 contents of AttributeValue fields in protocol elements be octet 36 strings. This document defines a set of syntaxes for LDAPv3, and the 37 rules by which attribute values of these syntaxes are represented as 38 octet strings for transmission in the LDAP protocol. The syntaxes 39 defined in this document are referenced by this and other documents that 40 define attribute types. This document also defines the set of attribute 41 types which LDAP servers should support. 43 3. Overview 45 Section 4 states the general requirements and notations for attribute 46 types, object classes, syntax and matching rule definitions. 48 Section 5 lists attributes, section 6 syntaxes and section 7 object 49 classes. 51 4. General Issues 53 This document describes encodings used in an Internet protocol. Terms are 54 defined in [4]. 56 4.1. Attribute Types 58 The attribute types are described by sample values for the subschema 59 "attributeTypes" attribute, which is written in the 60 AttributeTypeDescription syntax. While lines have been folded for 61 readability, the values transferred in protocol would not contain 62 newlines. 64 The AttributeTypeDescription is encoded according to the following BNF, 65 and the productions for , and 66 are given in sections 4.2.1. 68 ::= "(" 69 -- AttributeType identifier 70 [ "NAME" ] -- name used in AttributeType 71 [ "DESC" ] 72 [ "OBSOLETE" ] 73 [ "SUP" ] -- derived from this other AttributeType 74 [ "EQUALITY" ] -- Matching Rule name 75 [ "ORDERING" ] -- Matching Rule name 76 [ "SUBSTR" ] -- Matching Rule name 77 [ "SYNTAX" ] -- see section 4.2 78 [ "SINGLE-VALUE" ] -- default multi-valued 79 [ "COLLECTIVE" ] -- default not collective 80 [ "NO-USER-MODIFICATION" ] -- default user modifiable 81 [ "USAGE" ] -- default user applications 82 ")" 84 ::= 85 "userApplications" 86 | "directoryOperation" 87 | "distributedOperation" -- DSA-shared 88 | "dSAOperation" -- DSA-specific, value depends on server 90 Servers are not required to provide the same or any text 91 in the description part of the subschema values they maintain. 93 Servers SHOULD implement all the attribute types referenced in section 5: 94 they MUST be able to perform equality matching of values, but need not 95 perform any additional validity checks on attribute values. 97 Servers MAY recognize additional names and attributes not listed in this 98 document, and if they do so, SHOULD publish the definitions of the types 99 in the attributeTypes attribute of their subschema subentries. 101 AttributeDescriptions can be used as the value in a NAME part of an 102 AttributeTypeDescription. Note that these are case insensitive. 104 4.2. Syntaxes 106 This section defines general requirements for LDAP attribute value 107 syntax encodings. All documents defining attribute syntax encodings for 108 use with LDAP are expected to conform to these requirements. 110 The encoding rules defined for a given attribute syntax must produce 111 octet strings. To the greatest extent possible, encoded octet 112 strings should be usable in their native encoded form for display 113 purposes. In particular, encoding rules for attribute syntaxes 114 defining non-binary values should produce strings that can be 115 displayed with little or no translation by clients implementing 116 LDAP. There are a few cases (e.g. Audio) however, when it is not sensible 117 to produce a printable representation, and clients MUST NOT assume that 118 an unrecognized syntax is a string representation. 120 4.2.1. Common Encoding Aspects 122 In these encodings where an arbitrary string is used as part of a larger 123 production (other than a Distinguished Name), a backslash quoting mechanism 124 is used to encode the following separator symbol character (such as ''', 125 '$' or '#') if it should occur in that string. The backslash is followed 126 by a pair of hexadecimal digits representing the next character. A 127 backslash itself in the string which forms part of a larger syntax is 128 always transmitted as '\5C' or '\5c'. 130 For the purposes of defining the encoding rules for attribute syntaxes, 131 the following auxiliary BNF definitions will be used: 133 ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 134 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 135 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 136 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 137 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 138 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' 140 ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 142 ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 143 'A' | 'B' | 'C' | 'D' | 'E' | 'F' 145 ::= | | '-' 147

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 148 '/' | ':' | '?' | ' ' 150 ::= | 152 ::= | 154 ::= | 156 ::= | 158 ::=

|

160 ::= ' ' | ' ' 162 ::= | empty 163 ::= any sequence of octets formed from the UTF-8 [9] 164 transformation of a character from ISO 10646 [10] 166 ::= | 168 ::= | '(' ')' 170 ::= | "" 172 ::= ''' ''' 174 ::= | '(' ')' 176 ::= '$' | 178 4.2.2 Binary Transfer of Values 180 This encoding format is used if the binary encoding is requested by the 181 client for an attribute, or if the attribute syntax name is 'Binary'. The 182 value, an instance of the ASN.1 AttributeValue type, is BER-encoded, 183 subject to the restrictions of section 5.1 of [1], and this sequence of 184 octets is used as the value. 186 All servers MUST implement this form for both generating attribute values in 187 search responses, and parsing attribute values in add, compare and modify 188 requests, if the attribute type is recognized and the attribute syntax name 189 is 'Binary'. Clients MUST be prepared receiving values in binary (e.g. 190 userCertificate or audio), and MUST NOT simply display binary or 191 unrecognized values to users. 193 4.2.3. Syntax Names 195 Names of syntaxes for use with LDAP are ASCII strings which either 196 begin with a letter and contain only letters or digits. The names are 197 case insensitive. Historically since syntaxes correspond to ASN.1 types, 198 they have been named starting with a capital letter. A suggested minimum 199 upper bound on the number of characters in value with a DirectoryString or 200 IA5String syntax or the number of bytes in a value for all other syntaxes 201 may be indicated by appending this bound count inside of curly braces. 202 For instance, "DirectoryString{64}" suggests that server implementations 203 should allow the string to be 64 characters long, althoough they may allow 204 longer strings. Note that a single character of the DirectoryString may be 205 encoded in more than one byte since UTF-8 is a variable-length encoding. 207 Syntax names do not have global scope: two clients or servers may 208 know of different syntaxes with the same name. 210 The definition of additional arbitrary syntaxes is strongly depreciated 211 since it will hinder interoperability: today's client and server 212 implementations generally do not have the ability to dynamically recognize 213 new syntaxes. In most cases attributes will be defined with the 214 DirectoryString syntax. 216 4.3. Object Classes 218 Object class descriptions are written according to the following BNF: 220 ::= "(" 221 -- ObjectClass identifier 222 [ "NAME" ] 223 [ "DESC" ] 224 [ "OBSOLETE" ] 225 [ "SUP" ] -- Superior ObjectClasses 226 [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural 227 [ "MUST" ] -- AttributeTypes 228 [ "MAY" ] -- AttributeTypes 229 ")" 231 These are described as sample values for the subschema "objectClasses" 232 attribute for a server which implements the LDAP schema. 233 While lines have been folded for readability, the values transferred in 234 protocol would not contain newlines. 236 Servers SHOULD implement all the object classes referenced in section 7, 237 except for extensibleObject, which is optional. 239 Servers MAY implement additional object classes not listed in this 240 document, and if they do so, SHOULD publish the definitions of the classes 241 in the objectClasses attribute of their subschema subentries. Later 242 documents may define additional object classes. 244 4.4. Matching Rules 246 Matching rules are used by servers to compare attribute values against 247 assertion values when performing Search and Compare operations. 249 Most of the attributes given in this document will have an equality 250 matching rule defined. 252 Matching rule descriptions are written according to the following BNF: 254 ::= "(" 255 -- MatchingRule identifier 256 [ "NAME" ] 257 [ "DESC" ] 258 [ "OBSOLETE" ] 259 "SYNTAX" 260 ")" 262 Servers SHOULD implement all the matching rules in section 8. 264 Servers MAY implement additional matching rules not listed in this 265 document, and if they do so, SHOULD publish the definitions of the 266 matching rules in the matchingRules attribute of their 267 subschema subentries. 269 5. Attribute Types 271 All LDAP server implementations MUST recognize the attribute types 272 defined in this section. These types are based on definitions in 273 X.501(93) [3]. 275 Servers SHOULD also recognize all the attributes from section 5 of [12], 276 from section 5 of [13]. 278 5.1. Standard Operational Attributes 280 5.1.1. createTimestamp 282 ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch 283 ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' 284 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 286 5.1.2. modifyTimestamp 288 ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch 289 ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' 290 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 292 5.1.3. creatorsName 294 ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 'DN' 295 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 297 5.1.4. modifiersName 299 ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 'DN' 300 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 302 5.1.5. subschemaSubentry 304 The value of this attribute is the name of a subschema subentry, an 305 entry in which the server makes available attributes specifying 306 the schema. 308 ( 2.5.18.10 NAME 'subschemaSubentry' 309 EQUALITY distinguishedNameMatch SYNTAX 'DN' NO-USER-MODIFICATION 310 SINGLE-VALUE USAGE directoryOperation ) 312 5.1.6. attributeTypes 314 ( 2.5.21.5 NAME 'attributeTypes' 315 EQUALITY objectIdentifierFirstComponentMatch 316 SYNTAX 'AttributeTypeDescription' USAGE directoryOperation ) 318 5.1.7. objectClasses 320 ( 2.5.21.6 NAME 'objectClasses' 321 EQUALITY objectIdentifierFirstComponentMatch 322 SYNTAX 'ObjectClassDescription' USAGE directoryOperation ) 324 5.2. LDAP Operational Attributes 326 These attributes are only present in the root DSE. 328 Servers MUST recognize these attribute names, but it is not required that 329 a server provide values for these attributes, when the attribute 330 corresponds to a feature which the server does not implement. 332 5.2.1. namingContexts 334 The values of this attribute correspond to naming contexts which this 335 server masters or shadows. If the server does not master any 336 information (e.g. it is an LDAP gateway to a public X.500 directory) 337 this attribute will be absent. If the server believes it contains the 338 entire directory, the attribute will have a single value, and that 339 value will be the empty string (indicating the null DN of the root). 340 This attribute will allow a client to choose suitable base objects 341 for searching when it has contacted a server. 343 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 344 SYNTAX 'DN' USAGE dSAOperation ) 346 5.2.2. altServer 348 The values of this attribute are URLs of other servers which may be 349 contacted when this server becomes unavailable. If the server does not 350 know of any other servers which could be used this attribute will be 351 absent. Clients may cache this information in case their preferred LDAP 352 server later becomes unavailable. 354 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 355 SYNTAX 'IA5String' USAGE dSAOperation ) 357 5.2.3. supportedExtension 359 The values of this attribute are OBJECT IDENTIFIERs identifying the 360 supported extended operations which the server supports. 362 If the server does not support any extensions this attribute will be 363 absent. 365 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 366 SYNTAX 'OID' USAGE dSAOperation ) 368 5.2.4. supportedControl 370 The values of this attribute are the OBJECT IDENTIFIERS identifying 371 controls which the server supports. If the server does not 372 support any controls, this attribute will be absent. 374 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 375 SYNTAX 'OID' USAGE dSAOperation ) 377 5.2.5. supportedSASLMechanisms 379 The values of this attribute are the names of supported SASL 380 mechanisms which the server supports. If the server does not 381 support any mechanisms this attribute will be absent. 383 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 384 SYNTAX 'LDAPString' USAGE dSAOperation ) 386 5.2.6. supportedLDAPVersion 388 The values of this attribute are the versions of the LDAP protocol which 389 the server implements. 391 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 392 SYNTAX 'INTEGER' USAGE dSAOperation ) 394 6. Syntaxes 396 Servers SHOULD recognize all the syntaxes described in this section 397 (6.1 - 6.3). 399 6.1. AttributeTypeDescription 401 Values with this syntax are encoded according to the BNF given at the 402 start of section 4.1. For example, 404 ( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' ) 406 6.2. Audio 408 The encoding of a value with Audio syntax is the octets of the value 409 itself, an 8KHz uncompressed encoding compatible with the SunOS 410 4.1.3 'play' utility. 412 6.3. BitString 414 The encoding of a value with BitString syntax is according to the 415 following BNF: 417 ::= ''' ''B' 419 ::= '0' | '1' | 420 empty 422 Example: 424 '0101111101'B 426 6.4. Boolean 428 Values with Boolean syntax are encoded according to the following 429 BNF: 431 ::= "TRUE" | "FALSE" 433 Boolean values have an encoding of "TRUE" if they are logically true, 434 and have an encoding of "FALSE" otherwise. 436 6.5. Certificate 438 Because of the changes from X.509(1988) and X.509(1993) and additional 439 changes to the ASN.1 definition to support certificate extensions, no 440 string representation is defined, and values with Certificate syntax 441 MUST only be transferred using the binary encoding, by requesting or 442 returning the attributes with descriptions "userCertificate;binary" or 443 "caCertificate;binary". The BNF notation in RFC 1778 for 444 "User Certificate" is not recommended to be used. 446 6.6. CertificateList 448 Because of the incompatibility of the X.509(1988) and X.509(1993) 449 definitions of revocation lists, values with CertificateList syntax 450 MUST only be transferred using a binary encoding, by requesting or 451 returning the attributes with descriptions 452 "certificateRevocationList;binary" or "authorityRevocationList;binary". 453 The BNF notation in RFC 1778 for "Authority Revocation List" is not 454 recommended to be used. 456 6.7. CertificatePair 458 Because the Certificate is being carried in binary, values with 459 CertificatePair syntax MUST only be transferred using a binary encoding, 460 by requesting or returning the attribute description 461 "crossCertificatePair;binary". The BNF notation in RFC 1778 for 462 "Certificate Pair" is not recommended to be used. 464 6.8. CountryString 466 A value of CountryString syntax is encoded the same as a value of 467 DirectoryString syntax. Note that this syntax is limited to values of 468 exactly two printable string characters. 470 ::=

472 Example: 473 US 475 6.9. DN 477 Values with DN (Distinguished Name) syntax are encoded to have the 478 representation defined in [5]. Note that this representation is not 479 reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as 480 the CHOICE of any DirectoryString element in an RDN is no longer known. 482 Examples (from [5]): 483 CN=Steve Kille,O=Isode Limited,C=GB 484 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 485 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 486 CN=Before\0DAfter,O=Test,C=GB 487 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 488 SN=Lu\C4\8Di\C4\C7 490 6.10. DirectoryString 492 A string with DirectoryString syntax is encoded in the UTF-8 form of 493 ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to 494 receive encodings of arbitrary Unicode characters, including characters 495 not presently assigned to any character set, in values. 497 For characters in the PrintableString form, the value is encoded as the 498 string value itself. 500 If it is of the TeletexString form, then the characters are transliterated 501 to their equivalents in UniversalString, and encoded in UTF-8 [9]. 503 If it is of the UniversalString or BMPString forms [10], UTF-8 is used to 504 encode them. 506 Note: the form of DirectoryString is not indicated in protocol unless the 507 attribute value is carried in binary. Servers which convert to DAP MUST 508 choose an appropriate form. Servers MUST NOT reject values merely because 509 they contain legal Unicode characters outside of the range of printable 510 ASCII. 512 Example: 514 This is a string of DirectoryString containing #!%#@ 516 6.11. DITContentRuleDescription 518 Values with this syntax are encoded according to the following BNF: 520 ::= "(" 521 -- Structural ObjectClass identifier 522 [ "NAME" ] 523 [ "DESC" ] 524 [ "OBSOLETE" ] 525 [ "AUX" ] -- Auxiliary ObjectClasses 526 [ "MUST" ] -- AttributeType identifiers 527 [ "MAY" ] -- AttributeType identifiers 528 [ "NOT" ] -- AttributeType identifiers 529 ")" 531 6.12. FacsimileTelephoneNumber 533 Values with the FacsimileTelephoneNumber syntax are encoded according 534 to the following BNF: 536 ::= [ '$' ] 538 ::= | '$' 540 ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | 541 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' 543 In the above, the first is the actual fax number, 544 and the tokens represent fax parameters. 546 6.13. Fax 548 Values with Fax syntax are encoded as if they were octet strings 549 containing Group 3 Fax images as defined in [7]. 551 6.14. GeneralizedTime 553 Values of this syntax are encoded as printable strings, represented 554 as specified in X.208. Note that the time zone must be specified. 555 It is strongly recommended that Zulu time zone be used. For example, 557 199412161032Z 559 6.15. IA5String 561 The encoding of a value with IA5String syntax is the string value 562 itself. 564 6.16. INTEGER 566 Values with INTEGER syntax are encoded as the decimal representation 567 of their values, with each decimal digit represented by the its 568 character equivalent. So the number 1321 is represented by the character 569 string "1321". 571 6.17. JPEG 573 Values with JPEG syntax are encoded as if they were octet strings 574 containing JPEG images in the JPEG File Interchange Format (JFIF), as 575 described in [8]. 577 6.18. MatchingRuleUseDescription 579 Values of this syntax are encoded according to the following BNF: 581 ::= "(" 582 -- MatchingRule identifier 583 [ "NAME" ] 584 [ "DESC" ] 585 [ "OBSOLETE" ] 586 "APPLIES" -- AttributeType identifiers 587 ")" 589 6.19. MHSORAddress 591 Values of type MHSORAddress are encoded as strings, according to 592 the format defined in [11]. 594 6.20. NameAndOptionalUID 596 The encoding of a value with the NameAndOptionalUID syntax is according 597 to the following BNF: 599 ::= 600 [ '#' ] 602 Although the '#' character may occur in a string representation of a 603 distinguished name, no additional special quoting is done. 605 This syntax has been added subsequent to RFC 1778. 607 Example: 609 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 611 6.21. NameFormDescription 613 Values of this syntax are encoded according to the following BNF: 615 ::= "(" 616 -- NameForm identifier 617 [ "NAME" ] 618 [ "DESC" ] 619 [ "OBSOLETE" ] 620 "OC" -- Structural ObjectClass 621 "MUST" -- AttributeTypes 622 [ "MAY" ] -- AttributeTypes 623 ")" 625 6.22. NumericString 627 The encoding of a string with the NumericString syntax is the string 628 value itself. Example: 630 1997 632 6.23. ObjectClassDescription 634 Values of this syntax are encoded according to the BNF in section 4.3. 636 6.24. OID 638 Values with OID (Object Identifier) syntax are encoded according to the 639 following BNF: 641 ::= | 643 ::= 645 ::= | '.' 647 In the above BNF, is the syntactic representation of an 648 object descriptor, which consists of letters and digits, starting 649 with a letter. When encoding values with OID syntax, the first encoding 650 option MUST be used in preference to the second. That is, in encoding 651 object identifiers, object descriptors (where assigned and known by 652 the implementation) must be used in preference to numeric oids to 653 the greatest extent possible. All permitted object descriptors for use 654 in LDAP are given in this document. No other object descriptors may be 655 used. (Note that clients should expect that LDAPv2 implementations 656 will return object descriptors other than those listed.) 658 Example: 660 1.2.3.4 661 cn 663 6.25. OtherMailbox 665 Values of the OtherMailbox syntax are encoded according to the 666 following BNF: 668 ::= '$' 670 ::= an encoded Printable String 672 ::= an encoded IA5 String 674 In the above, represents the type of mail system in 675 which the mailbox resides, for example "MCIMail"; and is the 676 actual mailbox in the mail system defined by . 678 6.26. Password 680 Values with Password syntax are encoded as octet strings. 682 Example: 684 secret 686 6.27. PostalAddress 688 Values with the PostalAddress syntax are encoded according to the 689 following BNF: 691 ::= | '$' 693 In the above, each component of a postal address value is 694 encoded as a value of type DirectoryString syntax. Backslashes and 695 dollar characters, if they occur in the component, are quoted as 696 described in section 4.2. 698 Example: 700 1234 Main St.$Anytown, CA 12345$USA 701 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 703 6.28. PresentationAddress 705 Values with the PresentationAddress syntax are encoded to have the 706 representation described in [6]. 708 6.29. PrintableString 710 The encoding of a value with PrintableString syntax is the string 711 value itself. PrintableString is limited to the characters in 712 production

of section 4.1. 714 Example: 716 This is a PrintableString 718 6.30. TelephoneNumber 720 Values with the TelephoneNumber syntax are encoded as if they were 721 Printable String types. Telephone numbers are recommended in X.520 to 722 be in international form. 724 Example: 726 +1 512 305 0280 728 6.31. UTCTime 730 Values with UTCTime syntax are encoded as if they were printable 731 strings with the strings containing a UTCTime value. This is historical; 732 new attribute definitions will use GeneralizedTime instead. 734 7. Object Classes 736 Servers SHOULD recognize all the names of standard classes from section 737 7 of [12], as well as the names of the Internet classes from section 738 7 of [13]. 740 7.1. Extensible Object Class 742 The extensibleObject object class, if present in an entry, permits that 743 entry to optionally hold any attribute. The MAY attribute list of this 744 class is implicitly the set of all attributes known to the server. 746 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 747 SUP top AUXILIARY ) 749 The mandatory attributes of the other object classes of this entry are 750 still required to be present. 752 Note that not all servers will implement this object class, and those 753 which do not will reject requests to add entries which contain this 754 object class, or modify an entry to add this object class. 756 8. Matching Rules 758 Servers which implement extensibleMatch SHOULD recognize the following 759 matching rules, used for equality matching, and be capable of 760 performing the matching rules. For all these rules, the 761 assertion syntax is the same as the value syntax. 763 ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 'OID' ) 764 ( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 'DN' ) 765 ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 'DirectoryString' ) 766 ( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 'NumericString' ) 767 ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 'PostalAddress' ) 768 ( 2.5.13.14 NAME 'integerMatch' SYNTAX 'INTEGER' ) 769 ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 'BitString' ) 770 ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 'Password' ) 771 ( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 'TelephoneNumber' ) 772 ( 2.5.13.22 NAME 'presentationAddressMatch' SYNTAX 'PresentationAddress' ) 773 ( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 'NameAndOptionalUID' ) 774 ( 2.5.13.24 NAME 'protocolInformationMatch' SYNTAX 'ProtocolInformation' ) 775 ( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 'GeneralizedTime' ) 776 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 'IA5String' ) 777 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 'IA5String' ) 779 When performing the caseIgnoreMatch, caseIgnoreListMatch, 780 telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, 781 multiple adjoining whitespace characters are treated the same as an 782 individual space, and leading and trailing whitespace is ignored. 784 9. Security Considerations 786 Security issues are not discussed in this memo. 788 10. Acknowledgements 790 This document is based substantially on RFC 1778, written by Tim Howes, 791 Steve Kille, Wengyik Yeong and Colin Robbins. 793 Many of the attribute syntax encodings defined in this document are 794 adapted from those used in the QUIPU and the IC R3 X.500 795 implementations. The contributions of the authors of both these 796 implementations in the specification of syntaxes in this document are 797 gratefully acknowledged. 799 11. Authors Addresses 801 Mark Wahl 802 Critical Angle Inc. 803 4815 West Braker Lane #502-385 804 Austin, TX 78759 805 USA 807 EMail: M.Wahl@critical-angle.com 809 Andy Coulbeck 810 Isode Limited 811 The Dome, The Square 812 Richmond TW9 1DT 813 United Kingdom 815 Phone: +44 181-332-9091 816 EMail: A.Coulbeck@isode.com 818 Tim Howes 819 Netscape Communications Corp. 820 501 E. Middlefield Rd 821 Mountain View, CA 94043 822 USA 824 Phone: +1 415 254-1900 825 EMail: howes@netscape.com 827 Steve Kille 828 Isode Limited 829 The Dome, The Square 830 Richmond 831 TW9 1DT 832 UK 834 Phone: +44-181-332-9091 835 EMail: S.Kille@isode.com 837 12. Bibliography 839 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 840 (Version 3)", INTERNET-DRAFT , 841 March 1997. 843 [2] The Directory: Selected Attribute Types. ITU-T Recommendation 844 X.520, 1993. 846 [3] The Directory: Models. ITU-T Recommendation X.501, 1993. 848 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 849 Levels", INTERNET-DRAFT . 851 [5] M. Wahl, S. Kille, "A UTF-8 String Representation of Distinguished 852 Names", INTERNET-DRAFT , 853 March 1997. 855 [6] S. Kille, "A String Representation for Presentation Addresses", 856 RFC 1278, University College London, November 1991. 858 [7] Terminal Equipment and Protocols for Telematic Services - 859 Standardization of Group 3 facsimile apparatus for document 860 transmission. CCITT, Recommendation T.4. 862 [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 863 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 865 [9] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 866 10646", RFC 2044, October 1996. 868 [10] Universal Multiple-Octet Coded Character Set (UCS) - Architecture 869 and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993. 871 [11] H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson, 872 "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495, 873 August 1993. 875 [12] M. Wahl, "X.500(93) User Schema for use with LDAP", 876 INTERNET-DRAFT , 877 March 1997. 879 [13] M. Wahl, "Pilot Internet Schema for use with LDAP", 880 INTERNET-DRAFT , 881 March 1997. 883 884 Expires: September 1997