idnits 2.17.1 draft-ietf-ldapbis-bcp64-06.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 3978, Section 5.1 on line 24. -- 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 904), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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. 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 (23 January 2006) is 6640 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- 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: 8 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 23 January 2006 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, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright (C) The Internet Society (2006). All Rights Reserved. 43 Please see the Full Copyright section near the end of this document 44 for more information. 46 Abstract 48 This document provides procedures for registering extensible elements 49 of Lightweight Directory Access Protocol (LDAP). The document also 50 provides guidelines to Internet Assigned Numbers Authority (IANA) 51 describing conditions under which new values can be assigned. 53 1. Introduction 55 The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an 56 extensible protocol. LDAP supports: 58 - addition of new operations, 59 - extension of existing operations, and 60 - extensible schema. 62 This document details procedures for registering values of used to 63 unambiguously identify extensible elements of the protocol including: 65 - LDAP message types; 66 - LDAP extended operations and controls; 67 - LDAP result codes; 68 - LDAP authentication methods; 69 - LDAP attribute description options; and 70 - Object Identifier descriptors. 72 These registries are maintained by the Internet Assigned Numbers 73 Authority (IANA). 75 In addition, this document provides guidelines to IANA describing the 76 conditions under which new values can be assigned. 78 This document replaces RFC 3383. 80 2. Terminology and Conventions 82 This section details terms and conventions used in this document. 84 2.1. Policy Terminology 86 The terms "IESG Approval", "Standards Action", "IETF Consensus", 87 "Specification Required", "First Come First Served", "Expert Review", 88 and "Private Use" are used as defined in BCP 26 [RFC2434]. 90 2.2. Requirement Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in BCP 14 [RFC2119]. In 95 this case, "the specification" as used by BCP 14 refers to the 96 processing of protocols being submitted to the IETF standards 97 process. 99 2.3. Common ABNF Productions 101 A number of syntaxes in this document are described using ABNF 102 [ABNF]. These syntaxes rely on the following common productions: 104 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 105 LDIGIT = %x31-39 ; "1"-"9" 106 DIGIT = %x30 / LDIGIT ; "0"-"9" 107 HYPHEN = %x2D ; "-" 108 DOT = %x2E ; "." 109 number = DIGIT / ( LDIGIT 1*DIGIT ) 110 keychar = ALPHA / DIGIT / HYPHEN 111 leadkeychar = ALPHA 112 keystring = leadkeychar *keychar 114 A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded 115 Unicode [Unicode] restricted to the production. 117 3. IANA Considerations for LDAP 119 This section details each kind of protocol value which can be 120 registered and provides IANA guidelines on how to assign new values. 122 IANA may reject obviously bogus registrations. 124 LDAP values specified in RFCs MUST be registered. Other LDAP values, 125 except those in private-use name spaces, SHOULD be registered. RFCs 126 SHOULD NOT reference, use, or otherwise recognize unregistered LDAP 127 values. 129 3.1. Object Identifiers 131 Numerous LDAP schema and protocol elements are identified by Object 132 Identifiers (OIDs) [X.680]. Specifications which assign OIDs to 133 elements SHOULD state who delegated the OIDs for its use. 135 For IETF developed elements, specifications SHOULD use OIDs under 136 "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed 137 by others, any properly delegated OID can be used, including those 138 under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private 139 Enterprise Numbers" (1.3.6.1.4.1.x). 141 Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert 142 Review with Specification Required. Only one OID per specification 143 will be assigned. The specification MAY then assign any number of 144 OIDs within this arc without further coordination with IANA. 146 Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by 147 IANA . Practices for IANA 148 assignment of Internet Private Enterprise Numbers is detailed in RFC 149 2578 [RFC2578]. 151 To avoid interoperability problems between early implementations of a 152 "work in progress" and implementations of the published specification 153 (e.g., the RFC), experimental OIDs SHOULD be used in "works in 154 progress" and early implementations. OIDs under the Internet 155 Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 156 Practices for IANA assignment of these Internet Experimental numbers 157 is detailed in RFC 2578 [RFC2578] 159 3.2 Protocol Mechanisms 161 LDAP provides a number of Root DSE attributes for discovery of 162 protocol mechanisms identified by OIDs, including the 163 supportedControl, supportedExtension, and supportedFeatures 164 attributes [Models], 166 A registry of OIDs used for discover of protocol mechanisms is 167 provided to allow implementors and others to locate the technical 168 specification for these protocol mechanisms. Future specifications 169 of additional Root DSE attributes holding values identifying protocol 170 mechanisms MAY extend this registry for their values. 172 Protocol Mechanisms are registered on a First Come First Served 173 basis. 175 3.3 LDAP Syntaxes 177 This registry provides a listing of LDAP syntaxes [Models]. Each 178 LDAP syntax is identified by an object identifier (OID). This 179 registry is provided to allow implementors and others to locate the 180 technical specification describing a particular LDAP Syntax. 182 LDAP Syntaxes are registered on a First Come First Served with 183 Specification Required basis. 185 Note: unlike object classes, attribute types and various other kinds 186 of schema elements, descriptors are not used in LDAP to identify LDAP 187 Syntaxes. 189 3.4. Object Identifier Descriptors 191 LDAP allows short descriptive names (or descriptors) to be used 192 instead of a numeric Object Identifier to identify select protocol 193 extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] 194 extensions, and other objects. 196 While the protocol allows the same descriptor to refer to different 197 object identifiers in certain cases and the registry supports 198 multiple registrations of the same descriptor (each indicating a 199 different kind of schema element and different object identifier), 200 multiple registrations of the same descriptor are to be avoided. All 201 such multiple registration requests require Expert Review. 203 Descriptors are restricted to strings of UTF-8 encoded Unicode 204 characters restricted by the following ABNF: 206 name = keystring 208 Descriptors are case-insensitive. 210 Multiple names may be assigned to a given OID. For purposes of 211 registration, an OID is to be represented in numeric OID form (e.g., 212 1.1.0.23.40) conforming to the ABNF: 214 numericoid = number 1*( DOT number ) 216 While the protocol places no maximum length restriction upon 217 descriptors, they should be short. Descriptors longer than 48 218 characters may be viewed as too long to register. 220 A value ending with a hyphen ("-") reserves all descriptors which 221 start with that value. For example, the registration of the option 222 "descrFamily-" reserves all options which start with "descrFamily-" 223 for some related purpose. 225 Descriptors beginning with "x-" are for Private Use and cannot be 226 registered. 228 Descriptors beginning with "e-" are reserved for experiments and will 229 be registered on a First Come First Served basis. 231 All other descriptors require Expert Review to be registered. 233 The registrant need not "own" the OID being named. 235 The OID name space is managed by The ISO/IEC Joint Technical 236 Committee 1 - Subcommittee 6. 238 3.5. AttributeDescription Options 240 An AttributeDescription [Models] can contain zero or more options 241 specifying additional semantics. An option SHALL be restricted to a 242 string UTF-8 encoded Unicode characters limited by the following 243 ABNF: 245 option = keystring 247 Options are case-insensitive. 249 While the protocol places no maximum length restriction upon option 250 strings, they should be short. Options longer than 24 characters may 251 be viewed as too long to register. 253 Values ending with a hyphen ("-") reserve all option names which 254 start with the name. For example, the registration of the option 255 "optionFamily-" reserves all options which start with "optionFamily-" 256 for some related purpose. 258 Options beginning with "x-" are for Private Use and cannot be 259 registered. 261 Options beginning with "e-" are reserved for experiments and will be 262 registered on a First Come First Served basis. 264 All other options require Standards Action or Expert Review with 265 Specification Required to be registered. 267 3.6. LDAP Message Types 269 Each protocol message is encapsulated in an LDAPMessage envelope 270 [Protocol]. The protocolOp CHOICE indicates the type of message 271 encapsulated. Each message type consists of an ASN.1 identifier in 272 the form of a keyword and a non-negative choice number. The choice 273 number is combined with the class (APPLICATION) and data type 274 (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's 275 encoding. The choice numbers for existing protocol messages are 276 implicit in the protocol's ASN.1 defined in [Protocol]. 278 New values will be registered upon Standards Action. 280 Note: LDAP provides extensible messages which reduces, but does not 281 eliminate, the need to add new message types. 283 3.7. LDAP Authentication Method 285 The LDAP Bind operation supports multiple authentication methods 286 [Protocol]. Each authentication choice consists of an ASN.1 287 identifier in the form of a keyword and a non-negative integer. 289 The registrant SHALL classify the authentication method usage using 290 one of the following terms: 292 COMMON - method is appropriate for common use on the 293 Internet, 294 LIMITED USE - method is appropriate for limited use, 295 OBSOLETE - method has been deprecated or otherwise found to 296 be inappropriate for any use. 298 Methods without publicly available specifications SHALL NOT be 299 classified as COMMON. New registrations of class OBSOLETE cannot be 300 registered. 302 New authentication method integers in the range 0-1023 require 303 Standards Action to be registered. New authentication method 304 integers in the range 1024-4095 require Expert Review with 305 Specification Required. New authentication method integers in the 306 range 4096-16383 will be registered on a First Come First Served 307 basis. Keywords associated with integers in the range 0-4095 SHALL 308 NOT start with "e-" or "x-". Keywords associated with integers in 309 the range 4096-16383 SHALL start with "e-". Values greater than or 310 equal to 16384 and keywords starting with "x-" are for Private Use 311 and cannot be registered. 313 Note: LDAP supports Simple Authentication and Security Layers [SASL] 314 as an authentication choice. SASL is an extensible 315 authentication framework. 317 3.8. LDAP Result Codes 319 LDAP result messages carry an resultCode enumerated value to indicate 320 the outcome of the operation [Protocol]. Each result code consists 321 of a ASN.1 identifier in the form of a keyword and a non-negative 322 integer. 324 New resultCodes integers in the range 0-1023 require Standards Action 325 to be registered. New resultCode integers in the range 1024-4095 326 require Expert Review with Specification Required. New resultCode 327 integers in the range 4096-16383 will be registered on a First Come 328 First Served basis. Keywords associated with integers in the range 329 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 330 integers in the range 4096-16383 SHALL start with "e-". Values 331 greater than or equal to 16384 and keywords starting with "x-" are 332 for Private Use and cannot be registered. 334 3.9. LDAP Search Scope 336 LDAP SearchRequest messages carry a scope enumerated value to 337 indicate the extend of search within the DIT [Protocol] Each search 338 value consists of a ASN.1 identifier in the form of a keyword and a 339 non-negative integer. 341 New scope integers in the range 0-1023 require Standards Action to be 342 registered. New scope integers in the range 1024-4095 require Expert 343 Review with Specification Required. New scope integers in the range 344 4096-16383 will be registered on a First Come First Served basis. 345 Keywords associated with integers in the range 0-4095 SHALL NOT start 346 with "e-" or "x-". Keywords associated with integers in the range 347 4096-16383 SHALL start with "e-". Values greater than or equal to 348 16384 and keywords starting with "x-" are for Private Use and cannot 349 be registered. 351 3.10. LDAP Filter Choice 353 LDAP filters are used in making assertions against an object 354 represented in the directory [Protocol]. The Filter CHOICE indicates 355 a type of assertion. Each Filter CHOICE consists of an ASN.1 356 identifier in the form of a keyword and a non-negative choice number. 357 The choice number is combined with the class (APPLICATION) and data 358 type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the 359 message's encoding. 361 Note: LDAP provides the extensibleMatching choice which reduces, but 362 does not eliminate, the need to add new filter choices. 364 3.11. LDAP ModifyRequest Operation Type 365 The LDAP ModifyRequest carries a sequence of modification operations 366 [Protocol]. Each kind (e.g., add, delete, replace) of operation is 367 consists of a ASN.1 identifier in the form of a keyword and a 368 non-negative integer. 370 New operation type integers in the range 0-1023 require Standards 371 Action to be registered. New operation type integers in the range 372 1024-4095 require Expert Review with Specification Required. New 373 operation type integers in the range 4096-16383 will be registered on 374 a First Come First Served basis. Keywords associated with integers 375 in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords 376 associated with integers in the range 4096-16383 SHALL start with 377 "e-". Values greater than or equal to 16384 and keywords starting 378 with "x-" are for Private Use and cannot be registered. 380 3.12. LDAP authzId Prefixes 382 Authorization Identities in LDAP are strings conforming to the 383 production [AuthMeth]. This production is extensible. 384 Each new specific authorization form is identified by a prefix string 385 conforming to the following ABNF: 387 prefix = keystring COLON 388 COLON = %x3A ; COLON (":" U+003A) 390 Prefixes are case-insensitive. 392 While the protocol places no maximum length restriction upon prefix 393 strings, they should be short. Prefixes longer than 12 characters 394 may be viewed as too long to register. 396 Prefixes beginning with "x-" are for Private Use and cannot be 397 registered. 399 Prefixes beginning with "e-" are reserved for experiments and will be 400 registered on a First Come First Served basis. 402 All other prefixes require Standards Action or Expert Review with 403 Specification Required to be registered. 405 3.13. Directory Systems Names 407 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 408 valid keywords for well known attributes was used in the LDAPv2 409 string representation of a distinguished name [RFC1779]. LDAPv2 is 410 now Historic [RFC3494]. 412 Directory systems names are not known to be used in any other 413 context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section 414 3.2] (which have a different syntax than directory system names). 416 New Directory System Names will no longer be accepted. For 417 historical purposes, the current list of registered names should 418 remain publicly available. 420 4. Registration Procedure 422 The procedure given here MUST be used by anyone who wishes to use a 423 new value of a type described in Section 3 of this document. 425 The first step is for the requester to fill out the appropriate form. 426 Templates are provided in Appendix A. 428 If the policy is Standards Action, the completed form SHOULD be 429 provided to the IESG with the request for Standards Action. Upon 430 approval of the Standards Action, the IESG SHALL forward the request 431 (possibly revised) to IANA. The IESG SHALL be viewed as the owner of 432 all values requiring Standards Action. 434 If the policy is Expert Review, the requester SHALL post the 435 completed form to the mailing list for 436 public review. The review period is two (2) weeks. If a revised 437 form is later submitted, the review period is restarted. Anyone may 438 subscribe to this list by sending a request to 439 . During the review, objections may 440 be raised by anyone (including the Expert) on the list. After 441 completion of the review, the Expert, based upon public comments, 442 SHALL either approve the request and forward it to the IANA OR deny 443 the request. In either case, the Expert SHALL promptly notify the 444 requester of the action. Actions of the Expert may be appealed 445 [RFC2026]. The Expert is appointed by Applications Area Director(s). 446 The requester is viewed as the owner of values registered under 447 Expert Review. 449 If the policy is First Come First Served, the requester SHALL submit 450 the completed form directly to the IANA: . The 451 requester is viewed as the owner of values registered under First 452 Come First Served. 454 Neither the Expert nor IANA will take position on the claims of 455 copyright or trademarks issues regarding completed forms. 457 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 458 after IESG review and tentative approval, the document editor SHOULD 459 revise the I-D to use registered values. 461 5. Registration Maintenance 463 This section discusses maintenance of registrations. 465 5.1. Lists of Registered Values 467 IANA makes lists of registered values readily available to the 468 Internet community on their web site: . 470 5.2. Change Control 472 The registration owner MAY update the registration subject to the 473 same constraints and review as with new registrations. In cases 474 where the owner is not unable or unwilling to make necessary updates, 475 the IESG MAY assume ownership in order to update the registration. 477 5.3. Comments 479 For cases where others (anyone other than the owner) have significant 480 objections to the claims in a registration and the owner does not 481 agree to change the registration, comments MAY be attached to a 482 registration upon Expert Review. For registrations owned by the 483 IESG, the objections SHOULD be addressed by initiating a request for 484 Expert Review. 486 The form to these requests is ad hoc, but MUST include the specific 487 objections to be reviewed and SHOULD contain (directly or by 488 reference) materials supporting the objections. 490 6. Security Considerations 492 The security considerations detailed in BCP 26 [RFC2434] are 493 generally applicable to this document. Additional security 494 considerations specific to each name space are discussed in Section 3 495 where appropriate. 497 Security considerations for LDAP are discussed in documents 498 comprising the technical specification [Roadmap]. 500 7. Acknowledgment 501 This document is a product of the IETF LDAP Revision (LDAPBIS) 502 Working Group (WG). This document is a revision of RFC 3383, also a 503 product of the LDAPBIS WG. 505 This document includes text borrowed from "Guidelines for Writing an 506 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 507 Harald Alvestrand. 509 8. Author's Address 511 Kurt D. Zeilenga 512 OpenLDAP Foundation 514 Email: Kurt@OpenLDAP.org 516 9. References 518 [[Note to the RFC Editor: please replace the citation tags used in 519 referencing Internet-Drafts with tags of the form RFCnnnn where 520 possible.]] 522 9.1. Normative References 524 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 525 3", BCP 9 (also RFC 2026), October 1996. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 530 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 531 IANA Considerations Section in RFCs", BCP 26 (also RFC 532 2434), October 1998. 534 [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure 535 of Management Information Version 2 (SMIv2)", RFC 2578 536 (STD: 58), April 1999. 537 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 538 10646", RFC 3629 (also STD 63), November 2003. 540 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 541 Specifications: ABNF", RFC 4234, October 2005. 543 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 544 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 545 progress. 547 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 548 Connection Level Security Mechanisms", 549 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 551 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 552 Models", draft-ietf-ldapbis-models-xx.txt, a work in 553 progress. 555 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 556 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 558 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 559 draft-ietf-ldapbis-url-xx.txt, a work in progress. 561 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 562 3.2.0" is defined by "The Unicode Standard, Version 3.0" 563 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 564 as amended by the "Unicode Standard Annex #27: Unicode 565 3.1" (http://www.unicode.org/reports/tr27/) and by the 566 "Unicode Standard Annex #28: Unicode 3.2" 567 (http://www.unicode.org/reports/tr28/). 569 [X.680] International Telecommunication Union - 570 Telecommunication Standardization Sector, "Abstract 571 Syntax Notation One (ASN.1) - Specification of Basic 572 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 574 9.2. Informative References 576 [RFC1779] Kille, S., "A String Representation of Distinguished 577 Names", RFC 1779, March 1995. 579 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 580 version 2 (LDAPv2) to Historic Status", RFC 3494, March 581 2003. 583 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 584 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 586 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 587 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a 588 work in progress. 590 [SASL] Melnikov, A. (Editor), "Simple Authentication and 591 Security Layer (SASL)", 592 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 594 [IANADSN] IANA, "Directory Systems Names", 595 http://www.iana.org/assignments/directory-system-names. 597 Appendix A. Registration Templates 599 This appendix provides registration templates for registering new 600 LDAP values. Note that more than one value may be requested by 601 extending the template by listing multiple values, or through use of 602 tables. 604 A.1. LDAP Object Identifier Registration Template 606 Subject: Request for LDAP OID Registration 608 Person & email address to contact for further information: 610 Specification: (I-D) 612 Author/Change Controller: 614 Comments: 616 (Any comments that the requester deems relevant to the request) 618 A.2. LDAP Protocol Mechanism Registration Template 620 Subject: Request for LDAP Protocol Mechanism Registration 622 Object Identifier: 624 Description: 626 Person & email address to contact for further information: 628 Usage: (One of Control or Extension or Feature or other) 630 Specification: (RFC, I-D, URI) 632 Author/Change Controller: 634 Comments: 636 (Any comments that the requester deems relevant to the request) 638 A.3. LDAP Syntax Registration Template 640 Subject: Request for LDAP Syntax Registration 642 Object Identifier: 644 Description: 646 Person & email address to contact for further information: 648 Specification: (RFC, I-D, URI) 650 Author/Change Controller: 652 Comments: 654 (Any comments that the requester deems relevant to the request) 656 A.4. LDAP Descriptor Registration Template 658 Subject: Request for LDAP Descriptor Registration 660 Descriptor (short name): 662 Object Identifier: 664 Person & email address to contact for further information: 666 Usage: (One of administrative role, attribute type, matching rule, 667 name form, object class, URL extension, or other) 669 Specification: (RFC, I-D, URI) 671 Author/Change Controller: 673 Comments: 675 (Any comments that the requester deems relevant to the request) 677 A.5. LDAP Attribute Description Option Registration Template 679 Subject: Request for LDAP Attribute Description Option Registration 681 Option Name: 683 Family of Options: (YES or NO) 684 Person & email address to contact for further information: 686 Specification: (RFC, I-D, URI) 688 Author/Change Controller: 690 Comments: 692 (Any comments that the requester deems relevant to the request) 694 A.6. LDAP Message Type Registration Template 696 Subject: Request for LDAP Message Type Registration 698 LDAP Message Name: 700 Person & email address to contact for further information: 702 Specification: (Approved I-D) 704 Comments: 706 (Any comments that the requester deems relevant to the request) 708 A.7. LDAP Authentication Method Registration Template 710 Subject: Request for LDAP Authentication Method Registration 712 Authentication Method Name: 714 Person & email address to contact for further information: 716 Specification: (RFC, I-D, URI) 718 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 720 Author/Change Controller: 722 Comments: 724 (Any comments that the requester deems relevant to the request) 726 A.8. LDAP Result Code Registration Template 728 Subject: Request for LDAP Result Code Registration 729 Result Code Name: 731 Person & email address to contact for further information: 733 Specification: (RFC, I-D, URI) 735 Author/Change Controller: 737 Comments: 739 (Any comments that the requester deems relevant to the request) 741 A.8. LDAP Search Scope Registration Template 743 Subject: Request for LDAP Search Scope Registration 745 Search Scope Name: 747 Filter Scope String: 749 Person & email address to contact for further information: 751 Specification: (RFC, I-D, URI) 753 Author/Change Controller: 755 Comments: 757 (Any comments that the requester deems relevant to the request) 759 A.9. LDAP Filter Choice Registration Template 761 Subject: Request for LDAP Filter Choice Registration 763 Filter Choice Name: 765 Person & email address to contact for further information: 767 Specification: (RFC, I-D, URI) 769 Author/Change Controller: 771 Comments: 773 (Any comments that the requester deems relevant to the request) 775 A.10. LDAP ModifyRequest Operation Registration Template 777 Subject: Request for LDAP ModifyRequest Operation Registration 779 ModifyRequest Operation Name: 781 Person & email address to contact for further information: 783 Specification: (RFC, I-D, URI) 785 Author/Change Controller: 787 Comments: 789 (Any comments that the requester deems relevant to the request) 791 Appendix B. Changes since RFC 3383 793 This informative appendix provides a summary of changes made since RFC 794 3383. 796 - Object Identifier Descriptors practices were updated to require 797 all descriptors defined in RFCs to be registered and 798 recommending all other descriptors (excepting those in 799 private-use name space) be registered. Additionally, all 800 requests for multiple registrations of the same descriptor are 801 now subject to Expert Review. 803 - Protocol Mechanisms practices were updated to include values of 804 the 'supportedFeatures' attribute type. 806 - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest 807 operation, and authzId prefixes registries were added. 808 [[Initial values provided in Appendix C. This Appendix is to be 809 removed by the RFC Editor before publication as an RFC.]] 811 - References to RFCs comprising the LDAP technical specifications 812 have been updated to latest revisions. 814 - References to ISO 10646 have been replaced with [Unicode]. 816 - The "Assigned Values" appendix providing initial registry values 817 was removed. 819 - Numerous editorial changes were made. 821 Appendix C. Initial Values for new registries 823 This appendix provides initial values for new registries. 825 C.1. LDAP Syntaxes 827 Object Identifier Syntax Owner Reference 828 ----------------------------- -------------------------- ----- --- 829 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes] 830 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes] 831 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes] 832 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes] 833 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes] 834 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes] 835 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes] 836 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes] 837 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes] 838 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes] 839 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes] 840 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes] 841 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes] 842 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes] 843 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes] 844 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes] 845 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes] 846 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes] 847 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes] 848 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes] 849 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes] 850 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes] 851 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes] 852 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes] 853 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes] 854 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes] 855 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes] 856 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes] 857 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes] 858 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes] 859 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes] 860 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes] 861 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes] 862 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes] 864 C.2. LDAP Search Scopes 866 Name URLString Value Owner Reference 867 ---------------- --------- ----- ----- ------------------- 868 baseObject base 0 IESG [Protocol][LDAPURL] 869 singleLevel one 1 IESG [Protocol][LDAPURL] 870 wholeSubtree sub 2 IESG [Protocol][LDAPURL] 872 C.3. LDAP Filter Choices 874 Name Value Owner Reference 875 ---------------- ----- ----- --------- 876 and 0 IESG [Protocol] 877 or 1 IESG [Protocol] 878 not 2 IESG [Protocol] 879 equalityMatch 3 IESG [Protocol] 880 substrings 4 IESG [Protocol] 881 greaterOrEqual 5 IESG [Protocol] 882 lessOrEqual 6 IESG [Protocol] 883 present 7 IESG [Protocol] 884 approxMatch 8 IESG [Protocol] 885 extensibleMatch 9 IESG [Protocol] 887 C.4. LDAP ModifyRequest Operations 889 Name Value Owner Reference 890 ---------------- ----- ----- --------- 891 add 0 IESG [Protocol] 892 delete 1 IESG [Protocol] 893 replace 2 IESG [Protocol] 895 C.5. LDAP authzId prefixes 897 Name Prefix Owner Reference 898 ---------------- ------ ----- --------- 899 dnAuthzId dn: IESG [AuthMeth] 900 uAuthzId u: IESG [AuthMeth] 902 Full Copyright 904 Copyright (C) The Internet Society (2006). 906 This document is subject to the rights, licenses and restrictions 907 contained in BCP 78, and except as set forth therein, the authors 908 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.