idnits 2.17.1 draft-zeilenga-ldapv3bis-rfc2252-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. 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.) ** The document seems to lack an Authors' Addresses Section. ** 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 36 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1481 has weird spacing: '...for the purpo...' -- 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 (4 July 2000) is 8696 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? 'RFC2252' on line 43 looks like a reference -- Missing reference section? '1' on line 1411 looks like a reference -- Missing reference section? '4' on line 1419 looks like a reference -- Missing reference section? '3' on line 1417 looks like a reference -- Missing reference section? '13' on line 1449 looks like a reference -- Missing reference section? '9' on line 1436 looks like a reference -- Missing reference section? '12' on line 1446 looks like a reference -- Missing reference section? '14' on line 1452 looks like a reference -- Missing reference section? '5' on line 1422 looks like a reference -- Missing reference section? '10' on line 1439 looks like a reference -- Missing reference section? '15' on line 1454 looks like a reference -- Missing reference section? '7' on line 1429 looks like a reference -- Missing reference section? '8' on line 1433 looks like a reference -- Missing reference section? '11' on line 1443 looks like a reference -- Missing reference section? '6' on line 1426 looks like a reference -- Missing reference section? '2' on line 1414 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires: 4 January 2001 4 July 2000 6 LDAPv3bis Suggestions: 7 Attribute Syntax Definitions 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of this 18 document will take place on the IETF LDAP Extension Working Group 19 mailing list . Please send editorial 20 comments directly to the author . 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 32 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 34 Copyright 2000, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Forward 41 This Internet Draft suggests a number of updates to "Lightweight 42 Directory Access Protocol (v3): Attribute Syntax Definitions" 43 [RFC2252]. This document is not intended to be published as an RFC 44 but used to identify LDAPv3bis work items. 46 The remainer of this documents incorporates the substantive portion of 47 RFC 2252 text (less status of memo, appendices, etc). Comments and 48 suggested updates to this text are inserted as inline notes prefixed 49 with '//'. 51 // Start of RFC 2252 text 53 2. Abstract 55 The Lightweight Directory Access Protocol (LDAP) [1] requires that the 56 contents of AttributeValue fields in protocol elements be octet 57 strings. This document defines a set of syntaxes for LDAPv3, and the 58 rules by which attribute values of these syntaxes are represented as 59 octet strings for transmission in the LDAP protocol. The syntaxes 60 defined in this document are referenced by this and other documents 61 that define attribute types. This document also defines the set of 62 attribute types which LDAP servers should support. 64 // RFC 2251 refers to mandatory attribute types in RFC 2252... 66 3. Overview 68 This document defines the framework for developing schemas for 69 directories accessible via the Lightweight Directory Access Protocol. 71 Schema is the collection of attribute type definitions, object class 72 definitions and other information which a server uses to determine how 73 to match a filter or attribute value assertion (in a compare 74 operation) against the attributes of an entry, and whether to permit 75 add and modify operations. 77 Section 4 states the general requirements and notations for attribute 78 types, object classes, syntax and matching rule definitions. 80 Section 5 lists attributes, section 6 syntaxes and section 7 object 81 classes. 83 Additional documents define schemas for representing real-world 84 objects as directory entries. 86 4. General Issues 88 This document describes encodings used in an Internet protocol. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [4]. 94 Attribute Type and Object Class definitions are written in a string 95 representation of the AttributeTypeDescription and 96 ObjectClassDescription data types defined in X.501(93) [3]. 97 Implementors are strongly advised to first read the description of how 98 schema is represented in X.500 before reading the rest of this 99 document. 101 4.1. Common Encoding Aspects 103 For the purposes of defining the encoding rules for attribute 104 syntaxes, the following BNF definitions will be used. They are based 105 on the BNF styles of RFC 822 [13]. 107 a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / 108 "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / 109 "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / 110 "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / 111 "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / 112 "T" / "U" / "V" / "W" / "X" / "Y" / "Z" 114 d = "0" / "1" / "2" / "3" / "4" / 115 "5" / "6" / "7" / "8" / "9" 117 hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" / 118 "A" / "B" / "C" / "D" / "E" / "F" 120 k = a / d / "-" / ";" 122 p = a / d / """ / "(" / ")" / "+" / "," / 123 "-" / "." / "/" / ":" / "?" / " " 125 letterstring = 1*a 127 numericstring = 1*d 129 anhstring = 1*k 131 keystring = a [ anhstring ] 133 printablestring = 1*p 135 space = 1*" " 137 whsp = [ space ] 139 utf8 = 142 dstring = 1*utf8 143 qdstring = whsp "'" dstring "'" whsp 145 qdstringlist = [ qdstring *( qdstring ) ] 147 qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp ) 149 In the following BNF for the string representation of OBJECT 150 IDENTIFIERs, descr is the syntactic representation of an object 151 descriptor, which consists of letters and digits, starting with a 152 letter. An OBJECT IDENTIFIER in the numericoid format should not have 153 leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should not be 154 generated). 156 // Suggest dot-decimal OID syntax (numericoid) specification 157 // (and other syntax used by the protocol) to moved RFC2251bis. 159 When encoding 'oid' elements in a value, the descr encoding option 160 SHOULD be used in preference to the numericoid. An object descriptor 161 is a more readable alias for a number OBJECT IDENTIFIER, and these 162 (where assigned and known by the implementation) SHOULD be used in 163 preference to numeric oids to the greatest extent possible. Examples 164 of object descriptors in LDAP are attribute type, object class and 165 matching rule names. 167 oid = descr / numericoid 169 descr = keystring 171 numericoid = numericstring *( "." numericstring ) 173 woid = whsp oid whsp 175 ; set of oids of either form 176 oids = woid / ( "(" oidlist ")" ) 178 oidlist = woid *( "$" woid ) 180 ; object descriptors used as schema element names 181 qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) 183 qdescrlist = [ qdescr *( qdescr ) ] 185 qdescr = whsp "'" descr "'" whsp 187 // Should note this syntax differs from that in RFC 1778. 189 4.2. Attribute Types 190 The attribute types are described by sample values for the subschema 191 "attributeTypes" attribute, which is written in the 192 AttributeTypeDescription syntax. While lines have been folded for 193 readability, the values transferred in protocol would not contain 194 newlines. 196 The AttributeTypeDescription is encoded according to the following 197 BNF, and the productions for oid, qdescrs and qdstring are given in 198 section 4.1. Implementors should note that future versions of this 199 document may have expanded this BNF to include additional terms. 200 Terms which begin with the characters "X-" are reserved for private 201 experiments, and MUST be followed by a . 203 AttributeTypeDescription = "(" whsp 204 numericoid whsp ; AttributeType identifier 205 [ "NAME" qdescrs ] ; name used in AttributeType 206 [ "DESC" qdstring ] ; description 207 [ "OBSOLETE" whsp ] 208 [ "SUP" woid ] ; derived from this other 209 ; AttributeType 210 [ "EQUALITY" woid ; Matching Rule name 211 [ "ORDERING" woid ; Matching Rule name 212 [ "SUBSTR" woid ] ; Matching Rule name 213 [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 214 [ "SINGLE-VALUE" whsp ] ; default multi-valued 215 [ "COLLECTIVE" whsp ] ; default not collective 216 [ "NO-USER-MODIFICATION" whsp ]; default user modifiable 217 [ "USAGE" whsp AttributeUsage ]; default userApplications 218 whsp ")" 220 AttributeUsage = 221 "userApplications" / 222 "directoryOperation" / 223 "distributedOperation" / ; DSA-shared 224 "dSAOperation" ; DSA-specific, value depends on server 226 Servers are not required to provide the same or any text in the 227 description part of the subschema values they maintain. Servers 228 SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each 229 AttributeTypeDescription. 231 Servers MUST implement all the attribute types referenced in sections 232 5.1, 5.2 and 5.3. 234 Servers MAY recognize additional names and attributes not listed in 235 this document, and if they do so, MUST publish the definitions of the 236 types in the attributeTypes attribute of their subschema entries. 238 Schema developers MUST NOT create attribute definitions whose names 239 conflict with attributes defined for use with LDAP in existing 240 standards-track RFCs. 242 An AttributeDescription can be used as the value in a NAME part of an 243 AttributeTypeDescription. Note that these are case insensitive. 245 Note that the AttributeTypeDescription does not list the matching 246 rules which can can be used with that attribute type in an 247 extensibleMatch search filter. This is done using the matchingRuleUse 248 attribute described in section 4.5. 250 This document refines the schema description of X.501 by requiring 251 that the syntax field in an AttributeTypeDescription be a string 252 representation of an OBJECT IDENTIFIER for the LDAP string syntax 253 definition, and an optional indication of the maximum length of a 254 value of this attribute (defined in section 4.3.2). 256 4.3. Syntaxes 258 This section defines general requirements for LDAP attribute value 259 syntax encodings. All documents defining attribute syntax encodings 260 for use with LDAP are expected to conform to these requirements. 262 The encoding rules defined for a given attribute syntax must produce 263 octet strings. To the greatest extent possible, encoded octet strings 264 should be usable in their native encoded form for display purposes. In 265 particular, encoding rules for attribute syntaxes defining non-binary 266 values should produce strings that can be displayed with little or no 267 translation by clients implementing LDAP. There are a few cases (e.g. 268 audio) however, when it is not sensible to produce a printable 269 representation, and clients MUST NOT assume that an unrecognized 270 syntax is a string representation. 272 In encodings where an arbitrary string, not a Distinguished Name, is 273 used as part of a larger production, and other than as part of a 274 Distinguished Name, a backslash quoting mechanism is used to escape 275 the following separator symbol character (such as "'", "$" or "#") if 276 it should occur in that string. The backslash is followed by a pair 277 of hexadecimal digits representing the next character. A backslash 278 itself in the string which forms part of a larger syntax is always 279 transmitted as '\5C' or '\5c'. An example is given in section 6.27. 281 Syntaxes are also defined for matching rules whose assertion value 282 syntax is different from the attribute value syntax. 284 4.3.1 Binary Transfer of Values 285 This encoding format is used if the binary encoding is requested by 286 the client for an attribute, or if the attribute syntax name is 287 "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP 288 AttributeValue or AssertionValue field is a BER-encoded instance of 289 the attribute value or a matching rule assertion value ASN.1 data type 290 as defined for use with X.500. (The first byte inside the OCTET STRING 291 wrapper is a tag octet. However, the OCTET STRING is still encoded in 292 primitive form.) 294 All servers MUST implement this form for both generating attribute 295 values in search responses, and parsing attribute values in add, 296 compare and modify requests, if the attribute type is recognized and 297 the attribute syntax name is that of Binary. Clients which request 298 that all attributes be returned from entries MUST be prepared to 299 receive values in binary (e.g. userCertificate;binary), and SHOULD NOT 300 simply display binary or unrecognized values to users. 302 4.3.2. Syntax Object Identifiers 304 Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are 305 dotted-decimal strings. These are not intended to be displayed to 306 users. 308 noidlen = numericoid [ "{" len "}" ] 310 // should allow reference to syntaxes by common names 312 len = numericstring 314 The following table lists some of the syntaxes that have been defined 315 for LDAP thus far. The H-R column suggests whether a value in that 316 syntax would likely be a human readable string. Clients and servers 317 need not implement all the syntaxes listed here, and MAY implement 318 other syntaxes. 320 Other documents may define additional syntaxes. However, the 321 definition of additional arbitrary syntaxes is strongly deprecated 322 since it will hinder interoperability: today's client and server 323 implementations generally do not have the ability to dynamically 324 recognize new syntaxes. In most cases attributes will be defined with 325 the syntax for directory strings. 327 Value being represented H-R OBJECT IDENTIFIER 328 ================================================================= 329 ACI Item N 1.3.6.1.4.1.1466.115.121.1.1 330 Access Point Y 1.3.6.1.4.1.1466.115.121.1.2 331 Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3 332 Audio N 1.3.6.1.4.1.1466.115.121.1.4 333 Binary N 1.3.6.1.4.1.1466.115.121.1.5 334 Bit String Y 1.3.6.1.4.1.1466.115.121.1.6 335 Boolean Y 1.3.6.1.4.1.1466.115.121.1.7 336 Certificate N 1.3.6.1.4.1.1466.115.121.1.8 337 Certificate List N 1.3.6.1.4.1.1466.115.121.1.9 338 Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10 339 Country String Y 1.3.6.1.4.1.1466.115.121.1.11 340 DN Y 1.3.6.1.4.1.1466.115.121.1.12 341 Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13 342 Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14 343 Directory String Y 1.3.6.1.4.1.1466.115.121.1.15 344 DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16 345 DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17 346 DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18 347 DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19 348 DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20 349 Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21 350 Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22 351 Fax N 1.3.6.1.4.1.1466.115.121.1.23 352 Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24 353 Guide Y 1.3.6.1.4.1.1466.115.121.1.25 354 IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26 355 INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27 356 JPEG N 1.3.6.1.4.1.1466.115.121.1.28 357 LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54 358 LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56 359 LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57 360 Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29 361 Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30 362 Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31 363 Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32 364 MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33 365 Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55 366 Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34 367 Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35 368 Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36 369 Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37 370 Octet String Y 1.3.6.1.4.1.1466.115.121.1.40 371 OID Y 1.3.6.1.4.1.1466.115.121.1.38 372 Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39 373 Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41 374 Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 375 Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43 376 Printable String Y 1.3.6.1.4.1.1466.115.121.1.44 377 Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58 378 Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45 379 Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46 380 Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47 381 Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48 382 Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49 383 Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50 384 Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51 385 Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52 386 UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53 388 A suggested minimum upper bound on the number of characters in value 389 with a string-based syntax, or the number of bytes in a value for all 390 other syntaxes, may be indicated by appending this bound count inside 391 of curly braces following the syntax name's OBJECT IDENTIFIER in an 392 Attribute Type Description. This bound is not part of the syntax name 393 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server 394 implementations should allow a string to be 64 characters long, 395 although they may allow longer strings. Note that a single character 396 of the Directory String syntax may be encoded in more than one byte 397 since UTF-8 is a variable-length encoding. 399 4.3.3. Syntax Description 401 The following BNF may be used to associate a short description with a 402 syntax OBJECT IDENTIFIER. Implementors should note that future 403 versions of this document may expand this definition to include 404 additional terms. Terms whose identifier begins with "X-" are 405 reserved for private experiments, and MUST be followed by a 406 . 408 SyntaxDescription = "(" whsp 409 numericoid whsp 410 [ "DESC" qdstring ] 411 whsp ")" 413 // should add NAME and OBSOLETE 415 4.4. Object Classes 417 The format for representation of object classes is defined in X.501 418 [3]. In general every entry will contain an abstract class ("top" or 419 "alias"), 421 // "alias" is not abstract. 422 // "top" may be implicit. 424 at least one structural object class, and zero or more auxiliary 425 object classes. Whether an object class is abstract, structural or 426 auxiliary is defined when the object class identifier is assigned. An 427 object class definition should not be changed without having a new 428 identifier assigned to it. 430 Object class descriptions are written according to the following BNF. 431 Implementors should note that future versions of this document may 432 expand this definition to include additional terms. Terms whose 433 identifier begins with "X-" are reserved for private experiments, and 434 MUST be followed by a encoding. 436 ObjectClassDescription = "(" whsp 437 numericoid whsp ; ObjectClass identifier 438 [ "NAME" qdescrs ] 439 [ "DESC" qdstring ] 440 [ "OBSOLETE" whsp ] 441 [ "SUP" oids ] ; Superior ObjectClasses 442 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] 443 ; default structural 444 [ "MUST" oids ] ; AttributeTypes 445 [ "MAY" oids ] ; AttributeTypes 446 whsp ")" 448 These are described as sample values for the subschema "objectClasses" 449 attribute for a server which implements the LDAP schema. While lines 450 have been folded for readability, the values transferred in protocol 451 would not contain newlines. 453 Servers SHOULD implement all the object classes referenced in section 454 7, except for extensibleObject, which is optional. Servers MAY 455 implement additional object classes not listed in this document, and 456 if they do so, MUST publish the definitions of the classes in the 457 objectClasses attribute of their subschema entries. 459 Schema developers MUST NOT create object class definitions whose names 460 conflict with attributes defined for use with LDAP in existing 461 standards-track RFCs. 463 4.5. Matching Rules 465 Matching rules are used by servers to compare attribute values against 466 assertion values when performing Search and Compare operations. They 467 are also used to identify the value to be added or deleted when 468 modifying entries, and are used when comparing a purported 469 distinguished name with the name of an entry. 471 Most of the attributes given in this document will have an equality 472 matching rule defined. 474 Matching rule descriptions are written according to the following BNF. 475 Implementors should note that future versions of this document may 476 have expanded this BNF to include additional terms. Terms whose 477 identifier begins with "X-" are reserved for private experiments, and 478 MUST be followed by a encoding. 480 MatchingRuleDescription = "(" whsp 481 numericoid whsp ; MatchingRule identifier 482 [ "NAME" qdescrs ] 483 [ "DESC" qdstring ] 484 [ "OBSOLETE" whsp ] 485 "SYNTAX" numericoid 486 whsp ")" 488 // should s/numericoid/oid/ 490 Values of the matchingRuleUse list the attributes which are suitable 491 for use with an extensible matching rule. 493 MatchingRuleUseDescription = "(" whsp 494 numericoid whsp ; MatchingRule identifier 495 [ "NAME" qdescrs ] 496 [ "DESC" qdstring ] 497 [ "OBSOLETE" ] 498 "APPLIES" oids ; AttributeType identifiers 499 whsp ")" 501 Servers which support matching rules and the extensibleMatch SHOULD 502 implement all the matching rules in section 8. 504 Servers MAY implement additional matching rules not listed in this 505 document, and if they do so, MUST publish the definitions of the 506 matching rules in the matchingRules attribute of their subschema 507 entries. If the server supports the extensibleMatch, then the server 508 MUST publish the relationship between the matching rules and 509 attributes in the matchingRuleUse attribute. 511 For example, a server which implements a privately-defined matching 512 rule for performing sound-alike matches on Directory String-valued 513 attributes would include the following in the subschema entry 514 (1.2.3.4.5 is an example, the OID of an actual matching rule would be 515 different): 517 matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' 518 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 520 If this matching rule could be used with the attributes 2.5.4.41 and 521 2.5.4.15, the following would also be present: 523 matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) ) 525 A client could then make use of this matching rule by sending a search 526 operation in which the filter is of the extensibleMatch choice, the 527 matchingRule field is "soundAlikeMatch", and the type field is 528 "2.5.4.41" or "2.5.4.15". 530 5. Attribute Types 532 All LDAP server implementations MUST recognize the attribute types 533 defined in this section. 535 Servers SHOULD also recognize all the attributes from section 5 of 536 [12]. 538 // Core schema should be moved into this document, User Schema 539 // should not be SHOULD. 541 5.1. Standard Operational Attributes 543 Servers MUST maintain values of these attributes in accordance with 544 the definitions in X.501(93). 546 5.1.1. createTimestamp 548 This attribute SHOULD appear in entries which were created using the 549 Add operation. 551 ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch 552 ORDERING generalizedTimeOrderingMatch 553 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 554 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 556 5.1.2. modifyTimestamp 558 This attribute SHOULD appear in entries which have been modified using 559 the Modify operation. 561 // s/using the Modify operation/using LDAP update operations/ 563 ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch 564 ORDERING generalizedTimeOrderingMatch 565 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 566 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 568 5.1.3. creatorsName 570 This attribute SHOULD appear in entries which were created using the 571 Add operation. 573 ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch 574 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 575 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 577 5.1.4. modifiersName 579 This attribute SHOULD appear in entries which have been modified using 580 the Modify operation. 582 // s/using the Modify operation/using update operations/ 584 ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch 585 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 586 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 588 5.1.5. subschemaSubentry 590 The value of this attribute is the name of a subschema entry (or 591 subentry if the server is based on X.500(93)) in which the server 592 makes available attributes specifying the schema. 594 // Replace with: 595 // 596 // The value of this attribute is the name of the subschema entry 597 // (or subentry) which makes available attributes specifying the 598 // schema controlling the entry which contains the attribute. 599 // This attribute SHOULD appear in all entries. 601 ( 2.5.18.10 NAME 'subschemaSubentry' 602 EQUALITY distinguishedNameMatch 603 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION 604 SINGLE-VALUE USAGE directoryOperation ) 606 5.1.6. attributeTypes 608 This attribute is typically located in the subschema entry. 610 ( 2.5.21.5 NAME 'attributeTypes' 611 EQUALITY objectIdentifierFirstComponentMatch 612 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) 614 5.1.7. objectClasses 616 This attribute is typically located in the subschema entry. 618 ( 2.5.21.6 NAME 'objectClasses' 619 EQUALITY objectIdentifierFirstComponentMatch 620 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) 622 5.1.8. matchingRules 624 This attribute is typically located in the subschema entry. 626 ( 2.5.21.4 NAME 'matchingRules' 627 EQUALITY objectIdentifierFirstComponentMatch 628 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation ) 630 5.1.9. matchingRuleUse 632 This attribute is typically located in the subschema entry. 634 ( 2.5.21.8 NAME 'matchingRuleUse' 635 EQUALITY objectIdentifierFirstComponentMatch 636 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation ) 638 5.2. LDAP Operational Attributes 640 These attributes are only present in the root DSE (see [1] and [3]). 642 Servers MUST recognize these attribute names, but it is not required 643 that a server provide values for these attributes, when the attribute 644 corresponds to a feature which the server does not implement. 646 5.2.1. namingContexts 648 The values of this attribute correspond to naming contexts which this 649 server masters or shadows. If the server does not master any 650 information (e.g. it is an LDAP gateway to a public X.500 directory) 651 this attribute will be absent. If the server believes it contains the 652 entire directory, the attribute will have a single value, and that 653 value will be the empty string (indicating the null DN of the root). 654 This attribute will allow a client to choose suitable base objects for 655 searching when it has contacted a server. 657 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 658 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation ) 660 // This should have an equality matching rule 662 5.2.2. altServer 664 The values of this attribute are URLs of other servers which may be 665 contacted when this server becomes unavailable. If the server does 666 not know of any other servers which could be used this attribute will 667 be absent. Clients may cache this information in case their preferred 668 LDAP server later becomes unavailable. 670 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 671 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation ) 673 // This should have an equality matching rule 675 5.2.3. supportedExtension 677 The values of this attribute are OBJECT IDENTIFIERs identifying the 678 supported extended operations which the server supports. 680 If the server does not support any extensions this attribute will be 681 absent. 683 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 684 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) 686 // This should have an equality matching rule 688 5.2.4. supportedControl 690 The values of this attribute are the OBJECT IDENTIFIERs identifying 691 controls which the server supports. If the server does not support 692 any controls, this attribute will be absent. 694 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 695 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) 697 // This should have an equality matching rule 699 5.2.5. supportedSASLMechanisms 701 The values of this attribute are the names of supported SASL 702 mechanisms which the server supports. If the server does not support 703 any mechanisms this attribute will be absent. 705 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 706 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation ) 708 // This should have an equality matching rule 710 5.2.6. supportedLDAPVersion 712 The values of this attribute are the versions of the LDAP protocol 713 which the server implements. 715 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 716 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation ) 718 // This should have an equality or ordering matching rule 720 5.3. LDAP Subschema Attribute 722 This attribute is typically located in the subschema entry. 724 5.3.1. ldapSyntaxes 726 Servers MAY use this attribute to list the syntaxes which are 727 implemented. Each value corresponds to one syntax. 729 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 730 EQUALITY objectIdentifierFirstComponentMatch 731 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation ) 733 5.4. X.500 Subschema attributes 735 These attributes are located in the subschema entry. All servers 736 SHOULD recognize their name, although typically only X.500 servers 737 will implement their functionality. 739 5.4.1. dITStructureRules 741 ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY 742 integerFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE 743 directoryOperation ) 745 5.4.2. nameForms 747 ( 2.5.21.7 NAME 'nameForms' 748 EQUALITY objectIdentifierFirstComponentMatch 749 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation ) 751 5.4.3. ditContentRules 753 ( 2.5.21.2 NAME 'dITContentRules' 754 EQUALITY objectIdentifierFirstComponentMatch 755 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation ) 757 6. Syntaxes 759 Servers SHOULD recognize all the syntaxes described in this section. 761 6.1. Attribute Type Description 763 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 765 Values in this syntax are encoded according to the BNF given at the 766 start of section 4.2. For example, 768 ( 2.5.4.0 NAME 'objectClass' 769 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 771 6.2. Binary 773 ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) 775 Values in this syntax are encoded as described in section 4.3.1. 777 6.3. Bit String 779 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 781 Values in this syntax are encoded according to the following BNF: 783 bitstring = "'" *binary-digit "'B" 785 binary-digit = "0" / "1" 787 Example: 789 '0101111101'B 791 6.4. Boolean 793 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 795 Values in this syntax are encoded according to the following BNF: 797 boolean = "TRUE" / "FALSE" 799 Boolean values have an encoding of "TRUE" if they are logically true, 800 and have an encoding of "FALSE" otherwise. 802 6.5. Certificate 804 ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) 806 Because of the changes from X.509(1988) and X.509(1993) and additional 807 changes to the ASN.1 definition to support certificate extensions, no 808 string representation is defined, and values in this syntax MUST only 809 be transferred using the binary encoding, by requesting or returning 810 the attributes with descriptions "userCertificate;binary" or 811 "caCertificate;binary". The BNF notation in RFC 1778 for "User 812 Certificate" is not recommended to be used. 814 6.6. Certificate List 816 ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) 818 Because of the incompatibility of the X.509(1988) and X.509(1993) 819 definitions of revocation lists, values in this syntax MUST only be 820 transferred using a binary encoding, by requesting or returning the 821 attributes with descriptions "certificateRevocationList;binary" or 822 "authorityRevocationList;binary". The BNF notation in RFC 1778 for 823 "Authority Revocation List" is not recommended to be used. 825 6.7. Certificate Pair 827 ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) 829 Because the Certificate is being carried in binary, values in this 830 syntax MUST only be transferred using a binary encoding, by requesting 831 or returning the attribute description "crossCertificatePair;binary". 832 The BNF notation in RFC 1778 for "Certificate Pair" is not recommended 833 to be used. 835 6.8. Country String 837 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 839 A value in this syntax is encoded the same as a value of Directory 840 String syntax. Note that this syntax is limited to values of exactly 841 two printable string characters, as listed in ISO 3166 [14]. 843 CountryString = p p 845 Example: 846 US 848 6.9. DN 850 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 852 Values in the Distinguished Name syntax are encoded to have the 853 representation defined in [5]. Note that this representation is not 854 reversible to an ASN.1 encoding used in X.500 for Distinguished Names, 855 as the CHOICE of any DirectoryString element in an RDN is no longer 856 known. 858 Examples (from [5]): 859 CN=Steve Kille,O=Isode Limited,C=GB 860 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 861 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 862 CN=Before\0DAfter,O=Test,C=GB 863 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 864 SN=Lu\C4\8Di\C4\87 866 6.10. Directory String 868 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 870 A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a 871 superset of Unicode). Servers and clients MUST be prepared to receive 872 encodings of arbitrary Unicode characters, including characters not 873 presently assigned to any character set. 875 For characters in the PrintableString form, the value is encoded as 876 the string value itself. 878 If it is of the TeletexString form, then the characters are 879 transliterated to their equivalents in UniversalString, and encoded in 880 UTF-8 [9]. 882 If it is of the UniversalString or BMPString forms [10], UTF-8 is used 883 to encode them. 885 Note: the form of DirectoryString is not indicated in protocol unless 886 the attribute value is carried in binary. Servers which convert to 887 DAP MUST choose an appropriate form. Servers MUST NOT reject values 888 merely because they contain legal Unicode characters outside of the 889 range of printable ASCII. 891 Example: 893 This is a string of DirectoryString containing #!%#@ 895 6.11. DIT Content Rule Description 897 ues in this syntax are encoded according to the following BNF. 898 lementors should note that future versions of this document have 899 expanded this BNF to include additional terms. 901 // s/ues/Values/ 902 // s/lementors/Implementors/ 903 // s/have/and have/ 904 0 905 // remove 907 DITContentRuleDescription = "(" 908 numericoid ; Structural ObjectClass identifier 910 [ "NAME" qdescrs ] 911 [ "DESC" qdstring ] 912 [ "OBSOLETE" ] 913 [ "AUX" oids ] ; Auxiliary ObjectClasses 914 [ "MUST" oids ] ; AttributeType identifiers 915 [ "MAY" oids ] ; AttributeType identifiers 916 [ "NOT" oids ] ; AttributeType identifiers 917 ")" 919 0 2. Facsimile Telephone Number 920 // s/^/6.12./ 922 3 923 // remove 925 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) 927 Values in this syntax are encoded according to the following BNF: 929 fax-number = printablestring [ "$" faxparameters ] 931 faxparameters = faxparm / ( faxparm "$" faxparameters ) 933 faxparm = "twoDimensional" / "fineResolution" / 934 "unlimitedLength" / 935 "b4Length" / "a3Width" / "b4Width" / "uncompressed" 937 In the above, the first printablestring is the telephone number, based 938 on E.123 [15], and the faxparm tokens represent fax parameters. 940 6.13. Fax 942 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 944 Values in this syntax are encoded as if they were octet strings 945 containing Group 3 Fax images as defined in [7]. 947 6.14. Generalized Time 949 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 951 Values in this syntax are encoded as printable strings, represented as 952 specified in X.208. Note that the time zone must be specified. It is 953 strongly recommended that GMT time be used. For example, 955 199412161032Z 957 6.15. IA5 String 959 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 961 The encoding of a value in this syntax is the string value itself. 963 6.16. INTEGER 965 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 967 Values in this syntax are encoded as the decimal representation of 968 their values, with each decimal digit represented by the its character 969 equivalent. So the number 1321 is represented by the character string 970 "1321". 972 6.17. JPEG 974 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 976 Values in this syntax are encoded as strings containing JPEG images in 977 the JPEG File Interchange Format (JFIF), as described in [8]. 979 6.18. Matching Rule Description 981 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 983 Values of type matchingRules are encoded as strings according to the 984 BNF given in section 4.5. 986 6.19. Matching Rule Use Description 988 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' ) 990 Values of type matchingRuleUse are encoded as strings according to the 991 BNF given in section 4.5. 993 6.20. MHS OR Address 995 ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) 997 Values in this syntax are encoded as strings, according to the format 998 defined in [11]. 1000 6.21. Name And Optional UID 1002 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 1004 Values in this syntax are encoded according to the following BNF: 1006 NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 1008 Although the '#' character may occur in a string representation of a 1009 distinguished name, no additional special quoting is done. This 1010 syntax has been added subsequent to RFC 1778. 1012 Example: 1014 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 1016 6.22. Name Form Description 1018 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 1020 Values in this syntax are encoded according to the following BNF. 1021 Implementors should note that future versions of this document may 1022 have expanded this BNF to include additional terms. 1024 NameFormDescription = "(" whsp 1025 numericoid whsp ; NameForm identifier 1026 [ "NAME" qdescrs ] 1027 [ "DESC" qdstring ] 1028 [ "OBSOLETE" whsp ] 1029 "OC" woid ; Structural ObjectClass 1030 "MUST" oids ; AttributeTypes 1031 [ "MAY" oids ] ; AttributeTypes 1032 whsp ")" 1034 6.23. Numeric String 1036 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 1038 The encoding of a string in this syntax is the string value itself. 1039 Example: 1041 1997 1043 6.24. Object Class Description 1045 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 1047 Values in this syntax are encoded according to the BNF in section 4.4. 1049 6.25. OID 1051 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 1053 Values in the Object Identifier syntax are encoded according to the 1054 BNF in section 4.1 for "oid". 1056 Example: 1058 1.2.3.4 1059 cn 1061 6.26. Other Mailbox 1063 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 1065 Values in this syntax are encoded according to the following BNF: 1067 otherMailbox = mailbox-type "$" mailbox 1069 mailbox-type = printablestring 1071 mailbox = 1073 In the above, mailbox-type represents the type of mail system in which 1074 the mailbox resides, for example "MCIMail"; and mailbox is the actual 1075 mailbox in the mail system defined by mailbox-type. 1077 6.27. Postal Address 1079 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 1081 Values in this syntax are encoded according to the following BNF: 1083 postal-address = dstring *( "$" dstring ) 1085 In the above, each dstring component of a postal address value is 1086 encoded as a value of type Directory String syntax. Backslashes and 1087 dollar characters, if they occur in the component, are quoted as 1088 described in section 4.3. Many servers limit the postal address to 1089 six lines of up to thirty characters. 1091 Example: 1093 1234 Main St.$Anytown, CA 12345$USA 1094 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 1096 6.28. Presentation Address 1098 ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) 1100 Values in this syntax are encoded with the representation described in 1101 RFC 1278 [6]. 1103 6.29. Printable String 1105 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1107 The encoding of a value in this syntax is the string value itself. 1108 PrintableString is limited to the characters in production p of 1109 section 4.1. 1111 Example: 1113 This is a PrintableString 1115 6.30. Telephone Number 1117 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1119 Values in this syntax are encoded as if they were Printable String 1120 types. Telephone numbers are recommended in X.520 to be in 1121 international form, as described in E.123 [15]. 1123 // X.520 requires telephone numbers "complies with the 1124 // internationally agreed format for showing international 1125 // telephone numbers, CCITT Recommendation E.123 1127 Example: 1129 +1 512 305 0280 1131 6.31. UTC Time 1133 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1135 Values in this syntax are encoded as if they were printable strings 1136 with the strings containing a UTCTime value. This is historical; new 1137 attribute definitions SHOULD use GeneralizedTime instead. 1139 // This syntax and attributes/rules which use it should be marked 1140 // OBSOLETE. 1142 6.32. LDAP Syntax Description 1144 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 1146 Values in this syntax are encoded according to the BNF in section 1147 4.3.3. 1149 6.33. DIT Structure Rule Description 1150 ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' 1151 ) 1153 Values with this syntax are encoded according to the following BNF: 1155 DITStructureRuleDescription = "(" whsp 1156 ruleidentifier whsp ; DITStructureRule identifier 1157 [ "NAME" qdescrs ] 1158 [ "DESC" qdstring ] 1159 [ "OBSOLETE" whsp ] 1160 "FORM" woid whsp ; NameForm 1161 [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules 1162 ")" 1164 ruleidentifier = integer 1166 ruleidentifiers = ruleidentifier | 1167 "(" whsp ruleidentifierlist whsp ")" 1169 ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ] 1171 7. Object Classes 1173 Servers SHOULD recognize all the names of standard classes from 1174 section 7 of [12]. 1176 // User schema, especially that derived from 1177 // X.500(97), should not be SHOULD. It should optional 1178 // supported. 1180 7.1. Extensible Object Class 1182 The extensibleObject object class, if present in an entry, permits 1183 that entry to optionally hold any attribute. 1184 // which the server recognizes. The MAY attribute list of this class 1185 is implicitly the set of all attributes. 1187 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 1188 SUP top AUXILIARY ) 1190 The mandatory attributes of the other object classes of this entry are 1191 still required to be present. 1193 Note that not all servers will implement this object class, and those 1194 which do not will reject requests to add entries which contain this 1195 object class, or modify an entry to add this object class. 1197 7.2. subschema 1198 This object class is used in the subschema entry. 1200 ( 2.5.20.1 NAME 'subschema' AUXILIARY 1201 MAY ( dITStructureRules $ nameForms $ ditContentRules $ 1202 objectClasses $ attributeTypes $ matchingRules $ 1203 matchingRuleUse ) ) 1205 The ldapSyntaxes operational attribute may also be present in 1206 subschema entries. 1208 8. Matching Rules 1210 Servers which implement the extensibleMatch filter SHOULD allow all 1211 the matching rules listed in this section to be used in the 1212 extensibleMatch. In general these servers SHOULD allow matching rules 1213 to be used with all attribute types known to the server, when the 1214 assertion syntax of the matching rule is the same as the value syntax 1215 of the attribute. 1217 Servers MAY implement additional matching rules. 1219 8.1. Matching Rules used in Equality Filters 1221 Servers SHOULD be capable of performing the following matching rules. 1223 For all these rules, the assertion syntax is the same as the value 1224 syntax. 1226 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1227 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1229 If the client supplies a filter using an objectIdentifierMatch whose 1230 matchValue oid is in the "descr" form, and the oid is not recognized 1231 by the server, then the filter is Undefined. 1233 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1234 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1236 // Add caseExactMatch 1238 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1239 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1241 ( 2.5.13.8 NAME 'numericStringMatch' 1242 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1244 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1245 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1247 ( 2.5.13.14 NAME 'integerMatch' 1248 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1250 ( 2.5.13.16 NAME 'bitStringMatch' 1251 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1253 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1254 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1256 ( 2.5.13.22 NAME 'presentationAddressMatch' 1257 SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) 1259 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1260 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 1262 ( 2.5.13.24 NAME 'protocolInformationMatch' 1263 SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) 1265 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1266 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1268 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1269 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1271 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1272 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1274 When performing the caseIgnoreMatch, caseIgnoreListMatch, 1275 telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, 1276 multiple adjoining whitespace characters are treated the same as an 1277 individual space, and leading and trailing whitespace is ignored. 1279 Clients MUST NOT assume that servers are capable of transliteration of 1280 Unicode values. 1282 8.2. Matching Rules used in Inequality Filters 1284 Servers SHOULD be capable of performing the following matching rules, 1285 which are used in greaterOrEqual and lessOrEqual filters. 1287 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1288 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1290 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1291 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1293 The sort ordering for a caseIgnoreOrderingMatch is 1294 implementation-dependent. 1296 // add octetStringOrderingMatch 1297 // add caseExactOrderingMatch 1298 // add caseExactIA5OrderingMatch 1299 // add caseIgnoreIA5OrderingMatch 1301 8.3. Syntax and Matching Rules used in Substring Filters 1303 // and extensible matching rule filters 1305 The Substring Assertion syntax is used only as the syntax of assertion 1306 values in the extensible match. It is not used as the syntax of 1307 attributes, or in the substring filter. 1309 // Suggest the paragraph be replaced replaced with: 1310 // 1311 // The Substring Assertion syntax is used in rules which may 1312 // be used in substrings and extensible matching rules. When 1313 // using a substrings assertion, substrings components are 1314 // provided in a SubstringFilter sequence. When using 1315 // a matching rule assertion, substring components are 1316 // are encoded according to the following BNF and provided 1317 // as the matchValue of the MatchingRuleAssertion. 1318 // 1320 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1322 The Substring Assertion is encoded according to the following BNF: 1324 substring = [initial] any [final] 1325 initial = value 1326 any = "*" *(value "*") 1327 final = value 1329 The production is UTF-8 encoded string. Should the backslash 1330 or asterix characters be present in a production of , they are 1331 quoted as described in section 4.3. 1333 Servers SHOULD be capable of performing the following matching rules, 1334 which are used in substring filters. 1336 // but the syntax (as originally defined) is not to be used in 1337 // substring filters! 1339 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1340 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1342 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1343 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1345 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1346 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1348 // Add CaseIgnoreIA5SubstringsMatch 1349 // Add CaseExactIA5SubstringsMatch 1351 // Add OctetStringSubstringsMatch (and Octet String Substring 1352 // Assertion) 1354 8.4. Matching Rules for Subschema Attributes 1356 Servers which allow subschema entries to be modified by clients MUST 1357 support the following matching rules, as they are the equality 1358 matching rules for several of the subschema attributes. 1360 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1361 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1363 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' 1364 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1366 Implementors should note that the assertion syntax of these matching 1367 rules, an INTEGER or OID, is different from the value syntax of 1368 attributes for which this is the equality matching rule. 1370 If the client supplies an extensible filter using an 1371 objectIdentifierFirstComponentMatch whose matchValue is in the "descr" 1372 form, and the OID is not recognized by the server, then the filter is 1373 Undefined. 1375 9. Security Considerations 1377 // Add consideration requiring the use of strong authentication 1378 // to update the directory. 1380 9.1. Disclosure 1382 Attributes of directory entries are used to provide descriptive 1383 information about the real-world objects they represent, which can be 1384 people, organizations or devices. Most countries have privacy laws 1385 regarding the publication of information about people. 1387 9.2. Use of Attribute Values in Security Applications 1389 The transformations of an AttributeValue value from its X.501 form to 1390 an LDAP string representation are not always reversible back to the 1391 same BER or DER form. An example of a situation which requires the 1392 DER form of a distinguished name is the verification of an X.509 1393 certificate. 1395 For example, a distinguished name consisting of one RDN with one AVA, 1396 in which the type is commonName and the value is of the TeletexString 1397 choice with the letters 'Sam' would be represented in LDAP as the 1398 string CN=Sam. Another distinguished name in which the value is still 1399 'Sam' but of the PrintableString choice would have the same 1400 representation CN=Sam. 1402 Applications which require the reconstruction of the DER form of the 1403 value SHOULD NOT use the string representation of attribute syntaxes 1404 when converting a value to LDAP format. Instead it SHOULD use the 1405 Binary syntax. 1407 // Sections 10,11 were trimmed. 1409 12. Bibliography 1411 [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access 1412 Protocol (v3)", RFC 2251, December 1997. 1414 [2] The Directory: Selected Attribute Types. ITU-T Recommendation 1415 X.520, 1993. 1417 [3] The Directory: Models. ITU-T Recommendation X.501, 1993. 1419 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1420 Levels", RFC 2119, March 1997. 1422 [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access 1423 Protocol (v3): UTF-8 String Representation of 1424 Distinguished Names", RFC 2253, December 1997. 1426 [6] Kille, S., "A String Representation for Presentation Addresses", 1427 RFC 1278, November 1991. 1429 [7] Terminal Equipment and Protocols for Telematic Services - 1430 Standardization of Group 3 facsimile apparatus for document 1431 transmission. CCITT, Recommendation T.4. 1433 [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 1434 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 1436 [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 1437 10646", RFC 2044, October 1996. 1439 [10] Universal Multiple-Octet Coded Character Set (UCS) - 1440 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1441 1993 (With amendments). 1443 [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1444 and RFC 822", RFC 1327, May 1992. 1446 [12] Wahl, M., "A Summary of the X.500(96) User Schema for use 1447 with LDAPv3", RFC 2256, December 1997. 1449 [13] Crocker, D., "Standard of the Format of ARPA-Internet Text 1450 Messages", STD 11, RFC 822, August 1982. 1452 [14] ISO 3166, "Codes for the representation of names of countries". 1454 [15] ITU-T Rec. E.123, Notation for national and international 1455 telephone numbers, 1988. 1457 // End of RFC 2252 text 1459 Additional Information 1461 Discussions regarding these suggestions may directed to the author: 1463 Kurt D. Zeilenga 1464 OpenLDAP Foundation 1465 1467 or the LDAPext Working Group mailing list: 1469 1471 Copyright 2000, The Internet Society. All Rights Reserved. 1473 This document and translations of it may be copied and furnished 1474 to others, and derivative works that comment on or otherwise explain 1475 it or assist in its implementation may be prepared, copied, published 1476 and distributed, in whole or in part, without restriction of any 1477 kind, provided that the above copyright notice and this paragraph 1478 are included on all such copies and derivative works. However, 1479 this document itself may not be modified in any way, such as by 1480 removing the copyright notice or references to the Internet Society 1481 or other Internet organizations, except as needed for the purpose 1482 of developing Internet standards in which case the procedures for 1483 copyrights defined in the Internet Standards process must be 1484 followed, or as required to translate it into languages other than 1485 English. 1487 The limited permissions granted above are perpetual and will not 1488 be revoked by the Internet Society or its successors or assigns. 1490 This document and the information contained herein is provided on 1491 an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE 1492 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 1493 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1494 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1495 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1496 PURPOSE.