idnits 2.17.1 draft-ietf-asid-ldapv3-attributes-05.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-25) 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 24 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 14 instances of too long lines in the document, the longest one being 2 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 28 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 (6 June 1997) is 9820 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 1214 looks like a reference -- Missing reference section? '4' on line 1223 looks like a reference -- Missing reference section? '13' on line 1254 looks like a reference -- Missing reference section? '9' on line 1240 looks like a reference -- Missing reference section? '3' on line 1221 looks like a reference -- Missing reference section? '12' on line 1250 looks like a reference -- Missing reference section? '5' on line 1226 looks like a reference -- Missing reference section? '10' on line 1243 looks like a reference -- Missing reference section? '7' on line 1233 looks like a reference -- Missing reference section? '8' on line 1237 looks like a reference -- Missing reference section? '11' on line 1247 looks like a reference -- Missing reference section? '6' on line 1230 looks like a reference -- Missing reference section? '2' on line 1218 looks like a reference Summary: 10 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 6 June 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 35 the 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 40 that define attribute types. This document also defines the set of 41 attribute types which LDAP servers should support. 43 3. Overview 45 This document defines the framework for developing schemas for 46 directories accessible via the Lightweight Directory Access Protocol. 48 Schema is the collection of attribute type definitions, object class 49 definitions and other information which a server uses to determine 50 how to match a filter or attribute value assertion (in a compare 51 operation) against the attributes of an entry, and whether to permit 52 add and modify operations. 54 Section 4 states the general requirements and notations for attribute 55 types, object classes, syntax and matching rule definitions. 57 Section 5 lists attributes, section 6 syntaxes and section 7 object 58 classes. 60 Additional documents define schemas for representing real-world 61 objects as directory entries. 63 4. General Issues 65 This document describes encodings used in an Internet protocol. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 69 this document are to be interpreted as described in RFC 2119 [4]. 71 4.1. Common Encoding Aspects 73 For the purposes of defining the encoding rules for attribute 74 syntaxes, the following BNF definitions will be used. They are 75 based on the BNF styles of RFC 822 [13]. 77 a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / 78 "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / 79 "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / 80 "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / 81 "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / 82 "T" / "U" / "V" / "W" / "X" / "Y" / "Z" 84 d = "0" / "1" / "2" / "3" / "4" / 85 "5" / "6" / "7" / "8" / "9" 87 hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" / 88 "A" / "B" / "C" / "D" / "E" / "F" 90 k = a / d / "-" 92 p = a / d / """ / "(" / ")" / "+" / "," / 93 "-" / "." / "/" / ":" / "?" / " " 95 letterstring = 1*a 97 numericstring = 1*d 99 anhstring = 1*k 101 keystring = a [ anhstring ] 103 printablestring = 1*p 105 space = 1*" " 107 whsp = [ space ] 109 utf8 = 112 dstring = 1*utf8 114 qdstring = whsp "'" dstring "'" whsp 116 qdstringlist = ( qdstringlist qdstring ) / "" 118 qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp ) 120 In the following BNF for the string representation of OBJECT 121 IDENTIFIERs, descr is the syntactic representation of an object 122 descriptor, which consists of letters and digits, starting with a 123 letter. An OBJECT IDENTIFIER in the numericoid format should not 124 have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should 125 not be generated). 127 When encoding values in syntax, the descr encoding option SHOULD 128 be used in preference to the numericoid. An object descriptor is 129 a more readable alias for a number OBJECT IDENTIFIER, and these 130 (where assigned and known by the implementation) SHOULD be used in 131 preference to numeric oids to the greatest extent possible. 132 Examples of object descriptors in LDAP are attribute type, object 133 class and matching rule names. 135 oid = descr / numericoid 137 descr = keystring 139 numericoid = numericstring *( "." numericstring ) 141 woid = whsp oid whsp 143 ; set of oids of either form 144 oids = woid / ( "(" oidlist ")" ) 146 oidlist = woid *( "$" woid ) 148 ; object descriptors used as schema element names 149 qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) 151 qdescrlist = ( qdescrlist qdescr ) / "" 153 qdescr = whsp "'" descr "'" whsp 155 4.2. Attribute Types 157 The attribute types are described by sample values for the subschema 158 "attributeTypes" attribute, which is written in the 159 AttributeTypeDescription syntax. While lines have been folded for 160 readability, the values transferred in protocol would not contain 161 newlines. 163 The AttributeTypeDescription is encoded according to the following 164 BNF, and the productions for oid, qdsescrs and qdstring are given 165 in section 4.1. Implementors should note that future versions of this 166 document may have expanded this BNF to include additional terms. 168 AttributeTypeDescription = "(" whsp 169 numericoid whsp ; AttributeType identifier 170 [ "NAME" qdescrs ] ; name used in AttributeType 171 [ "DESC" qdstring ] ; description 172 [ "OBSOLETE" whsp ] 173 [ "SUP" woid ] ; derived from this other 174 ; AttributeType 175 [ "EQUALITY" woid ; Matching Rule name 176 [ "ORDERING" woid ; Matching Rule name 177 [ "SUBSTR" woid ] ; Matching Rule name 178 [ "SYNTAX" whsp numericoid whsp ] ; see section 4.2 179 [ "SINGLE-VALUE" whsp ] ; default multi-valued 180 [ "COLLECTIVE" whsp ] ; default not collective 181 [ "NO-USER-MODIFICATION" whsp ]; default user modifiable 182 [ "USAGE" whsp AttributeUsage ]; default user applications 183 whsp ")" 185 AttributeUsage = 186 "userApplications" / 187 "directoryOperation" / 188 "distributedOperation" / ; DSA-shared 189 "dSAOperation" ; DSA-specific, value depends on server 191 Servers are not required to provide the same or any text 192 in the description part of the subschema values they maintain. 193 Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields 194 for each AttributeTypeDescription. 196 Servers SHOULD implement all the attribute types referenced in 197 section 5. Servers MUST be able to evaluate presence filters, 198 SHOULD be able to perform equality matching of values of all user 199 attributes known to the server, and MAY be able to perform matching 200 with the other kinds of filters. If a server allows values of an 201 attribute of a particular type to be added or removed over protocol, 202 the server MUST be able to perform equality matching of values of 203 that attribute, but need not perform any additional validity checks 204 on attribute values. 206 Servers MAY recognize additional names and attributes not listed in 207 this document, and if they do so, SHOULD publish the definitions of 208 the types in the attributeTypes attribute of their subschema 209 entries. 211 AttributeDescriptions can be used as the value in a NAME part of an 212 AttributeTypeDescription. Note that these are case insensitive. 214 Note that the AttributeTypeDescription does not list the matching 215 rules which can can be used with that attribute type in an 216 extensibleMatch search filter. This is done using the matchingRuleUse 217 attribute described in section 4.4. 219 4.2. Syntaxes 221 This section defines general requirements for LDAP attribute value 222 syntax encodings. All documents defining attribute syntax encodings 223 for use with LDAP are expected to conform to these requirements. 225 The encoding rules defined for a given attribute syntax must produce 226 octet strings. To the greatest extent possible, encoded octet 227 strings should be usable in their native encoded form for display 228 purposes. In particular, encoding rules for attribute syntaxes 229 defining non-binary values should produce strings that can be 230 displayed with little or no translation by clients implementing 231 LDAP. There are a few cases (e.g. audio) however, when it is not 232 sensible to produce a printable representation, and clients MUST NOT 233 assume that an unrecognized syntax is a string representation. 235 In encodings where an arbitrary string is used as part of a larger 236 production (other than a Distinguished Name), a backslash quoting 237 mechanism is used to encode the following separator symbol character 238 (such as "'", "$" or "#") if it should occur in that string. The 239 backslash is followed by a pair of hexadecimal digits representing the 240 next character. A backslash itself in the string which forms part of 241 a larger syntax is always transmitted as '\5C' or '\5c'. 243 Syntaxes are also defined for matching rules whose assertion value 244 syntax is different from the attribute value syntax. 246 4.2.1 Binary Transfer of Values 248 This encoding format is used if the binary encoding is requested by 249 the client for an attribute, or if the attribute syntax name is 250 "1.3.6.1.4.1.1466.115.121.1.5". The value, an instance of the ASN.1 251 AttributeValue type, is BER-encoded, subject to the restrictions of 252 section 5.1 of [1], and this sequence of octets is used as the value. 253 (E.g. the first byte inside the OCTET STRING wrapper is a tag byte. 254 However the OCTET STRING is still encoded in primitive form.) 256 All servers MUST implement this form for both generating attribute 257 values in search responses, and parsing attribute values in add, 258 compare and modify requests, if the attribute type is recognized and 259 the attribute syntax name is that of Binary. Clients which request 260 that all attributes be returned from entries MUST be prepared 261 to receive values in binary (e.g. userCertificate), and SHOULD NOT 262 simply display binary or unrecognized values to users. 264 4.2.2. Syntax Object Identifiers 266 Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which 267 are dotted-decimal strings. These are not intended to be displayed 268 to users. 270 The following table lists some of the syntaxes that have been defined 271 for LDAP thus far. The H-R column suggests whether a value in that 272 syntax would likely be a human readable string. Clients and servers 273 need not implement all the syntaxes listed here, and MAY implement 274 other syntaxes. 276 Other documents may define additional syntaxes. However, the 277 definition of additional arbitrary syntaxes is strongly depreciated 278 since it will hinder interoperability: today's client and server 279 implementations generally do not have the ability to dynamically 280 recognize new syntaxes. In most cases attributes will be defined 281 with the syntax for directory strings. 283 Value being represented H-R OBJECT IDENTIFIER 284 ================================================================= 285 ACI Item N 1.3.6.1.4.1.1466.115.121.1.1 286 Access Point Y 1.3.6.1.4.1.1466.115.121.1.2 287 Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3 288 Audio N 1.3.6.1.4.1.1466.115.121.1.4 289 Binary N 1.3.6.1.4.1.1466.115.121.1.5 290 Bit String Y 1.3.6.1.4.1.1466.115.121.1.6 291 Boolean Y 1.3.6.1.4.1.1466.115.121.1.7 292 Certificate N 1.3.6.1.4.1.1466.115.121.1.8 293 Certificate List N 1.3.6.1.4.1.1466.115.121.1.9 294 Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10 295 Country String Y 1.3.6.1.4.1.1466.115.121.1.11 296 DN Y 1.3.6.1.4.1.1466.115.121.1.12 297 Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13 298 Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14 299 Directory String Y 1.3.6.1.4.1.1466.115.121.1.15 300 DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16 301 DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17 302 DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18 303 DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19 304 DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20 305 Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21 306 Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22 307 Fax N 1.3.6.1.4.1.1466.115.121.1.23 308 Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24 309 Guide Y 1.3.6.1.4.1.1466.115.121.1.25 310 IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26 311 INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27 312 JPEG N 1.3.6.1.4.1.1466.115.121.1.28 313 LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54 314 Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29 315 Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30 316 Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31 317 Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32 318 MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33 319 Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34 320 Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35 321 Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36 322 Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37 323 OID Y 1.3.6.1.4.1.1466.115.121.1.38 324 Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39 325 Password Y 1.3.6.1.4.1.1466.115.121.1.40 326 Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41 327 Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 328 Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43 329 Printable String Y 1.3.6.1.4.1.1466.115.121.1.44 330 Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45 331 Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46 332 Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47 333 Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48 334 Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49 335 Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50 336 Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51 337 Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52 338 UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53 340 A suggested minimum upper bound on the number of characters in value 341 with a string-based syntax, or the number of bytes in a value for all 342 other syntaxes, may be indicated by appending this bound count inside 343 of curly braces following the syntax name's OBJECT IDENTIFIER. This 344 bound is not part of the syntax name itself. For instance, 345 "1.3.6.4.1.1466.0{64}" suggests that server implementations should 346 allow the string to be 64 characters long, although they may allow 347 longer strings. Note that a single character of the Directory String 348 syntax may be encoded in more than one byte since UTF-8 is a 349 variable-length encoding. 351 4.2.3. Syntax Description 353 The following BNF may be used to associate a short description with 354 a syntax OBJECT IDENTIFIER. Implementors should note that future 355 versions of this document may expand this definition to include 356 additional terms. 358 SyntaxDescription = "(" whsp 359 numericoid whsp 360 [ "DESC" qdstring ] 361 whsp ")" 363 4.3. Object Classes 365 The format for representation of object classes is defined in X.501 366 [3]. In general every entry will contain an abstract class ("top" or 367 "alias"), at least one structural object class, and zero or more 368 auxiliary object classes. Whether an object class is abstract, 369 structural or auxiliary is defined when the object class identifier 370 is assigned. An object class definition should not be changed 371 without having a new identifier assigned to it. 373 Object class descriptions are written according to the following BNF. 374 Implementors should note that future versions of this document may 375 expand this definition to include additional terms. 377 ObjectClassDescription = "(" whsp 378 numericoid whsp ; ObjectClass identifier 379 [ "NAME" qdescrs ] 380 [ "DESC" qdstring ] 381 [ "OBSOLETE" whsp ] 382 [ "SUP" oids ] ; Superior ObjectClasses 383 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] 384 ; default structural 385 [ "MUST" oids ] ; AttributeTypes 386 [ "MAY" oids ] ; AttributeTypes 387 whsp ")" 389 These are described as sample values for the subschema 390 "objectClasses" attribute for a server which implements the LDAP 391 schema. While lines have been folded for readability, the values 392 transferred in protocol would not contain newlines. 394 Servers SHOULD implement all the object classes referenced in 395 section 7, except for extensibleObject, which is optional. 397 Servers MAY implement additional object classes not listed in this 398 document, and if they do so, SHOULD publish the definitions of the 399 classes in the objectClasses attribute of their subschema entries. 400 Later documents may define additional object classes. 402 4.4. Matching Rules 404 Matching rules are used by servers to compare attribute values 405 against assertion values when performing Search and Compare 406 operations. They are also used to identify the value to be added 407 or deleted when modifying entries, and are used when comparing a 408 purported distinguished name with the name of an entry. 410 Most of the attributes given in this document will have an equality 411 matching rule defined. 413 Matching rule descriptions are written according to the following 414 BNF. Implementors should note that future versions of this document 415 may have expanded this BNF to include additional terms. 417 MatchingRuleDescription = "(" whsp 418 numericoid whsp ; MatchingRule identifier 419 [ "NAME" qdescrs ] 420 [ "DESC" qdstring ] 421 [ "OBSOLETE" whsp ] 422 "SYNTAX" numericoid 423 whsp ")" 425 Values of the matchingRuleUse list the attributes which are suitable 426 for use with an extensible matching rule. 428 MatchingRuleUseDescription = "(" whsp 429 numericoid whsp ; MatchingRule identifier 430 [ "NAME" qdescrs ] 431 [ "DESC" qdstring ] 432 [ "OBSOLETE" ] 433 "APPLIES" oids ; AttributeType identifiers 434 whsp ")" 436 Servers which support matching rules and the extensibleMatch SHOULD 437 implement all the matching rules in section 8. 439 Servers MAY implement additional matching rules not listed in this 440 document, and if they do so, SHOULD publish the definitions of the 441 matching rules in the matchingRules attribute of their 442 subschema entries. If the server supports the extensibleMatch, then 443 the server SHOULD publish the relationship between the matching rules 444 and attributes in the matchingRuleUse attribute. 446 For example, a server which implements a privately-defined matching 447 rule for performing sound-alike matches on Directory String-valued 448 attributes would include the following in the subschema entry 449 (1.2.3.4.5 is an example, the OID of an actual matching rule would be 450 different): 452 matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' 453 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) 455 If this matching rule could be used with the attributes 2.5.4.41 and 456 2.5.4.15, the following would also be present: 458 matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) ) 460 A client could then make use of this matching rule by sending a 461 search operation in which the filter is of the extensibleMatch choice, 462 the matchingRule field is "soundAlikeMatch", and the type field is 463 "2.5.4.41" of "2.5.4.15". 465 5. Attribute Types 467 All LDAP server implementations MUST recognize the attribute types 468 defined in this section. These types are based on definitions in 469 X.501(93) [3]. 471 Servers SHOULD also recognize all the attributes from section 5 of 472 [12]. 474 5.1. Standard Operational Attributes 476 Servers MUST maintain values of these attributes in accordance with 477 the definitions in X.501(93). 479 5.1.1. createTimestamp 481 This attribute SHOULD appear in entries which were created using 482 the Add operation. 484 ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch 485 ORDERING generalizedTimeOrderingMatch 486 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' 487 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 489 5.1.2. modifyTimestamp 491 This attribute SHOULD appear in entries which have been modified 492 using the Modify operation. 494 ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch 495 ORDERING generalizedTimeOrderingMatch 496 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' 497 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 499 5.1.3. creatorsName 501 This attribute SHOULD appear in entries which were created using 502 the Add operation. 504 ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch 505 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' 506 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 508 5.1.4. modifiersName 510 This attribute SHOULD appear in entries which have been modified 511 using the Modify operation. 513 ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch 514 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' 515 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 517 5.1.5. subschemaSubentry 519 The value of this attribute is the name of a subschema entry (or 520 subentry if the server is based on X.500(93)) in which the server 521 makes available attributes specifying the schema. 523 ( 2.5.18.10 NAME 'subschemaSubentry' 524 EQUALITY distinguishedNameMatch 525 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' NO-USER-MODIFICATION 526 SINGLE-VALUE USAGE directoryOperation ) 528 5.1.6. attributeTypes 530 This attribute is typically located in the subschema entry. 532 ( 2.5.21.5 NAME 'attributeTypes' 533 EQUALITY objectIdentifierFirstComponentMatch 534 SYNTAX '1.3.6.1.4.1.1466.115.121.1.3' USAGE directoryOperation ) 536 5.1.7. objectClasses 538 This attribute is typically located in the subschema entry. 540 ( 2.5.21.6 NAME 'objectClasses' 541 EQUALITY objectIdentifierFirstComponentMatch 542 SYNTAX '1.3.6.1.4.1.1466.115.121.1.37' USAGE directoryOperation ) 544 5.1.8. matchingRules 546 This attribute is typically located in the subschema entry. 548 ( 2.5.21.4 NAME 'matchingRules' 549 EQUALITY objectIdentifierFirstComponentMatch 550 SYNTAX '1.3.6.1.4.1.1466.115.121.1.30' USAGE directoryOperation ) 552 5.1.9. matchingRuleUse 554 This attribute is typically located in the subschema entry. 556 ( 2.5.21.8 NAME 'matchingRuleUse' 557 EQUALITY objectIdentifierFirstComponentMatch 558 SYNTAX '1.3.6.1.4.1.1466.115.121.1.31' USAGE directoryOperation ) 560 5.2. LDAP Operational Attributes 562 These attributes are only present in the root DSE (see [1] and [3]). 564 Servers MUST recognize these attribute names, but it is not required 565 that a server provide values for these attributes, when the 566 attribute corresponds to a feature which the server does not 567 implement. 569 5.2.1. namingContexts 571 The values of this attribute correspond to naming contexts which this 572 server masters or shadows. If the server does not master any 573 information (e.g. it is an LDAP gateway to a public X.500 directory) 574 this attribute will be absent. If the server believes it contains 575 the entire directory, the attribute will have a single value, and 576 that value will be the empty string (indicating the null DN of the 577 root). This attribute will allow a client to choose suitable base 578 objects for searching when it has contacted a server. 580 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 581 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' USAGE dSAOperation ) 583 5.2.2. altServer 585 The values of this attribute are URLs of other servers which may be 586 contacted when this server becomes unavailable. If the server does 587 not know of any other servers which could be used this attribute 588 will be absent. Clients may cache this information in case their 589 preferred LDAP server later becomes unavailable. 591 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 592 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' USAGE dSAOperation ) 594 5.2.3. supportedExtension 596 The values of this attribute are OBJECT IDENTIFIERs identifying the 597 supported extended operations which the server supports. 599 If the server does not support any extensions this attribute will be 600 absent. 602 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 603 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' USAGE dSAOperation ) 605 5.2.4. supportedControl 607 The values of this attribute are the OBJECT IDENTIFIERS identifying 608 controls which the server supports. If the server does not 609 support any controls, this attribute will be absent. 611 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 612 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' USAGE dSAOperation ) 614 5.2.5. supportedSASLMechanisms 616 The values of this attribute are the names of supported SASL 617 mechanisms which the server supports. If the server does not 618 support any mechanisms this attribute will be absent. 620 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 621 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' USAGE dSAOperation ) 623 5.2.6. supportedLDAPVersion 625 The values of this attribute are the versions of the LDAP protocol 626 which the server implements. 628 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 629 SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' USAGE dSAOperation ) 631 5.3. LDAP Subschema Attribute 633 This attribute is typically located in the subschema entry. 635 5.3.1. ldapSyntaxes 637 Servers MAY use this attribute to list the syntaxes which are 638 implemented. Each value corresponds to one syntax. 640 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 641 EQUALITY objectIdentifierFirstComponentMatch 642 SYNTAX '1.3.6.1.4.1.1466.115.121.1.54' USAGE directoryOperation ) 644 6. Syntaxes 646 Servers SHOULD recognize all the syntaxes described in this section. 647 Each syntax begins with a sample value of the ldapSyntaxes attribute 648 which defines the OBJECT IDENTIFIER of the syntax. The descriptions 649 of syntax names are not carried in protocol, and are not guaranteed 650 to be unique. 652 6.1. Attribute Type Description 654 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 656 Values in this syntax are encoded according to the BNF given at the 657 start of section 4.2. For example, 659 ( 2.5.4.0 NAME 'objectClass' 660 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) 662 6.2. Binary 664 ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) 666 Values in this syntax are encoded as described in section 4.2.1. 668 6.3. Bit String 670 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 672 Values in this syntax are encoded according to the following BNF: 674 bitstring = "'" *binary-digit "'B" 676 binary-digit = "0" / "1" 678 Example: 680 '0101111101'B 682 6.4. Boolean 684 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 686 Values in this syntax are encoded according to the following BNF: 688 boolean = "TRUE" / "FALSE" 690 Boolean values have an encoding of "TRUE" if they are logically true, 691 and have an encoding of "FALSE" otherwise. 693 6.5. Certificate 695 ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) 697 Because of the changes from X.509(1988) and X.509(1993) and 698 additional changes to the ASN.1 definition to support certificate 699 extensions, no string representation is defined, and values in 700 this syntax MUST only be transferred using the binary encoding, by 701 requesting or returning the attributes with descriptions 702 "userCertificate;binary" or "caCertificate;binary". The BNF notation 703 in RFC 1778 for "User Certificate" is not recommended to be used. 705 6.6. Certificate List 707 ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) 709 Because of the incompatibility of the X.509(1988) and X.509(1993) 710 definitions of revocation lists, values in this syntax MUST only be 711 transferred using a binary encoding, by requesting or returning the 712 attributes with descriptions "certificateRevocationList;binary" or 713 "authorityRevocationList;binary". The BNF notation in RFC 1778 for 714 "Authority Revocation List" is not recommended to be used. 716 6.7. Certificate Pair 718 ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) 720 Because the Certificate is being carried in binary, values in this 721 syntax MUST only be transferred using a binary encoding, by requesting 722 or returning the attribute description "crossCertificatePair;binary". 723 The BNF notation in RFC 1778 for "Certificate Pair" is not 724 recommended to be used. 726 6.8. Country String 728 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 730 A value in this syntax is encoded the same as a value of 731 Directory String syntax. Note that this syntax is limited to values 732 of exactly two printable string characters. 734 CountryString = p p 736 Example: 737 US 739 6.9. DN 741 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 743 Values in the Distinguished Name syntax are encoded to have the 744 representation defined in [5]. Note that this representation is not 745 reversible to an ASN.1 encoding used in X.500 for Distinguished 746 Names, as the CHOICE of any DirectoryString element in an RDN is no 747 longer known. 749 Examples (from [5]): 750 CN=Steve Kille,O=Isode Limited,C=GB 751 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 752 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 753 CN=Before\0DAfter,O=Test,C=GB 754 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 755 SN=Lu\C4\8Di\C4\87 757 6.10. Directory String 759 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 761 A string in this syntax is encoded in the UTF-8 form of ISO 10646 762 (a superset of Unicode). Servers and clients MUST be prepared to 763 receive encodings of arbitrary Unicode characters, including 764 characters not presently assigned to any character set. 766 For characters in the PrintableString form, the value is encoded as 767 the string value itself. 769 If it is of the TeletexString form, then the characters are 770 transliterated to their equivalents in UniversalString, and encoded 771 in UTF-8 [9]. 773 If it is of the UniversalString or BMPString forms [10], UTF-8 is 774 used to encode them. 776 Note: the form of DirectoryString is not indicated in protocol 777 unless the attribute value is carried in binary. Servers which 778 convert to DAP MUST choose an appropriate form. Servers MUST NOT 779 reject values merely because they contain legal Unicode characters 780 outside of the range of printable ASCII. 782 Example: 784 This is a string of DirectoryString containing #!%#@ 786 6.11. DIT Content Rule Description 788 ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' ) 790 Values in this syntax are encoded according to the following BNF. 791 Implementors should note that future versions of this document 792 may have expanded this BNF to include additional terms. 794 DITContentRuleDescription = "(" 795 numericoid ; Structural ObjectClass identifier 796 [ "NAME" qdescrs ] 797 [ "DESC" qdstring ] 798 [ "OBSOLETE" ] 799 [ "AUX" oids ] ; Auxiliary ObjectClasses 800 [ "MUST" oids ] ; AttributeType identifiers 801 [ "MAY" oids ] ; AttributeType identifiers 802 [ "NOT" oids ] ; AttributeType identifiers 803 ")" 805 6.12. Facsimile Telephone Number 807 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) 809 Values in this syntax are encoded according to the following BNF: 811 fax-number = printablestring [ "$" faxparameters ] 813 faxparameters = faxparm / ( faxparm "$" faxparameters ) 815 faxparm = "twoDimensional" / "fineResolution" / 816 "unlimitedLength" / 817 "b4Length" / "a3Width" / "b4Width" / "uncompressed" 819 In the above, the first printablestring is the actual fax number, 820 and the faxparm tokens represent fax parameters. 822 6.13. Fax 824 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 826 Values in this syntax are encoded as if they were octet strings 827 containing Group 3 Fax images as defined in [7]. 829 6.14. Generalized Time 831 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 833 Values in this syntax are encoded as printable strings, represented 834 as specified in X.208. Note that the time zone must be specified. 835 It is strongly recommended that GMT time be used. For example, 837 199412161032Z 839 6.15. IA5 String 841 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 843 The encoding of a value in this syntax is the string value itself. 845 6.16. INTEGER 847 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 849 Values in this syntax are encoded as the decimal representation 850 of their values, with each decimal digit represented by the its 851 character equivalent. So the number 1321 is represented by the 852 character string "1321". 854 6.17. JPEG 856 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 858 Values in this syntax are encoded as strings containing JPEG images in 859 the JPEG File Interchange Format (JFIF), as described in [8]. 861 6.18. Matching Rule Description 863 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 865 Values of type matchingRules are encoded as strings according to 866 the BNF given in section 4.4. 868 6.19. Matching Rule Use Description 870 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' ) 872 Values of type matchingRuleUse are encoded as strings according to 873 the BNF given in section 4.4. 875 6.20. MHS OR Address 877 ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) 879 Values in this syntax are encoded as strings, according to the format 880 defined in [11]. 882 6.21. Name And Optional UID 884 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 886 Values in this syntax are encoded according to the following BNF: 888 NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 890 Although the '#' character may occur in a string representation of a 891 distinguished name, no additional special quoting is done. 893 This syntax has been added subsequent to RFC 1778. 895 Example: 897 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 899 6.22. Name Form Description 901 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 903 Values in this syntax are encoded according to the following BNF. 904 Implementors should note that future versions of this document 905 may have expanded this BNF to include additional terms. 907 NameFormDescription = "(" whsp 908 numericoid whsp ; NameForm identifier 909 [ "NAME" qdescrs ] 910 [ "DESC" qdstring ] 911 [ "OBSOLETE" whsp ] 912 "OC" woid ; Structural ObjectClass 913 "MUST" oids ; AttributeTypes 914 [ "MAY" oids ] ; AttributeTypes 915 whsp ")" 917 6.23. Numeric String 919 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 921 The encoding of a string in this syntax is the string value itself. 922 Example: 924 1997 926 6.24. Object Class Description 928 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 930 Values in this syntax are encoded according to the BNF in section 4.3. 932 6.25. OID 934 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 936 Values in the Object Identifier syntax are encoded according to 937 the BNF in section 4.1 for "oid". 939 Example: 941 1.2.3.4 942 cn 944 6.26. Other Mailbox 946 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 948 Values in this syntax are encoded according to the following BNF: 950 otherMailbox = mailbox-type "$" mailbox 952 mailbox-type = printablestring 954 mailbox = 956 In the above, mailbox-type represents the type of mail system in 957 which the mailbox resides, for example "MCIMail"; and mailbox is 958 the actual mailbox in the mail system defined by mailbox-type. 960 6.27. Postal Address 962 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 964 Values in this syntax are encoded according to the following BNF: 966 postal-address = dstring *( "$" dstring ) 968 In the above, each dstring component of a postal address value is 969 encoded as a value of type Directory String syntax. Backslashes and 970 dollar characters, if they occur in the component, are quoted as 971 described in section 4.2. 973 Example: 975 1234 Main St.$Anytown, CA 12345$USA 976 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 978 6.28. Presentation Address 980 ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) 982 Values in this syntax are encoded with the representation described 983 in RFC 1278 [6]. 985 6.29. Printable String 987 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 989 The encoding of a value in this syntax is the string value itself. 990 PrintableString is limited to the characters in production p of 991 section 4.1. 993 Example: 995 This is a PrintableString 997 6.30. Telephone Number 999 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1001 Values in this syntax are encoded as if they were Printable String 1002 types. Telephone numbers are recommended in X.520 to be in 1003 international form. 1005 Example: 1007 +1 512 305 0280 1009 6.31. UTC Time 1011 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1013 Values in this syntax are encoded as if they were printable 1014 strings with the strings containing a UTCTime value. This is 1015 historical; new attribute definitions SHOULD use GeneralizedTime 1016 instead. 1018 6.32. LDAP Syntax Description 1020 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 1022 Values in this syntax are encoded according to the BNF in section 1023 4.2.3. 1025 7. Object Classes 1027 Servers SHOULD recognize all the names of standard classes from 1028 section 7 of [12]. 1030 7.1. Extensible Object Class 1032 The extensibleObject object class, if present in an entry, permits 1033 that entry to optionally hold any attribute. The MAY attribute list 1034 of this class is implicitly the set of all attributes. 1036 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 1037 SUP top AUXILIARY ) 1039 The mandatory attributes of the other object classes of this entry 1040 are still required to be present. 1042 Note that not all servers will implement this object class, and those 1043 which do not will reject requests to add entries which contain this 1044 object class, or modify an entry to add this object class. 1046 8. Matching Rules 1048 Servers which implement the extensibleMatch filter SHOULD allow 1049 all the matching rules listed in this section to be used in the 1050 extensibleMatch. In general these servers SHOULD allow matching 1051 rules to be used with all attribute types known to the server, when 1052 the assertion syntax of the matching rule is the same as the value 1053 syntax of the attribute. 1055 Servers MAY implement additional matching rules. 1057 8.1. Matching Rules used in Equality Filters 1059 Servers SHOULD be capable of performing the following matching rules. 1061 For all these rules, the assertion syntax is the same as the value 1062 syntax. 1064 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1065 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) 1067 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1068 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) 1070 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1071 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) 1073 ( 2.5.13.8 NAME 'numericStringMatch' 1074 SYNTAX '1.3.6.1.4.1.1466.115.121.1.36' ) 1076 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1077 SYNTAX '1.3.6.1.4.1.1466.115.121.1.41' ) 1079 ( 2.5.13.14 NAME 'integerMatch' 1080 SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' ) 1082 ( 2.5.13.16 NAME 'bitStringMatch' 1083 SYNTAX '1.3.6.1.4.1.1466.115.121.1.6' ) 1085 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1086 SYNTAX '1.3.6.1.4.1.1466.115.121.1.50' ) 1088 ( 2.5.13.22 NAME 'presentationAddressMatch' 1089 SYNTAX '1.3.6.1.4.1.1466.115.121.1.43' ) 1091 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1092 SYNTAX '1.3.6.1.4.1.1466.115.121.1.34' ) 1094 ( 2.5.13.24 NAME 'protocolInformationMatch' 1095 SYNTAX '1.3.6.1.4.1.1466.115.121.1.42' ) 1097 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1098 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' ) 1100 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1101 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' ) 1103 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1104 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' ) 1106 When performing the caseIgnoreMatch, caseIgnoreListMatch, 1107 telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, 1108 multiple adjoining whitespace characters are treated the same as an 1109 individual space, and leading and trailing whitespace is ignored. 1111 8.2. Matching Rules used in Inequality Filters 1113 Servers SHOULD be capable of performing the following matching rules, 1114 which are used in greaterOrEqual and lessOrEqual filters. 1116 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1117 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' ) 1119 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1120 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) 1122 8.3. Matching Rules for Subschema Attributes 1124 Servers which allow subschema entries to be modified by clients MUST 1125 support the following matching rule, as it is the equality matching 1126 rule for several of the subschema attributes. 1128 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' 1129 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) 1131 Implementors should note that the assertion syntax of this matching 1132 rule, an OID, is different from the value syntax of attributes for 1133 which this is the equality matching rule. 1135 9. Security Considerations 1137 9.1. Disclosure 1139 Attributes of directory entries are used to provide descriptive 1140 information about the real-world objects they represent, which can 1141 be people, organizations or devices. Most countries have privacy 1142 laws regarding the publication of information about people. 1144 9.2. Use of Attribute Values in Security Applications 1146 The transformations of an AttributeValue value from its X.501 form to 1147 an LDAP string representation are not always reversible back to the 1148 same BER or DER form. An example of a situation which requires the 1149 DER form of a distinguished name is the verification of an X.509 1150 certificate. 1152 For example, a distinguished name consisting of one RDN with one AVA, 1153 in which the type is commonName and the value is of the TeletexString 1154 choice with the letters 'Sam' would be represented in LDAP as the 1155 string CN=Sam. Another distinguished name in which the value is 1156 still 'Sam' but of the PrintableString choice would have the same 1157 representation CN=Sam. 1159 Applications which require the reconstruction of the DER form of the 1160 value SHOULD NOT use the string representation of attribute syntaxes 1161 when converting a value to LDAP format. Instead it SHOULD use the 1162 Binary syntax. 1164 10. Acknowledgements 1166 This document is based substantially on RFC 1778, written by Tim 1167 Howes, Steve Kille, Wengyik Yeong and Colin Robbins. 1169 Many of the attribute syntax encodings defined in this and 1170 related documents are adapted from those used in the QUIPU and the 1171 IC R3 X.500 implementations. The contributions of the authors of both 1172 these implementations in the specification of syntaxes are gratefully 1173 acknowledged. 1175 11. Authors Addresses 1177 Mark Wahl 1178 Critical Angle Inc. 1179 4815 West Braker Lane #502-385 1180 Austin, TX 78759 1181 USA 1183 EMail: M.Wahl@critical-angle.com 1185 Andy Coulbeck 1186 Isode Limited 1187 The Dome, The Square 1188 Richmond TW9 1DT 1189 United Kingdom 1191 Phone: +44 181-332-9091 1192 EMail: A.Coulbeck@isode.com 1194 Tim Howes 1195 Netscape Communications Corp. 1196 501 E. Middlefield Rd 1197 Mountain View, CA 94043 1198 USA 1200 Phone: +1 415 254-1900 1201 EMail: howes@netscape.com 1202 Steve Kille 1203 Isode Limited 1204 The Dome, The Square 1205 Richmond 1206 TW9 1DT 1207 UK 1209 Phone: +44-181-332-9091 1210 EMail: S.Kille@isode.com 1212 12. Bibliography 1214 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 1215 Protocol (Version 3)", INTERNET-DRAFT 1216 , June 1997. 1218 [2] The Directory: Selected Attribute Types. ITU-T Recommendation 1219 X.520, 1993. 1221 [3] The Directory: Models. ITU-T Recommendation X.501, 1993. 1223 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1224 Levels", RFC 2119. 1226 [5] M. Wahl, S. Kille, "A UTF-8 String Representation of 1227 Distinguished Names", INTERNET-DRAFT 1228 , April 1997. 1230 [6] S. Kille, "A String Representation for Presentation Addresses", 1231 RFC 1278, University College London, November 1991. 1233 [7] Terminal Equipment and Protocols for Telematic Services - 1234 Standardization of Group 3 facsimile apparatus for document 1235 transmission. CCITT, Recommendation T.4. 1237 [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 1238 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 1240 [9] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 1241 10646", RFC 2044, October 1996. 1243 [10] Universal Multiple-Octet Coded Character Set (UCS) - 1244 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1245 1993 (With amendments). 1247 [11] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 1248 and RFC 822", RFC 1327, May 1992. 1250 [12] M. Wahl, "X.500(93) User Schema for use with LDAP", 1251 INTERNET-DRAFT , 1252 June 1997. 1254 [13] D. Crocker, "Standard of the Format of ARPA-Internet Text 1255 Messages", STD 11, RFC 822, August 1982. 1257 Expires: November 1997