idnits 2.17.1 draft-ietf-ldapbis-bcp64-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 908), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (21 February 2005) is 7004 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPURL' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 1779 (Obsoleted by RFC 2253, RFC 3494) -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: BCP OpenLDAP Foundation 4 Expires in six months 21 February 2005 5 Obsoletes: RFC 3383 7 IANA Considerations for LDAP 8 10 Status of Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Best Current Practice 14 document. This document is intended to replace RFC 3383. 15 Distribution of this memo is unlimited. Technical discussion of this 16 document will take place on the IETF LDAP Revision Working Group 17 (LDAPBIS) mailing list . Please send 18 editorial comments directly to the document editor 19 . 21 By submitting this Internet-Draft, I accept the provisions of Section 22 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 23 applicable patent or other IPR claims of which I am aware have been 24 disclosed, or will be disclosed, and any of which I become aware will 25 be disclosed, in accordance with RFC 3668. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Please see the Full Copyright section near the end of this document 45 for more information. 47 Abstract 49 This document provides procedures for registering extensible elements 50 of Lightweight Directory Access Protocol (LDAP). The document also 51 provides guidelines to Internet Assigned Numbers Authority (IANA) 52 describing conditions under which new values can be assigned. 54 1. Introduction 56 The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an 57 extensible protocol. LDAP supports: 59 - addition of new operations, 60 - extension of existing operations, and 61 - extensible schema. 63 This document details procedures for registering values of used to 64 unambiguously identify extensible elements of the protocol including: 66 - LDAP message types; 67 - LDAP extended operations and controls; 68 - LDAP result codes; 69 - LDAP authentication methods; 70 - LDAP attribute description options; and 71 - Object Identifier descriptors. 73 These registries are maintained by the Internet Assigned Numbers 74 Authority (IANA). 76 In addition, this document provides guidelines to IANA describing the 77 conditions under which new values can be assigned. 79 This document replaces RFC 3383. 81 2. Terminology and Conventions 83 This section details terms and conventions used in this document. 85 2.1. Policy Terminology 87 The terms "IESG Approval", "Standards Action", "IETF Consensus", 88 "Specification Required", "First Come First Served", "Expert Review", 89 and "Private Use" are used as defined in BCP 26 [RFC2434]. 91 2.2. Requirement Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in BCP 14 [RFC2119]. In 96 this case, "the specification" as used by BCP 14 refers to the 97 processing of protocols being submitted to the IETF standards 98 process. 100 2.3. Common ABNF Productions 102 A number of syntaxes in this document are described using ABNF 103 [RFC2234]. These syntaxes rely on the following common productions: 105 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 106 LDIGIT = %x31-39 ; "1"-"9" 107 DIGIT = %x30 / LDIGIT ; "0"-"9" 108 HYPHEN = %x2D ; "-" 109 DOT = %x2E ; "." 110 number = DIGIT / ( LDIGIT 1*DIGIT ) 111 keychar = ALPHA / DIGIT / HYPHEN 112 leadkeychar = ALPHA 113 keystring = leadkeychar *keychar 115 A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded 116 Unicode [Unicode] restricted to the production. 118 3. IANA Considerations for LDAP 120 This section details each kind of protocol value which can be 121 registered and provides IANA guidelines on how to assign new values. 123 IANA may reject obviously bogus registrations described. 125 LDAP values specified in RFCs MUST be registered. Other LDAP values, 126 expecting those in private-use name spaces, SHOULD be registered. 127 RFCs SHOULD NOT reference, use, or otherwise recongize unregistered 128 LDAP values. 130 3.1. Object Identifiers 132 Numerous LDAP schema and protocol elements are identified by Object 133 Identifiers (OIDs) [X.680]. Specifications which assign OIDs to 134 elements SHOULD state who delegated the OIDs for its use. 136 For IETF developed elements, specifications SHOULD use OIDs under 137 "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed 138 by others, any properly delegated OID can be used, including those 139 under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private 140 Enterprise Numbers" (1.3.6.1.4.1.x). 142 Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert 143 Review with Specification Required. Only one OID per specification 144 will be assigned. The specification MAY then assign any number of 145 OIDs within this arc without further coordination with IANA. 147 Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by 148 IANA . Practices for IANA 149 assignment of Internet Private Enterprise Numbers is detailed in STD 150 16 [RFC1155]. 152 To avoid interoperability problems between early implementations of a 153 "work in progress" and implementations of the published specification 154 (e.g., the RFC), experimental OIDs SHOULD be used in "works in 155 progress" and early implementations. OIDs under the Internet 156 Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 157 Practices for IANA assignment of these Internet Experimental numbers 158 is detailed in STD 16 [RFC1155]. 160 3.2 Protocol Mechanisms 162 LDAP provides a number of Root DSE attributes for discovery of 163 protocol mechanisms identified by OIDs, including the 164 supportedControl, supportedExtension, and supportedFeatures 165 attributes [Models], 167 A registry of OIDs used for discover of protocol mechanisms is 168 provided to allow implementors and others to locate the technical 169 specification for these protocol mechanisms. Future specifications 170 of additional Root DSE attributes holding values identifying protocol 171 mechanisms MAY extend this registry for their values. 173 Protocol Mechanisms are registered on a First Come First Served 174 basis. 176 3.3 LDAP Syntaxes 178 This registry provides a listing of LDAP syntaxes [Models]. Each 179 LDAP syntax is identified by an object identifier (OID). This 180 registry is provided to allow implementors and others to locate the 181 technical specification describing a particular LDAP Syntax. 183 LDAP Syntaxes are registered on a First Come First Served with 184 Specification Required basis. 186 Note: unlike object classes, attribute types and various other kinds 187 of schema elements, descriptors are not used in LDAP to identify LDAP 188 Syntaxes. 190 3.4. Object Identifier Descriptors 192 LDAP allows short descriptive names (or descriptors) to be used 193 instead of a numeric Object Identifier to identify select protocol 194 extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] 195 extensions, and other objects. 197 While the protocol allows the same descriptor to refer to different 198 object identifiers in certain cases and the registry supports 199 multiple registrations of the same descriptor (each indicating a 200 different kind of schema element and different object identifier), 201 multiple registrations of the same descriptor are to be avoided. All 202 such registration requests require Expert Review. 204 Descriptors are restricted to strings of UTF-8 encoded Unicode 205 characters restricted by the following ABNF: 207 name = keystring 209 Descriptors are case-insensitive. 211 Multiple names may be assigned to a given OID. For purposes of 212 registration, an OID is to be represented in numeric OID form (e.g., 213 1.1.0.23.40) conforming to the ABNF: 215 numericoid = number 1*( DOT number ) 217 While the protocol places no maximum length restriction upon 218 descriptors, they should be short. Descriptors longer than 48 219 characters may be viewed as too long to register. 221 A value ending with a hyphen ("-") reserves all descriptors which 222 start with that value. For example, the registration of the option 223 "descrFamily-" reserves all options which start with "descrFamily-" 224 for some related purpose. 226 Descriptors beginning with "x-" are for Private Use and cannot be 227 registered. 229 Descriptors beginning with "e-" are reserved for experiments and will 230 be registered on a First Come First Served basis. 232 All other descriptors require Expert Review to be registered. 234 The registrant need not "own" the OID being named. 236 The OID name space is managed by The ISO/IEC Joint Technical 237 Committee 1 - Subcommittee 6. 239 3.5. AttributeDescription Options 241 An AttributeDescription [Models] can contain zero or more options 242 specifying additional semantics. An option SHALL be restricted to a 243 string UTF-8 encoded Unicode characters limited by the following 244 ABNF: 246 option = keystring 248 Options are case-insensitive. 250 While the protocol places no maximum length restriction upon option 251 strings, they should be short. Options longer than 24 characters may 252 be viewed as too long to register. 254 Values ending with a hyphen ("-") reserve all option names which 255 start with the name. For example, the registration of the option 256 "optionFamily-" reserves all options which start with "optionFamily-" 257 for some related purpose. 259 Options beginning with "x-" are for Private Use and cannot be 260 registered. 262 Options beginning with "e-" are reserved for experiments and will be 263 registered on a First Come First Served basis. 265 All other options require Standards Action or Expert Review with 266 Specification Required to be registered. 268 3.6. LDAP Message Types 270 Each protocol message is encapsulated in an LDAPMessage envelope 271 [Protocol]. The protocolOp CHOICE indicates the type of message 272 encapsulated. Each message type consists of an ASN.1 identifier in 273 the form of a keyword and a non-negative choice number. The choice 274 number is combined with the class (APPLICATION) and data type 275 (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's 276 encoding. The choice numbers for existing protocol messages are 277 implicit in the protocol's ASN.1 defined in [Protocol]. 279 New values will be registered upon Standards Action. 281 Note: LDAP provides extensible messages which reduces, but does not 282 eliminate, the need to add new message types. 284 3.7. LDAP Authentication Method 286 The LDAP Bind operation supports multiple authentication methods 287 [Protocol]. Each authentication choice consists of an ASN.1 288 identifier in the form of a keyword and a non-negative integer. 290 The registrant SHALL classify the authentication method usage using 291 one of the following terms: 293 COMMON - method is appropriate for common use on the 294 Internet, 295 LIMITED USE - method is appropriate for limited use, 296 OBSOLETE - method has been deprecated or otherwise found to 297 be inappropriate for any use. 299 Methods without publicly available specifications SHALL NOT be 300 classified as COMMON. New registrations of class OBSOLETE cannot be 301 registered. 303 New authentication method integers in the range 0-1023 require 304 Standards Action to be registered. New authentication method 305 integers in the range 1024-4095 require Expert Review with 306 Specification Required. New authentication method integers in the 307 range 4096-16383 will be registered on a First Come First Served 308 basis. Keywords associated with integers in the range 0-4095 SHALL 309 NOT start with "e-" or "x-". Keywords associated with integers in 310 the range 4096-16383 SHALL start with "e-". Values greater than or 311 equal to 16384 and keywords starting with "x-" are for Private Use 312 and cannot be registered. 314 Note: LDAP supports Simple Authentication and Security Layers [SASL] 315 as an authentication choice. SASL is an extensible 316 authentication framework. 318 3.8. LDAP Result Codes 320 LDAP result messages carry an resultCode enumerated value to indicate 321 the outcome of the operation [Protocol]. Each result code consists 322 of a ASN.1 identifier in the form of a keyword and a non-negative 323 integer. 325 New resultCodes integers in the range 0-1023 require Standards Action 326 to be registered. New resultCode integers in the range 1024-4095 327 require Expert Review with Specification Required. New resultCode 328 integers in the range 4096-16383 will be registered on a First Come 329 First Served basis. Keywords associated with integers in the range 330 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 331 integers in the range 4096-16383 SHALL start with "e-". Values 332 greater than or equal to 16384 and keywords starting with "x-" are 333 for Private Use and cannot be registered. 335 3.9. LDAP Search Scope 337 LDAP SearchRequest messages carry a scope enumerated value to 338 indicate the extend of search within the DIT [Protocol] Each search 339 value consists of a ASN.1 identifier in the form of a keyword and a 340 non-negative integer. 342 New scope integers in the range 0-1023 require Standards Action to be 343 registered. New scope integers in the range 1024-4095 require Expert 344 Review with Specification Required. New scope integers in the range 345 4096-16383 will be registered on a First Come First Served basis. 346 Keywords associated with integers in the range 0-4095 SHALL NOT start 347 with "e-" or "x-". Keywords associated with integers in the range 348 4096-16383 SHALL start with "e-". Values greater than or equal to 349 16384 and keywords starting with "x-" are for Private Use and cannot 350 be registered. 352 3.10. LDAP Filter Choice 354 LDAP filters are used in making assertions against an object 355 represented in the directory [Protocol]. The Filter CHOICE indicates 356 a type of assertion. Each Filter CHOICE consists of an ASN.1 357 identifier in the form of a keyword and a non-negative choice number. 358 The choice number is combined with the class (APPLICATION) and data 359 type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the 360 message's encoding. 362 Note: LDAP provides the extensibleMatching choice which reduces, but 363 does not eliminate, the need to add new filter choices. 365 3.11. LDAP ModifyRequest Operation Type 366 The LDAP ModifyRequest carries a sequence of modification operations 367 [Protocol]. Each kind (e.g., add, delete, replace) of operation is 368 consists of a ASN.1 identifier in the form of a keyword and a 369 non-negative integer. 371 New operation type integers in the range 0-1023 require Standards 372 Action to be registered. New operation type integers in the range 373 1024-4095 require Expert Review with Specification Required. New 374 operation type integers in the range 4096-16383 will be registered on 375 a First Come First Served basis. Keywords associated with integers 376 in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords 377 associated with integers in the range 4096-16383 SHALL start with 378 "e-". Values greater than or equal to 16384 and keywords starting 379 with "x-" are for Private Use and cannot be registered. 381 3.12. LDAP authzId Prefixes 383 Authorization Identities in LDAP are strings conforming to the 384 production [AuthMeth]. This production is extensible. 385 Each new specific authorization form is identified by a prefix string 386 conforming to the following ABNF: 388 prefix = keystring COLON 389 COLON = %x3A ; COLON (":" U+003A) 391 Prefixes are case-insensitive. 393 While the protocol places no maximum length restriction upon prefix 394 strings, they should be short. Prefixes longer than 12 characters 395 may be viewed as too long to register. 397 Prefixes beginning with "x-" are for Private Use and cannot be 398 registered. 400 Prefixes beginning with "e-" are reserved for experiments and will be 401 registered on a First Come First Served basis. 403 All other prefixes require Standards Action or Expert Review with 404 Specification Required to be registered. 406 3.13. Directory Systems Names 408 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 409 valid keywords for well known attributes was used in the LDAPv2 410 string representation of a distinguished name [RFC1779]. LDAPv2 is 411 now Historic [RFC3494]. 413 Directory systems names are not known to be used in any other 414 context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section 415 3.2] (which have a different syntax than directory system names). 417 New Directory System Names will no longer be accepted. For 418 historical purposes, the current list of registered names should 419 remain publicly available. 421 4. Registration Procedure 423 The procedure given here MUST be used by anyone who wishes to use a 424 new value of a type described in Section 3 of this document. 426 The first step is for the requester to fill out the appropriate form. 427 Templates are provided in Appendix A. 429 If the policy is Standards Action, the completed form SHOULD be 430 provided to the IESG with the request for Standards Action. Upon 431 approval of the Standards Action, the IESG SHALL forward the request 432 (possibly revised) to IANA. The IESG SHALL be viewed as the owner of 433 all values requiring Standards Action. 435 If the policy is Expert Review, the requester SHALL post the 436 completed form to the mailing list for 437 public review. The review period is two (2) weeks. If a revised 438 form is later submitted, the review period is restarted. Anyone may 439 subscribe to this list by sending a request to 440 . During the review, objections may 441 be raised by anyone (including the Expert) on the list. After 442 completion of the review, the Expert, based upon public comments, 443 SHALL either approve the request and forward it to the IESG OR deny 444 the request. In either case, the Expert SHALL promptly notify the 445 requester of the action. Actions of the Expert may be appealed 446 [RFC2026]. The Expert is appointed by Applications Area Director(s). 447 The requester is viewed as the owner of values registered under 448 Expert Review. 450 If the policy is First Come First Served, the requester SHALL submit 451 the completed form directly to the IANA: . The 452 requester is viewed as the owner of values registered under First 453 Come First Served. 455 Neither the Expert nor IANA will take position on the claims of 456 copyright or trademarks issues regarding completed forms. 458 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 459 after IESG review and tentative approval, the document editor SHOULD 460 revise the I-D to use registered values. 462 5. Registration Maintenance 464 This section discusses maintenance of registrations. 466 5.1. Lists of Registered Values 468 IANA makes lists of registered values readily available to the 469 Internet community on their web site: . 471 5.2. Change Control 473 The registration owner MAY update the registration subject to the 474 same constraints and review as with new registrations. In cases 475 where the owner is not unable or unwilling to make necessary updates, 476 the IESG MAY assume ownership in order to update the registration. 478 5.3. Comments 480 For cases where others (anyone other than the owner) have significant 481 objections to the claims in a registration and the owner does not 482 agree to change the registration, comments MAY be attached to a 483 registration upon Expert Review. For registrations owned by the 484 IESG, the objections SHOULD be addressed by initiating a request for 485 Expert Review. 487 The form to these requests is ad hoc, but MUST include the specific 488 objections to be reviewed and SHOULD contain (directly or by 489 reference) materials supporting the objections. 491 6. Security Considerations 493 The security considerations detailed in BCP 26 [RFC2434] are 494 generally applicable to this document. Additional security 495 considerations specific to each name space are discussed in Section 3 496 where appropriate. 498 Security considerations for LDAP are discussed in documents 499 comprising the technical specification [Roadmap]. 501 7. Acknowledgment 502 This document is a product of the IETF LDAP Revision (LDAPBIS) 503 Working Group (WG). This document is a revision of RFC 3383, also a 504 product of the LDAPBIS WG. 506 This document includes text borrowed from "Guidelines for Writing an 507 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 508 Harald Alvestrand. 510 8. Author's Address 512 Kurt D. Zeilenga 513 OpenLDAP Foundation 515 Email: Kurt@OpenLDAP.org 517 9. References 519 [[Note to the RFC Editor: please replace the citation tags used in 520 referencing Internet-Drafts with tags of the form RFCnnnn where 521 possible.]] 523 9.1. Normative References 525 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 526 Identification of Management Information for TCP/IP- 527 based Internets", STD 16 (also RFC 1155), May 1990. 529 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 530 3", BCP 9 (also RFC 2026), October 1996. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 535 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 536 Specifications: ABNF", RFC 2234, November 1997. 538 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 539 IANA Considerations Section in RFCs", BCP 26 (also RFC 540 2434), October 1998. 542 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 543 10646", RFC 3629 (also STD 63), November 2003. 545 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 546 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 547 progress. 549 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 550 Connection Level Security Mechanisms", 551 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 553 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 554 Models", draft-ietf-ldapbis-models-xx.txt, a work in 555 progress. 557 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 558 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 560 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 561 draft-ietf-ldapbis-url-xx.txt, a work in progress. 563 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 564 3.2.0" is defined by "The Unicode Standard, Version 3.0" 565 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 566 as amended by the "Unicode Standard Annex #27: Unicode 567 3.1" (http://www.unicode.org/reports/tr27/) and by the 568 "Unicode Standard Annex #28: Unicode 3.2" 569 (http://www.unicode.org/reports/tr28/). 571 [X.680] International Telecommunication Union - 572 Telecommunication Standardization Sector, "Abstract 573 Syntax Notation One (ASN.1) - Specification of Basic 574 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 576 9.2. Informative References 578 [RFC1779] Kille, S., "A String Representation of Distinguished 579 Names", RFC 1779, March 1995. 581 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 582 version 2 (LDAPv2) to Historic Status", RFC 3494, March 583 2003. 585 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 586 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 588 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 589 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a 590 work in progress. 592 [SASL] Melnikov, A. (Editor), "Simple Authentication and 593 Security Layer (SASL)", 594 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 596 [IANADSN] IANA, "Directory Systems Names", 597 http://www.iana.org/assignments/directory-system-names. 599 Appendix A. Registration Templates 601 This appendix provides registration templates for registering new 602 LDAP values. Note that more than one value may be requested by 603 extending the template by listing multiple values, or through use of 604 tables. 606 A.1. LDAP Object Identifier Registration Template 608 Subject: Request for LDAP OID Registration 610 Person & email address to contact for further information: 612 Specification: (I-D) 614 Author/Change Controller: 616 Comments: 618 (Any comments that the requester deems relevant to the request) 620 A.2. LDAP Protocol Mechanism Registration Template 622 Subject: Request for LDAP Protocol Mechanism Registration 624 Object Identifier: 626 Description: 628 Person & email address to contact for further information: 630 Usage: (One of Control or Extension or Feature or other) 632 Specification: (RFC, I-D, URI) 634 Author/Change Controller: 636 Comments: 638 (Any comments that the requester deems relevant to the request) 640 A.3. LDAP Syntax Registration Template 642 Subject: Request for LDAP Syntax Registration 644 Object Identifier: 646 Description: 648 Person & email address to contact for further information: 650 Specification: (RFC, I-D, URI) 652 Author/Change Controller: 654 Comments: 656 (Any comments that the requester deems relevant to the request) 658 A.4. LDAP Descriptor Registration Template 660 Subject: Request for LDAP Descriptor Registration 662 Descriptor (short name): 664 Object Identifier: 666 Person & email address to contact for further information: 668 Usage: (One of administrative role, attribute type, matching rule, 669 name form, object class, URL extension, or other) 671 Specification: (RFC, I-D, URI) 673 Author/Change Controller: 675 Comments: 677 (Any comments that the requester deems relevant to the request) 679 A.5. LDAP Attribute Description Option Registration Template 681 Subject: Request for LDAP Attribute Description Option Registration 683 Option Name: 685 Family of Options: (YES or NO) 686 Person & email address to contact for further information: 688 Specification: (RFC, I-D, URI) 690 Author/Change Controller: 692 Comments: 694 (Any comments that the requester deems relevant to the request) 696 A.6. LDAP Message Type Registration Template 698 Subject: Request for LDAP Message Type Registration 700 LDAP Message Name: 702 Person & email address to contact for further information: 704 Specification: (Approved I-D) 706 Comments: 708 (Any comments that the requester deems relevant to the request) 710 A.7. LDAP Authentication Method Registration Template 712 Subject: Request for LDAP Authentication Method Registration 714 Authentication Method Name: 716 Person & email address to contact for further information: 718 Specification: (RFC, I-D, URI) 720 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 722 Author/Change Controller: 724 Comments: 726 (Any comments that the requester deems relevant to the request) 728 A.8. LDAP Result Code Registration Template 730 Subject: Request for LDAP Result Code Registration 731 Result Code Name: 733 Person & email address to contact for further information: 735 Specification: (RFC, I-D, URI) 737 Author/Change Controller: 739 Comments: 741 (Any comments that the requester deems relevant to the request) 743 A.8. LDAP Search Scope Registration Template 745 Subject: Request for LDAP Search Scope Registration 747 Search Scope Name: 749 Filter Scope String: 751 Person & email address to contact for further information: 753 Specification: (RFC, I-D, URI) 755 Author/Change Controller: 757 Comments: 759 (Any comments that the requester deems relevant to the request) 761 A.9. LDAP Filter Choice Registration Template 763 Subject: Request for LDAP Filter Choice Registration 765 Filter Choice Name: 767 Person & email address to contact for further information: 769 Specification: (RFC, I-D, URI) 771 Author/Change Controller: 773 Comments: 775 (Any comments that the requester deems relevant to the request) 777 A.10. LDAP ModifyRequest Operation Registration Template 779 Subject: Request for LDAP ModifyRequest Operation Registration 781 ModifyRequest Operation Name: 783 Person & email address to contact for further information: 785 Specification: (RFC, I-D, URI) 787 Author/Change Controller: 789 Comments: 791 (Any comments that the requester deems relevant to the request) 793 Appendix B. Changes since RFC 3383 795 This informative appendix provides a summary of changes made since RFC 796 3383. 798 - Object Identifier Descriptors practices were updated to require 799 all descriptors defined in RFCs to be registered and 800 recommending all other descriptors (excepting those in 801 private-use name space) be registered. Additionally, all 802 requests for multiple registrations of the same descriptor are 803 now subject to Expert Review. 805 - Protocol Mechanisms practices were updated to include values of 806 the 'supportedFeatures' attribute type. 808 - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest 809 operation, and authzId prefixes registries were added. 810 [[Initial values provided in Appendix C. This Appendix is to be 811 removed by the RFC Editor before publication as an RFC.]] 813 - References to RFCs comprising the LDAP technical specifications 814 have been updated to latest revisions. 816 - References to ISO 10646 have been replaced with [Unicode]. 818 - The "Assigned Values" appendix providing initial registry values 819 was removed. 821 - Numerous editorial changes were made. 823 Appendix C. Initial Values for new registries 825 This appendix provides initial values for new registries. 827 C.1. LDAP Syntaxes 829 Object Identifier Syntax Owner Reference 830 ----------------------------- -------------------------- ----- --- 831 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes] 832 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes] 833 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes] 834 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes] 835 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes] 836 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes] 837 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes] 838 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes] 839 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes] 840 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes] 841 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes] 842 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes] 843 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes] 844 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes] 845 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes] 846 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes] 847 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes] 848 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes] 849 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes] 850 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes] 851 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes] 852 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes] 853 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes] 854 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes] 855 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes] 856 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes] 857 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes] 858 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes] 859 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes] 860 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes] 861 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes] 862 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes] 863 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes] 864 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes] 866 C.2. LDAP Search Scopes 868 Name URLString Value Owner Reference 869 ---------------- --------- ----- ----- ------------------- 870 baseObject base 0 IESG [Protocol][LDAPURL] 871 singleLevel one 1 IESG [Protocol][LDAPURL] 872 wholeSubtree sub 2 IESG [Protocol][LDAPURL] 874 C.3. LDAP Filter Choices 876 Name Value Owner Reference 877 ---------------- ----- ----- --------- 878 and 0 IESG [Protocol] 879 or 1 IESG [Protocol] 880 not 2 IESG [Protocol] 881 equalityMatch 3 IESG [Protocol] 882 substrings 4 IESG [Protocol] 883 greaterOrEqual 5 IESG [Protocol] 884 lessOrEqual 6 IESG [Protocol] 885 present 7 IESG [Protocol] 886 approxMatch 8 IESG [Protocol] 887 extensibleMatch 9 IESG [Protocol] 889 C.4. LDAP ModifyRequest Operations 891 Name Value Owner Reference 892 ---------------- ----- ----- --------- 893 add 0 IESG [Protocol] 894 delete 1 IESG [Protocol] 895 replace 2 IESG [Protocol] 897 C.5. LDAP authzId prefixes 899 Name Prefix Owner Reference 900 ---------------- ------ ----- --------- 901 dnAuthzId dn: IESG [AuthMeth] 902 uAuthzId u: IESG [AuthMeth] 904 Full Copyright 906 Copyright (C) The Internet Society (2005). This document is subject 907 to the rights, licenses and restrictions contained in BCP 78, and 908 except as set forth therein, the authors retain all their rights. 910 This document and the information contained herein are provided on an 911 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 912 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 913 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 914 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 915 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Intellectual Property Rights 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be found 927 in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this specification 933 can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org.