idnits 2.17.1 draft-ietf-asid-ldapv3-attributes-06.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-03-28) 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 22 longer pages, the longest (page 3) being 60 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 15 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 (11 July 1997) is 9757 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 1254 looks like a reference -- Missing reference section? '4' on line 1263 looks like a reference -- Missing reference section? '3' on line 1261 looks like a reference -- Missing reference section? '13' on line 1294 looks like a reference -- Missing reference section? '9' on line 1280 looks like a reference -- Missing reference section? '12' on line 1290 looks like a reference -- Missing reference section? '5' on line 1266 looks like a reference -- Missing reference section? '10' on line 1283 looks like a reference -- Missing reference section? '7' on line 1273 looks like a reference -- Missing reference section? '8' on line 1277 looks like a reference -- Missing reference section? '11' on line 1287 looks like a reference -- Missing reference section? '6' on line 1270 looks like a reference -- Missing reference section? '2' on line 1258 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 Inc. 5 T. Howes 6 Netscape Communications Corp. 7 S. Kille 8 Isode Limited 9 Intended Category: Standards Track 11 July 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 Attribute Type and Object Class definitions are written in a 72 string representation of the AttributeTypeDescription and 73 ObjectClassDescription data types defined in X.501(93) [3]. 74 Implementors are strongly advised to first read the description 75 of how schema is represented in X.500 before reading the rest of 76 this document. 78 4.1. Common Encoding Aspects 80 For the purposes of defining the encoding rules for attribute 81 syntaxes, the following BNF definitions will be used. They are 82 based on the BNF styles of RFC 822 [13]. 84 a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / 85 "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / 86 "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / 87 "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / 88 "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / 89 "T" / "U" / "V" / "W" / "X" / "Y" / "Z" 91 d = "0" / "1" / "2" / "3" / "4" / 92 "5" / "6" / "7" / "8" / "9" 94 hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" / 95 "A" / "B" / "C" / "D" / "E" / "F" 97 k = a / d / "-" 99 p = a / d / """ / "(" / ")" / "+" / "," / 100 "-" / "." / "/" / ":" / "?" / " " 102 letterstring = 1*a 104 numericstring = 1*d 106 anhstring = 1*k 108 keystring = a [ anhstring ] 110 printablestring = 1*p 111 space = 1*" " 113 whsp = [ space ] 115 utf8 = 118 dstring = 1*utf8 120 qdstring = whsp "'" dstring "'" whsp 122 qdstringlist = ( qdstringlist qdstring ) / "" 124 qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp ) 126 In the following BNF for the string representation of OBJECT 127 IDENTIFIERs, descr is the syntactic representation of an object 128 descriptor, which consists of letters and digits, starting with a 129 letter. An OBJECT IDENTIFIER in the numericoid format should not 130 have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should 131 not be generated). 133 When encoding values in syntax, the descr encoding option SHOULD 134 be used in preference to the numericoid. An object descriptor is 135 a more readable alias for a number OBJECT IDENTIFIER, and these 136 (where assigned and known by the implementation) SHOULD be used in 137 preference to numeric oids to the greatest extent possible. 138 Examples of object descriptors in LDAP are attribute type, object 139 class and matching rule names. 141 oid = descr / numericoid 143 descr = keystring 145 numericoid = numericstring *( "." numericstring ) 147 woid = whsp oid whsp 149 ; set of oids of either form 150 oids = woid / ( "(" oidlist ")" ) 152 oidlist = woid *( "$" woid ) 154 ; object descriptors used as schema element names 155 qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) 157 qdescrlist = ( qdescrlist qdescr ) / "" 159 qdescr = whsp "'" descr "'" whsp 161 4.2. Attribute Types 163 The attribute types are described by sample values for the subschema 164 "attributeTypes" attribute, which is written in the 165 AttributeTypeDescription syntax. While lines have been folded for 166 readability, the values transferred in protocol would not contain 167 newlines. 169 The AttributeTypeDescription is encoded according to the following 170 BNF, and the productions for oid, qdsescrs and qdstring are given 171 in section 4.1. Implementors should note that future versions of this 172 document may have expanded this BNF to include additional terms. 174 AttributeTypeDescription = "(" whsp 175 numericoid whsp ; AttributeType identifier 176 [ "NAME" qdescrs ] ; name used in AttributeType 177 [ "DESC" qdstring ] ; description 178 [ "OBSOLETE" whsp ] 179 [ "SUP" woid ] ; derived from this other 180 ; AttributeType 181 [ "EQUALITY" woid ; Matching Rule name 182 [ "ORDERING" woid ; Matching Rule name 183 [ "SUBSTR" woid ] ; Matching Rule name 184 [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 185 [ "SINGLE-VALUE" whsp ] ; default multi-valued 186 [ "COLLECTIVE" whsp ] ; default not collective 187 [ "NO-USER-MODIFICATION" whsp ]; default user modifiable 188 [ "USAGE" whsp AttributeUsage ]; default user applications 189 whsp ")" 191 AttributeUsage = 192 "userApplications" / 193 "directoryOperation" / 194 "distributedOperation" / ; DSA-shared 195 "dSAOperation" ; DSA-specific, value depends on server 197 Servers are not required to provide the same or any text 198 in the description part of the subschema values they maintain. 199 Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields 200 for each AttributeTypeDescription. 202 Servers SHOULD implement all the attribute types referenced in 203 section 5. Servers MUST be able to evaluate presence filters, 204 SHOULD be able to perform equality matching of values of all user 205 attributes known to the server, and MAY be able to perform matching 206 with the other kinds of filters. If a server allows values of an 207 attribute of a particular type to be added or removed over protocol, 208 the server MUST be able to perform equality matching of values of 209 that attribute, but need not perform any additional validity checks 210 on attribute values. 212 Servers MAY recognize additional names and attributes not listed in 213 this document, and if they do so, MUST publish the definitions of 214 the types in the attributeTypes attribute of their subschema 215 entries. 217 Schema developers MUST NOT create attribute definitions whose names 218 conflict with attributes defined for use with LDAP in existing 219 standards-track RFCs. 221 AttributeDescriptions can be used as the value in a NAME part of an 222 AttributeTypeDescription. Note that these are case insensitive. 224 Note that the AttributeTypeDescription does not list the matching 225 rules which can can be used with that attribute type in an 226 extensibleMatch search filter. This is done using the matchingRuleUse 227 attribute described in section 4.5. 229 This document refines the schema description of X.501 by requiring 230 that the syntax field in an AttributeTypeDescription be a string 231 representation of an OBJECT IDENTIFIER for the LDAP string syntax 232 definition, and an optional indication of the maximum length of 233 a value of this attribute. 235 4.3. Syntaxes 237 This section defines general requirements for LDAP attribute value 238 syntax encodings. All documents defining attribute syntax encodings 239 for use with LDAP are expected to conform to these requirements. 241 The encoding rules defined for a given attribute syntax must produce 242 octet strings. To the greatest extent possible, encoded octet 243 strings should be usable in their native encoded form for display 244 purposes. In particular, encoding rules for attribute syntaxes 245 defining non-binary values should produce strings that can be 246 displayed with little or no translation by clients implementing 247 LDAP. There are a few cases (e.g. audio) however, when it is not 248 sensible to produce a printable representation, and clients MUST NOT 249 assume that an unrecognized syntax is a string representation. 251 In encodings where an arbitrary string is used as part of a larger 252 production (other than a Distinguished Name), a backslash quoting 253 mechanism is used to encode the following separator symbol character 254 (such as "'", "$" or "#") if it should occur in that string. The 255 backslash is followed by a pair of hexadecimal digits representing the 256 next character. A backslash itself in the string which forms part of 257 a larger syntax is always transmitted as '\5C' or '\5c'. 259 Syntaxes are also defined for matching rules whose assertion value 260 syntax is different from the attribute value syntax. 262 4.3.1 Binary Transfer of Values 264 This encoding format is used if the binary encoding is requested by 265 the client for an attribute, or if the attribute syntax name is 266 "1.3.6.1.4.1.1466.115.121.1.5". The value, an instance of the ASN.1 267 AttributeValue type, is BER-encoded, subject to the restrictions of 268 section 5.1 of [1], and this sequence of octets is used as the value. 269 (E.g. the first byte inside the OCTET STRING wrapper is a tag byte. 270 However the OCTET STRING is still encoded in primitive form.) 271 All servers MUST implement this form for both generating attribute 272 values in search responses, and parsing attribute values in add, 273 compare and modify requests, if the attribute type is recognized and 274 the attribute syntax name is that of Binary. Clients which request 275 that all attributes be returned from entries MUST be prepared 276 to receive values in binary (e.g. userCertificate), and SHOULD NOT 277 simply display binary or unrecognized values to users. 279 4.3.2. Syntax Object Identifiers 281 Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which 282 are dotted-decimal strings. These are not intended to be displayed 283 to users. 285 noidlen = numericoid [ "{" len "}" ] 287 len = numericstring 289 The following table lists some of the syntaxes that have been defined 290 for LDAP thus far. The H-R column suggests whether a value in that 291 syntax would likely be a human readable string. Clients and servers 292 need not implement all the syntaxes listed here, and MAY implement 293 other syntaxes. 295 Other documents may define additional syntaxes. However, the 296 definition of additional arbitrary syntaxes is strongly depreciated 297 since it will hinder interoperability: today's client and server 298 implementations generally do not have the ability to dynamically 299 recognize new syntaxes. In most cases attributes will be defined 300 with the syntax for directory strings. 302 Value being represented H-R OBJECT IDENTIFIER 303 ================================================================= 304 ACI Item N 1.3.6.1.4.1.1466.115.121.1.1 305 Access Point Y 1.3.6.1.4.1.1466.115.121.1.2 306 Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3 307 Audio N 1.3.6.1.4.1.1466.115.121.1.4 308 Binary N 1.3.6.1.4.1.1466.115.121.1.5 309 Bit String Y 1.3.6.1.4.1.1466.115.121.1.6 310 Boolean Y 1.3.6.1.4.1.1466.115.121.1.7 311 Certificate N 1.3.6.1.4.1.1466.115.121.1.8 312 Certificate List N 1.3.6.1.4.1.1466.115.121.1.9 313 Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10 314 Country String Y 1.3.6.1.4.1.1466.115.121.1.11 315 DN Y 1.3.6.1.4.1.1466.115.121.1.12 316 Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13 317 Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14 318 Directory String Y 1.3.6.1.4.1.1466.115.121.1.15 319 DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16 320 DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17 321 DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18 322 DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19 323 DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20 324 Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21 325 Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22 326 Fax N 1.3.6.1.4.1.1466.115.121.1.23 327 Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24 328 Guide Y 1.3.6.1.4.1.1466.115.121.1.25 329 IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26 330 INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27 331 JPEG N 1.3.6.1.4.1.1466.115.121.1.28 332 LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54 333 Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29 334 Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30 335 Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31 336 Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32 337 MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33 338 Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55 339 Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34 340 Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35 341 Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36 342 Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37 343 OID Y 1.3.6.1.4.1.1466.115.121.1.38 344 Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39 345 Password Y 1.3.6.1.4.1.1466.115.121.1.40 346 Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41 347 Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 348 Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43 349 Printable String Y 1.3.6.1.4.1.1466.115.121.1.44 350 Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45 351 Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46 352 Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47 353 Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48 354 Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49 355 Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50 356 Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51 357 Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52 358 UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53 360 A suggested minimum upper bound on the number of characters in value 361 with a string-based syntax, or the number of bytes in a value for all 362 other syntaxes, may be indicated by appending this bound count inside 363 of curly braces following the syntax name's OBJECT IDENTIFIER in an 364 Attribute Type Description. This bound is not part of the syntax name 365 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server 366 implementations should allow a string to be 64 characters long, 367 although they may allow longer strings. Note that a single character 368 of the Directory String syntax may be encoded in more than one byte 369 since UTF-8 is a variable-length encoding. 371 4.3.3. Syntax Description 373 The following BNF may be used to associate a short description with 374 a syntax OBJECT IDENTIFIER. Implementors should note that future 375 versions of this document may expand this definition to include 376 additional terms. 378 SyntaxDescription = "(" whsp 379 numericoid whsp 380 [ "DESC" qdstring ] 381 whsp ")" 383 4.4. Object Classes 385 The format for representation of object classes is defined in X.501 386 [3]. In general every entry will contain an abstract class ("top" or 387 "alias"), at least one structural object class, and zero or more 388 auxiliary object classes. Whether an object class is abstract, 389 structural or auxiliary is defined when the object class identifier 390 is assigned. An object class definition should not be changed 391 without having a new identifier assigned to it. 393 Object class descriptions are written according to the following BNF. 394 Implementors should note that future versions of this document may 395 expand this definition to include additional terms. 397 ObjectClassDescription = "(" whsp 398 numericoid whsp ; ObjectClass identifier 399 [ "NAME" qdescrs ] 400 [ "DESC" qdstring ] 401 [ "OBSOLETE" whsp ] 402 [ "SUP" oids ] ; Superior ObjectClasses 403 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] 404 ; default structural 405 [ "MUST" oids ] ; AttributeTypes 406 [ "MAY" oids ] ; AttributeTypes 407 whsp ")" 409 These are described as sample values for the subschema 410 "objectClasses" attribute for a server which implements the LDAP 411 schema. While lines have been folded for readability, the values 412 transferred in protocol would not contain newlines. 414 Servers SHOULD implement all the object classes referenced in 415 section 7, except for extensibleObject, which is optional. 417 Servers MAY implement additional object classes not listed in this 418 document, and if they do so, MUST publish the definitions of the 419 classes in the objectClasses attribute of their subschema entries. 420 Later documents may define additional object classes. 422 Schema developers MUST NOT create object class definitions whose 423 names conflict with attributes defined for use with LDAP in existing 424 standards-track RFCs. 426 4.5. Matching Rules 428 Matching rules are used by servers to compare attribute values 429 against assertion values when performing Search and Compare 430 operations. They are also used to identify the value to be added 431 or deleted when modifying entries, and are used when comparing a 432 purported distinguished name with the name of an entry. 434 Most of the attributes given in this document will have an equality 435 matching rule defined. 437 Matching rule descriptions are written according to the following 438 BNF. Implementors should note that future versions of this document 439 may have expanded this BNF to include additional terms. 441 MatchingRuleDescription = "(" whsp 442 numericoid whsp ; MatchingRule identifier 443 [ "NAME" qdescrs ] 444 [ "DESC" qdstring ] 445 [ "OBSOLETE" whsp ] 446 "SYNTAX" numericoid 447 whsp ")" 449 Values of the matchingRuleUse list the attributes which are suitable 450 for use with an extensible matching rule. 452 MatchingRuleUseDescription = "(" whsp 453 numericoid whsp ; MatchingRule identifier 454 [ "NAME" qdescrs ] 455 [ "DESC" qdstring ] 456 [ "OBSOLETE" ] 457 "APPLIES" oids ; AttributeType identifiers 458 whsp ")" 460 Servers which support matching rules and the extensibleMatch SHOULD 461 implement all the matching rules in section 8. 463 Servers MAY implement additional matching rules not listed in this 464 document, and if they do so, MUST publish the definitions of the 465 matching rules in the matchingRules attribute of their 466 subschema entries. If the server supports the extensibleMatch, then 467 the server MUST publish the relationship between the matching rules 468 and attributes in the matchingRuleUse attribute. 470 For example, a server which implements a privately-defined matching 471 rule for performing sound-alike matches on Directory String-valued 472 attributes would include the following in the subschema entry 473 (1.2.3.4.5 is an example, the OID of an actual matching rule would be 474 different): 476 matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' 477 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) 479 If this matching rule could be used with the attributes 2.5.4.41 and 480 2.5.4.15, the following would also be present: 482 matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) ) 484 A client could then make use of this matching rule by sending a 485 search operation in which the filter is of the extensibleMatch choice, 486 the matchingRule field is "soundAlikeMatch", and the type field is 487 "2.5.4.41" of "2.5.4.15". 489 5. Attribute Types 491 All LDAP server implementations MUST recognize the attribute types 492 defined in this section. These types are based on definitions in 493 X.501(93) [3]. 495 Servers SHOULD also recognize all the attributes from section 5 of 496 [12]. 498 5.1. Standard Operational Attributes 500 Servers MUST maintain values of these attributes in accordance with 501 the definitions in X.501(93). 503 5.1.1. createTimestamp 505 This attribute SHOULD appear in entries which were created using 506 the Add operation. 508 ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch 509 ORDERING generalizedTimeOrderingMatch 510 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' 511 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 513 5.1.2. modifyTimestamp 515 This attribute SHOULD appear in entries which have been modified 516 using the Modify operation. 518 ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch 519 ORDERING generalizedTimeOrderingMatch 520 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' 521 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 523 5.1.3. creatorsName 525 This attribute SHOULD appear in entries which were created using 526 the Add operation. 528 ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch 529 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' 530 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 532 5.1.4. modifiersName 534 This attribute SHOULD appear in entries which have been modified 535 using the Modify operation. 537 ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch 538 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' 539 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 541 5.1.5. subschemaSubentry 543 The value of this attribute is the name of a subschema entry (or 544 subentry if the server is based on X.500(93)) in which the server 545 makes available attributes specifying the schema. 547 ( 2.5.18.10 NAME 'subschemaSubentry' 548 EQUALITY distinguishedNameMatch 549 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' NO-USER-MODIFICATION 550 SINGLE-VALUE USAGE directoryOperation ) 552 5.1.6. attributeTypes 554 This attribute is typically located in the subschema entry. 556 ( 2.5.21.5 NAME 'attributeTypes' 557 EQUALITY objectIdentifierFirstComponentMatch 558 SYNTAX '1.3.6.1.4.1.1466.115.121.1.3' USAGE directoryOperation ) 560 5.1.7. objectClasses 562 This attribute is typically located in the subschema entry. 564 ( 2.5.21.6 NAME 'objectClasses' 565 EQUALITY objectIdentifierFirstComponentMatch 566 SYNTAX '1.3.6.1.4.1.1466.115.121.1.37' USAGE directoryOperation ) 568 5.1.8. matchingRules 570 This attribute is typically located in the subschema entry. 572 ( 2.5.21.4 NAME 'matchingRules' 573 EQUALITY objectIdentifierFirstComponentMatch 574 SYNTAX '1.3.6.1.4.1.1466.115.121.1.30' USAGE directoryOperation ) 576 5.1.9. matchingRuleUse 578 This attribute is typically located in the subschema entry. 580 ( 2.5.21.8 NAME 'matchingRuleUse' 581 EQUALITY objectIdentifierFirstComponentMatch 582 SYNTAX '1.3.6.1.4.1.1466.115.121.1.31' USAGE directoryOperation ) 584 5.2. LDAP Operational Attributes 586 These attributes are only present in the root DSE (see [1] and [3]). 588 Servers MUST recognize these attribute names, but it is not required 589 that a server provide values for these attributes, when the 590 attribute corresponds to a feature which the server does not 591 implement. 593 5.2.1. namingContexts 595 The values of this attribute correspond to naming contexts which this 596 server masters or shadows. If the server does not master any 597 information (e.g. it is an LDAP gateway to a public X.500 directory) 598 this attribute will be absent. If the server believes it contains 599 the entire directory, the attribute will have a single value, and 600 that value will be the empty string (indicating the null DN of the 601 root). This attribute will allow a client to choose suitable base 602 objects for searching when it has contacted a server. 604 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 605 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' USAGE dSAOperation ) 607 5.2.2. altServer 609 The values of this attribute are URLs of other servers which may be 610 contacted when this server becomes unavailable. If the server does 611 not know of any other servers which could be used this attribute 612 will be absent. Clients may cache this information in case their 613 preferred LDAP server later becomes unavailable. 615 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 616 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' USAGE dSAOperation ) 618 5.2.3. supportedExtension 620 The values of this attribute are OBJECT IDENTIFIERs identifying the 621 supported extended operations which the server supports. 623 If the server does not support any extensions this attribute will be 624 absent. 626 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 627 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' USAGE dSAOperation ) 629 5.2.4. supportedControl 631 The values of this attribute are the OBJECT IDENTIFIERS identifying 632 controls which the server supports. If the server does not 633 support any controls, this attribute will be absent. 635 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 636 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' USAGE dSAOperation ) 638 5.2.5. supportedSASLMechanisms 640 The values of this attribute are the names of supported SASL 641 mechanisms which the server supports. If the server does not 642 support any mechanisms this attribute will be absent. 644 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 645 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' USAGE dSAOperation ) 647 5.2.6. supportedLDAPVersion 649 The values of this attribute are the versions of the LDAP protocol 650 which the server implements. 652 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 653 SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' USAGE dSAOperation ) 655 5.3. LDAP Subschema Attribute 657 This attribute is typically located in the subschema entry. 659 5.3.1. ldapSyntaxes 661 Servers MAY use this attribute to list the syntaxes which are 662 implemented. Each value corresponds to one syntax. 664 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 665 EQUALITY objectIdentifierFirstComponentMatch 666 SYNTAX '1.3.6.1.4.1.1466.115.121.1.54' USAGE directoryOperation ) 668 6. Syntaxes 670 Servers SHOULD recognize all the syntaxes described in this section. 671 Each syntax begins with a sample value of the ldapSyntaxes attribute 672 which defines the OBJECT IDENTIFIER of the syntax. The descriptions 673 of syntax names are not carried in protocol, and are not guaranteed 674 to be unique. 676 6.1. Attribute Type Description 678 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 680 Values in this syntax are encoded according to the BNF given at the 681 start of section 4.2. For example, 683 ( 2.5.4.0 NAME 'objectClass' 684 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) 686 6.2. Binary 688 ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) 690 Values in this syntax are encoded as described in section 4.3.1. 692 6.3. Bit String 694 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 696 Values in this syntax are encoded according to the following BNF: 698 bitstring = "'" *binary-digit "'B" 700 binary-digit = "0" / "1" 702 Example: 704 '0101111101'B 706 6.4. Boolean 708 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 710 Values in this syntax are encoded according to the following BNF: 712 boolean = "TRUE" / "FALSE" 714 Boolean values have an encoding of "TRUE" if they are logically true, 715 and have an encoding of "FALSE" otherwise. 717 6.5. Certificate 719 ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) 721 Because of the changes from X.509(1988) and X.509(1993) and 722 additional changes to the ASN.1 definition to support certificate 723 extensions, no string representation is defined, and values in 724 this syntax MUST only be transferred using the binary encoding, by 725 requesting or returning the attributes with descriptions 726 "userCertificate;binary" or "caCertificate;binary". The BNF notation 727 in RFC 1778 for "User Certificate" is not recommended to be used. 729 6.6. Certificate List 731 ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) 733 Because of the incompatibility of the X.509(1988) and X.509(1993) 734 definitions of revocation lists, values in this syntax MUST only be 735 transferred using a binary encoding, by requesting or returning the 736 attributes with descriptions "certificateRevocationList;binary" or 737 "authorityRevocationList;binary". The BNF notation in RFC 1778 for 738 "Authority Revocation List" is not recommended to be used. 740 6.7. Certificate Pair 742 ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) 744 Because the Certificate is being carried in binary, values in this 745 syntax MUST only be transferred using a binary encoding, by requesting 746 or returning the attribute description "crossCertificatePair;binary". 747 The BNF notation in RFC 1778 for "Certificate Pair" is not 748 recommended to be used. 750 6.8. Country String 752 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 754 A value in this syntax is encoded the same as a value of 755 Directory String syntax. Note that this syntax is limited to values 756 of exactly two printable string characters. 758 CountryString = p p 760 Example: 761 US 763 6.9. DN 765 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 767 Values in the Distinguished Name syntax are encoded to have the 768 representation defined in [5]. Note that this representation is not 769 reversible to an ASN.1 encoding used in X.500 for Distinguished 770 Names, as the CHOICE of any DirectoryString element in an RDN is no 771 longer known. 773 Examples (from [5]): 774 CN=Steve Kille,O=Isode Limited,C=GB 775 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 776 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 777 CN=Before\0DAfter,O=Test,C=GB 778 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 779 SN=Lu\C4\8Di\C4\87 781 6.10. Directory String 783 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 785 A string in this syntax is encoded in the UTF-8 form of ISO 10646 786 (a superset of Unicode). Servers and clients MUST be prepared to 787 receive encodings of arbitrary Unicode characters, including 788 characters not presently assigned to any character set. 790 For characters in the PrintableString form, the value is encoded as 791 the string value itself. 793 If it is of the TeletexString form, then the characters are 794 transliterated to their equivalents in UniversalString, and encoded 795 in UTF-8 [9]. 797 If it is of the UniversalString or BMPString forms [10], UTF-8 is 798 used to encode them. 800 Note: the form of DirectoryString is not indicated in protocol 801 unless the attribute value is carried in binary. Servers which 802 convert to DAP MUST choose an appropriate form. Servers MUST NOT 803 reject values merely because they contain legal Unicode characters 804 outside of the range of printable ASCII. 806 Example: 808 This is a string of DirectoryString containing #!%#@ 810 6.11. DIT Content Rule Description 812 ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' ) 814 Values in this syntax are encoded according to the following BNF. 815 Implementors should note that future versions of this document 816 may have expanded this BNF to include additional terms. 818 DITContentRuleDescription = "(" 819 numericoid ; Structural ObjectClass identifier 820 [ "NAME" qdescrs ] 821 [ "DESC" qdstring ] 822 [ "OBSOLETE" ] 823 [ "AUX" oids ] ; Auxiliary ObjectClasses 824 [ "MUST" oids ] ; AttributeType identifiers 825 [ "MAY" oids ] ; AttributeType identifiers 826 [ "NOT" oids ] ; AttributeType identifiers 827 ")" 829 6.12. Facsimile Telephone Number 831 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) 833 Values in this syntax are encoded according to the following BNF: 835 fax-number = printablestring [ "$" faxparameters ] 837 faxparameters = faxparm / ( faxparm "$" faxparameters ) 839 faxparm = "twoDimensional" / "fineResolution" / 840 "unlimitedLength" / 841 "b4Length" / "a3Width" / "b4Width" / "uncompressed" 843 In the above, the first printablestring is the actual fax number, 844 and the faxparm tokens represent fax parameters. 846 6.13. Fax 848 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 850 Values in this syntax are encoded as if they were octet strings 851 containing Group 3 Fax images as defined in [7]. 853 6.14. Generalized Time 855 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 857 Values in this syntax are encoded as printable strings, represented 858 as specified in X.208. Note that the time zone must be specified. 859 It is strongly recommended that GMT time be used. For example, 861 199412161032Z 863 6.15. IA5 String 865 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 867 The encoding of a value in this syntax is the string value itself. 869 6.16. INTEGER 871 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 873 Values in this syntax are encoded as the decimal representation 874 of their values, with each decimal digit represented by the its 875 character equivalent. So the number 1321 is represented by the 876 character string "1321". 878 6.17. JPEG 880 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 882 Values in this syntax are encoded as strings containing JPEG images in 883 the JPEG File Interchange Format (JFIF), as described in [8]. 885 6.18. Matching Rule Description 887 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 889 Values of type matchingRules are encoded as strings according to 890 the BNF given in section 4.5. 892 6.19. Matching Rule Use Description 894 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' ) 896 Values of type matchingRuleUse are encoded as strings according to 897 the BNF given in section 4.5. 899 6.20. MHS OR Address 901 ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) 903 Values in this syntax are encoded as strings, according to the format 904 defined in [11]. 906 6.21. Name And Optional UID 908 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 910 Values in this syntax are encoded according to the following BNF: 912 NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 914 Although the '#' character may occur in a string representation of a 915 distinguished name, no additional special quoting is done. 917 This syntax has been added subsequent to RFC 1778. 919 Example: 921 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 923 6.22. Name Form Description 925 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 927 Values in this syntax are encoded according to the following BNF. 928 Implementors should note that future versions of this document 929 may have expanded this BNF to include additional terms. 931 NameFormDescription = "(" whsp 932 numericoid whsp ; NameForm identifier 933 [ "NAME" qdescrs ] 934 [ "DESC" qdstring ] 935 [ "OBSOLETE" whsp ] 936 "OC" woid ; Structural ObjectClass 937 "MUST" oids ; AttributeTypes 938 [ "MAY" oids ] ; AttributeTypes 939 whsp ")" 941 6.23. Numeric String 943 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 945 The encoding of a string in this syntax is the string value itself. 946 Example: 948 1997 950 6.24. Object Class Description 952 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 954 Values in this syntax are encoded according to the BNF in section 4.4. 956 6.25. OID 958 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 960 Values in the Object Identifier syntax are encoded according to 961 the BNF in section 4.1 for "oid". 963 Example: 965 1.2.3.4 966 cn 968 6.26. Other Mailbox 970 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 972 Values in this syntax are encoded according to the following BNF: 974 otherMailbox = mailbox-type "$" mailbox 976 mailbox-type = printablestring 978 mailbox = 980 In the above, mailbox-type represents the type of mail system in 981 which the mailbox resides, for example "MCIMail"; and mailbox is 982 the actual mailbox in the mail system defined by mailbox-type. 984 6.27. Postal Address 986 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 988 Values in this syntax are encoded according to the following BNF: 990 postal-address = dstring *( "$" dstring ) 992 In the above, each dstring component of a postal address value is 993 encoded as a value of type Directory String syntax. Backslashes and 994 dollar characters, if they occur in the component, are quoted as 995 described in section 4. 997 Example: 999 1234 Main St.$Anytown, CA 12345$USA 1000 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 1002 6.28. Presentation Address 1004 ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) 1006 Values in this syntax are encoded with the representation described 1007 in RFC 1278 [6]. 1009 6.29. Printable String 1011 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1013 The encoding of a value in this syntax is the string value itself. 1014 PrintableString is limited to the characters in production p of 1015 section 4.1. 1017 Example: 1019 This is a PrintableString 1021 6.30. Telephone Number 1023 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1025 Values in this syntax are encoded as if they were Printable String 1026 types. Telephone numbers are recommended in X.520 to be in 1027 international form. 1029 Example: 1031 +1 512 305 0280 1033 6.31. UTC Time 1035 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1037 Values in this syntax are encoded as if they were printable 1038 strings with the strings containing a UTCTime value. This is 1039 historical; new attribute definitions SHOULD use GeneralizedTime 1040 instead. 1042 6.32. LDAP Syntax Description 1044 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 1046 Values in this syntax are encoded according to the BNF in section 1047 4.3.3. 1049 7. Object Classes 1051 Servers SHOULD recognize all the names of standard classes from 1052 section 7 of [12]. 1054 7.1. Extensible Object Class 1056 The extensibleObject object class, if present in an entry, permits 1057 that entry to optionally hold any attribute. The MAY attribute list 1058 of this class is implicitly the set of all attributes. 1060 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 1061 SUP top AUXILIARY ) 1063 The mandatory attributes of the other object classes of this entry 1064 are still required to be present. 1066 Note that not all servers will implement this object class, and those 1067 which do not will reject requests to add entries which contain this 1068 object class, or modify an entry to add this object class. 1070 8. Matching Rules 1072 Servers which implement the extensibleMatch filter SHOULD allow 1073 all the matching rules listed in this section to be used in the 1074 extensibleMatch. In general these servers SHOULD allow matching 1075 rules to be used with all attribute types known to the server, when 1076 the assertion syntax of the matching rule is the same as the value 1077 syntax of the attribute. 1079 Servers MAY implement additional matching rules. 1081 8.1. Matching Rules used in Equality Filters 1083 Servers SHOULD be capable of performing the following matching rules. 1085 For all these rules, the assertion syntax is the same as the value 1086 syntax. 1088 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1089 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) 1091 If the client supplies a filter using an objectIdentifierMatch whose 1092 matchValue oid is in the "descr" form, and the oid is not recognized 1093 by the server, then the filter is Undefined. 1095 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1096 SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) 1098 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1099 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) 1101 ( 2.5.13.8 NAME 'numericStringMatch' 1102 SYNTAX '1.3.6.1.4.1.1466.115.121.1.36' ) 1104 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1105 SYNTAX '1.3.6.1.4.1.1466.115.121.1.41' ) 1107 ( 2.5.13.14 NAME 'integerMatch' 1108 SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' ) 1110 ( 2.5.13.16 NAME 'bitStringMatch' 1111 SYNTAX '1.3.6.1.4.1.1466.115.121.1.6' ) 1113 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1114 SYNTAX '1.3.6.1.4.1.1466.115.121.1.50' ) 1116 ( 2.5.13.22 NAME 'presentationAddressMatch' 1117 SYNTAX '1.3.6.1.4.1.1466.115.121.1.43' ) 1119 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1120 SYNTAX '1.3.6.1.4.1.1466.115.121.1.34' ) 1122 ( 2.5.13.24 NAME 'protocolInformationMatch' 1123 SYNTAX '1.3.6.1.4.1.1466.115.121.1.42' ) 1125 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1126 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' ) 1128 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1129 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' ) 1131 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1132 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' ) 1134 When performing the caseIgnoreMatch, caseIgnoreListMatch, 1135 telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, 1136 multiple adjoining whitespace characters are treated the same as an 1137 individual space, and leading and trailing whitespace is ignored. 1139 Clients MUST NOT assume that servers are capable of transliteration 1140 of Unicode values. 1142 8.2. Matching Rules used in Inequality Filters 1144 Servers SHOULD be capable of performing the following matching rules, 1145 which are used in greaterOrEqual and lessOrEqual filters. 1147 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1148 SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' ) 1150 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1151 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) 1153 The sort ordering for a caseIgnoreOrderingMatch is 1154 implementation-dependent. 1156 8.3. Matching Rules for Subschema Attributes 1158 Servers which allow subschema entries to be modified by clients MUST 1159 support the following matching rule, as it is the equality matching 1160 rule for several of the subschema attributes. 1162 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' 1163 SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) 1165 Implementors should note that the assertion syntax of this matching 1166 rule, an OID, is different from the value syntax of attributes for 1167 which this is the equality matching rule. 1169 If the client supplies a filter using an 1170 objectIdentifierFirstComponentMatch whose matchValue oid is in the 1171 "descr" form, and the oid is not recognized by the server, then the 1172 filter is Undefined. 1174 9. Security Considerations 1176 9.1. Disclosure 1178 Attributes of directory entries are used to provide descriptive 1179 information about the real-world objects they represent, which can 1180 be people, organizations or devices. Most countries have privacy 1181 laws regarding the publication of information about people. 1183 9.2. Use of Attribute Values in Security Applications 1185 The transformations of an AttributeValue value from its X.501 form to 1186 an LDAP string representation are not always reversible back to the 1187 same BER or DER form. An example of a situation which requires the 1188 DER form of a distinguished name is the verification of an X.509 1189 certificate. 1191 For example, a distinguished name consisting of one RDN with one AVA, 1192 in which the type is commonName and the value is of the TeletexString 1193 choice with the letters 'Sam' would be represented in LDAP as the 1194 string CN=Sam. Another distinguished name in which the value is 1195 still 'Sam' but of the PrintableString choice would have the same 1196 representation CN=Sam. 1198 Applications which require the reconstruction of the DER form of the 1199 value SHOULD NOT use the string representation of attribute syntaxes 1200 when converting a value to LDAP format. Instead it SHOULD use the 1201 Binary syntax. 1203 10. Acknowledgements 1205 This document is based substantially on RFC 1778, written by Tim 1206 Howes, Steve Kille, Wengyik Yeong and Colin Robbins. 1208 Many of the attribute syntax encodings defined in this and 1209 related documents are adapted from those used in the QUIPU and the 1210 IC R3 X.500 implementations. The contributions of the authors of both 1211 these implementations in the specification of syntaxes are gratefully 1212 acknowledged. 1214 11. Authors Addresses 1216 Mark Wahl 1217 Critical Angle Inc. 1218 4815 West Braker Lane #502-385 1219 Austin, TX 78759 1220 USA 1222 Phone: +1 512 372-3160 1223 EMail: M.Wahl@critical-angle.com 1224 Andy Coulbeck 1225 Isode Inc. 1226 3925 West Braker Lane #333 1227 Austin, TX 78759 1228 USA 1230 Phone: +1 512 305-0280 1231 EMail: A.Coulbeck@isode.com 1233 Tim Howes 1234 Netscape Communications Corp. 1235 501 E. Middlefield Rd 1236 Mountain View, CA 94043 1237 USA 1239 Phone: +1 415 254-1900 1240 EMail: howes@netscape.com 1242 Steve Kille 1243 Isode Limited 1244 The Dome, The Square 1245 Richmond 1246 TW9 1DT 1247 UK 1249 Phone: +44-181-332-9091 1250 EMail: S.Kille@isode.com 1252 12. Bibliography 1254 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 1255 Protocol (Version 3)", INTERNET-DRAFT 1256 , July 1997. 1258 [2] The Directory: Selected Attribute Types. ITU-T Recommendation 1259 X.520, 1993. 1261 [3] The Directory: Models. ITU-T Recommendation X.501, 1993. 1263 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1264 Levels", RFC 2119. 1266 [5] M. Wahl, S. Kille, "A UTF-8 String Representation of 1267 Distinguished Names", INTERNET-DRAFT 1268 , April 1997. 1270 [6] S. Kille, "A String Representation for Presentation Addresses", 1271 RFC 1278, University College London, November 1991. 1273 [7] Terminal Equipment and Protocols for Telematic Services - 1274 Standardization of Group 3 facsimile apparatus for document 1275 transmission. CCITT, Recommendation T.4. 1277 [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 1278 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 1280 [9] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 1281 10646", RFC 2044, October 1996. 1283 [10] Universal Multiple-Octet Coded Character Set (UCS) - 1284 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1285 1993 (With amendments). 1287 [11] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 1288 and RFC 822", RFC 1327, May 1992. 1290 [12] M. Wahl, "X.500(96) User Schema for use with LDAP", 1291 INTERNET-DRAFT , 1292 July 1997. 1294 [13] D. Crocker, "Standard of the Format of ARPA-Internet Text 1295 Messages", STD 11, RFC 822, August 1982. 1297 Expires: December 1997