idnits 2.17.1 draft-ietf-ldapbis-bcp64-03.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 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 706. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 674), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (4 June 2004) is 7266 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) == Missing Reference: 'UTF-8' is mentioned on line 122, but not defined == Missing Reference: 'RFC3674' is mentioned on line 170, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Unused Reference: 'RFC3629' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'Features' is defined on line 473, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3674 (ref. 'Features') (Obsoleted by RFC 4512) -- 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-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- 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-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-sasl-rfc2222bis-xx - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 7 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: BCP OpenLDAP Foundation 4 Expires in six months 4 June 2004 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, and any of which I become aware will be disclosed, in 25 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/ietf/1id-abstracts.txt. The list of 38 Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright (C) The Internet Society (2004). 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 [RFC2234]. These syntaxes rely on the following common productions: 104 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 106 LDIGIT = %x31-39 ; 1-9 108 DIGIT = %x30 / LDIGIT ; 0-9 110 HYPHEN = %x2D ; "-" 112 DOT = %x2E ; "." 114 number = DIGIT / ( LDIGIT 1*DIGIT ) 116 keychar = ALPHA / DIGIT / HYPHEN 118 leadkeychar = ALPHA 120 keystring = leadkeychar *keychar 122 A keyword is a case-insensitive string of UTF-8 [UTF-8] encoded 123 Unicode [Unicode] restricted to the production. 125 3. IANA Considerations for LDAP 127 This section details each kind of protocol value which can be 128 registered and provides IANA guidelines on how to assign new values. 130 IANA may reject obviously bogus registrations described. 132 3.1. Object Identifiers 134 Numerous LDAP schema and protocol elements are identified by Object 135 Identifiers (OIDs) [X.680]. Specifications which assign OIDs to 136 elements SHOULD state who delegated the OIDs for its use. 138 For IETF developed elements, specifications SHOULD use OIDs under 139 "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed 140 by others, any properly delegated OID can be used, including those 141 under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private 142 Enterprise Numbers" (1.3.6.1.4.1.x). 144 Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert 145 Review with Specification Required. Only one OID per specification 146 will be assigned. The specification MAY then assign any number of 147 OIDs within this arc without further coordination with IANA. 149 Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by 150 IANA . 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. 158 Experimental OIDs SHALL NOT be used in published specifications (e.g. 159 RFCs). 161 Practices for IANA assignment of Internet Enterprise and Experimental 162 OIDs are detailed in STD 16 [RFC1155]. 164 3.2 Protocol Mechanisms 166 LDAP provides a number of Root DSE attributes for discovery of 167 protocol mechanisms identified by OIDs, including: 168 - supportedControl [Models], 169 - supportedExtension [Models], and 170 - supportedFeatures [RFC3674], 172 A registry of OIDs used for discover of protocol mechanisms is 173 provided to allow implementors and others to locate the technical 174 specification for these protocol mechanisms. Future specifications 175 of additional Root DSE attributes holding values identifying protocol 176 mechanisms MAY extend this registry for their values. 178 OIDs associated with discoverable protocol mechanisms SHOULD be 179 registered. These are be considered on a First Come First Served 180 with Specification Required basis. 182 OIDs associated with Standard Track mechanisms MUST be registered and 183 require Standards Action. 185 3.3. Object Identifier Descriptors 187 LDAP allows short descriptive names (or descriptors) to be used 188 instead of a numeric Object Identifier to identify protocol 189 extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] 190 extensions, and other objects. 192 Descriptors SHOULD be registered unless in private-use name space 193 (e.g., they begin with "x-"). Descriptors defined in RFCs MUST be 194 registered. 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 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.4. 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.5. 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.6. LDAP Result Codes 285 LDAP result messages carry an resultCode enumerated value to indicate 286 the outcome of the operation [Protocol]. Each result code consists 287 of a ASN.1 identifier in the form of a keyword and a non-negative 288 integer. 290 New resultCodes integers in the range 0-1023 require Standards Action 291 to be registered. New resultCode integers in the range 1024-4095 292 require Expert Review with Specification Required. New resultCode 293 integers in the range 4096-16383 will be registered on a First Come 294 First Served basis. Keywords associated with integers in the range 295 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 296 integers in the range 4096-16383 SHALL start with "e-". Values 297 greater than or equal to 16384 and keywords starting with "x-" are 298 for Private Use and cannot be registered. 300 3.7. LDAP Authentication Method 302 The LDAP Bind operation supports multiple authentication methods 303 [Protocol]. Each authentication choice consists of an ASN.1 304 identifier in the form of a keyword and a non-negative integer. 306 The registrant SHALL classify the authentication method usage using 307 one of the following terms: 309 COMMON - method is appropriate for common use on the 310 Internet, 311 LIMITED USE - method is appropriate for limited use, 312 OBSOLETE - method has been deprecated or otherwise found to be 313 inappropriate for any use. 315 Methods without publicly available specifications SHALL NOT be 316 classified as COMMON. New registrations of class OBSOLETE cannot be 317 registered. 319 New authentication method integers in the range 0-1023 require 320 Standards Action to be registered. New authentication method 321 integers in the range 1024-4095 require Expert Review with 322 Specification Required. New authentication method integers in the 323 range 4096-16383 will be registered on a First Come First Served 324 basis. Keywords associated with integers in the range 0-4095 SHALL 325 NOT start with "e-" or "x-". Keywords associated with integers in 326 the range 4096-16383 SHALL start with "e-". Values greater than or 327 equal to 16384 and keywords starting with "x-" are for Private Use 328 and cannot be registered. 330 Note: LDAP supports Simple Authentication and Security Layers [SASL] 331 as an authentication choice. SASL is an extensible 332 authentication framework. 334 3.8. Directory Systems Names 336 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 337 valid keywords for well known attributes was used in the LDAPv2 338 string representation of a distinguished name [RFC1779]. LDAPv2 is 339 now Historic [RFC3494]. 341 Directory systems names are not known to be used in any other 342 context. LDAPv3 uses Object Identifier Descriptors [Section 3.2] 343 (which have a different syntax than directory system names). 345 New Directory System Names will no longer be accepted. For 346 historical purposes, the current list of registered names should 347 remain publicly available. 349 4. Registration Procedure 351 The procedure given here MUST be used by anyone who wishes to use a 352 new value of a type described in Section 3 of this document. 354 The first step is for the requester to fill out the appropriate form. 355 Templates are provided in Appendix A. 357 If the policy is Standards Action, the completed form SHOULD be 358 provided to the IESG with the request for Standards Action. Upon 359 approval of the Standards Action, the IESG SHALL forward the request 360 (possibly revised) to IANA. The IESG SHALL be viewed as the owner of 361 all values requiring Standards Action. 363 If the policy is Expert Review, the requester SHALL post the 364 completed form to the mailing list for 365 public review. The review period is two (2) weeks. If a revised 366 form is later submitted, the review period is restarted. Anyone may 367 subscribe to this list by sending a request to 368 . During the review, objections may 369 be raised by anyone (including the Expert) on the list. After 370 completion of the review, the Expert, based upon public comments, 371 SHALL either approve the request and forward it to the IESG OR deny 372 the request. In either case, the Expert SHALL promptly notify the 373 requester of the action. Actions of the Expert may be appealed 374 [RFC2026]. The Expert is appointed by Applications Area Director(s). 375 The requester is viewed as the owner of values registered under 376 Expert Review. 378 If the policy is First Come First Served, the requester SHALL submit 379 the completed form directly to the IANA: . The 380 requester is viewed as the owner of values registered under First 381 Come First Served. 383 Neither the Expert nor IANA will take position on the claims of 384 copyright or trademarks issues regarding completed forms. 386 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 387 after IESG review and tentative approval, the document editor SHOULD 388 revise the I-D to use registered values. 390 5. Registration Maintenance 392 This section discusses maintenance of registrations. 394 5.1. Lists of Registered Values 396 IANA makes lists of registered values readily available to the 397 Internet community on their web site: . 399 5.2. Change Control 401 The registration owner MAY update the registration subject to the 402 same constraints and review as with new registrations. In cases 403 where the owner is not unable or unwilling to make necessary updates, 404 the IESG MAY assert ownership in order to update the registration. 406 5.3. Comments 408 For cases where others (anyone other than the owner) have significant 409 objections to the claims in a registration and the owner does not 410 agree to change the registration, comments MAY be attached to a 411 registration upon Expert Review. For registrations owned by the 412 IESG, the objections SHOULD be addressed by initiating a request for 413 Expert Review. 415 The form to these requests is ad hoc, but MUST include the specific 416 objections to be reviewed and SHOULD contain (directly or by 417 reference) materials supporting the objections. 419 6. Security Considerations 421 The security considerations detailed in BCP 26 [RFC2434] are 422 generally applicable to this document. Additional security 423 considerations specific to each name space are discussed in Section 3 424 where appropriate. 426 Security considerations for LDAP are discussed in documents 427 comprising the technical specification [Roadmap]. 429 7. Acknowledgment 431 This document is a product of the IETF LDAP Revision (LDAPBIS) 432 Working Group (WG). This document is a revision of RFC 3383, also a 433 product of the LDAPBIS WG. 435 This document includes text borrowed from "Guidelines for Writing an 436 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 437 Harald Alvestrand. 439 8. Author's Address 441 Kurt D. Zeilenga 442 OpenLDAP Foundation 444 Email: Kurt@OpenLDAP.org 446 9. References 448 [[Note to the RFC Editor: please replace the citation tags used in 449 referencing Internet-Drafts with tags of the form RFCnnnn.]] 451 9.1. Normative References 453 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 454 Identification of Management Information for TCP/IP- 455 based Internets", STD 16 (also RFC 1155), May 1990. 457 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 458 3", BCP 9 (also RFC 2026), October 1996. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 463 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 464 Specifications: ABNF", RFC 2234, November 1997. 466 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 467 IANA Considerations Section in RFCs", BCP 26 (also RFC 468 2434), October 1998. 470 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 471 10646", RFC 3629 (also STD 63), November 2003. 473 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 474 December 2003. 476 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 477 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 478 progress. 480 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 481 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 483 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 484 Models", draft-ietf-ldapbis-models-xx.txt, a work in 485 progress. 487 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 488 draft-ietf-ldapbis-url-xx.txt, a work in progress. 490 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 491 3.2.0" is defined by "The Unicode Standard, Version 3.0" 492 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 493 as amended by the "Unicode Standard Annex #27: Unicode 494 3.1" (http://www.unicode.org/reports/tr27/) and by the 495 "Unicode Standard Annex #28: Unicode 3.2" 496 (http://www.unicode.org/reports/tr28/). 498 [X.680] International Telecommunication Union - 499 Telecommunication Standardization Sector, "Abstract 500 Syntax Notation One (ASN.1) - Specification of Basic 501 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 503 9.2. Informative References 505 [RFC1779] Kille, S., "A String Representation of Distinguished 506 Names", RFC 1779, March 1995. 508 [IANADSN] IANA, "Directory Systems Names", 509 http://www.iana.org/assignments/directory-system-names. 511 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 512 version 2 (LDAPv2) to Historic Status", RFC 3494, March 513 2003. 515 [SASL] Melnikov, A. (Editor), "Simple Authentication and 516 Security Layer (SASL)", 517 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 519 Appendix A. Registration Templates 521 This appendix provides registration templates for registering new 522 LDAP values. 524 A.1. LDAP Object Identifier Registration Template 526 Subject: Request for LDAP OID Registration 528 Person & email address to contact for further information: 530 Specification: (I-D) 532 Author/Change Controller: 534 Comments: 536 (Any comments that the requester deems relevant to the request) 538 A.2. LDAP Protocol Mechanism Registration Template 540 Subject: Request for LDAP Protocol Mechanism Registration 542 Object Identifier: 544 Description: 546 Person & email address to contact for further information: 548 Usage: (One of Control or Extension or Feature) 550 Specification: (I-D) 552 Author/Change Controller: 554 Comments: 556 (Any comments that the requester deems relevant to the request) 558 A.3. LDAP Descriptor Registration Template 560 Subject: Request for LDAP Descriptor Registration 562 Descriptor (short name): 564 Object Identifier: 566 Person & email address to contact for further information: 568 Usage: (One of attribute type, URL extension, object class, 569 or other) 571 Specification: (RFC, I-D, URI) 573 Author/Change Controller: 575 Comments: 577 (Any comments that the requester deems relevant to the request) 579 A.4. LDAP Attribute Description Option Registration Template 581 Subject: Request for LDAP Attribute Description Option Registration 583 Option Name: 585 Family of Options: (YES or NO) 587 Person & email address to contact for further information: 589 Specification: (RFC, I-D, URI) 591 Author/Change Controller: 593 Comments: 595 (Any comments that the requester deems relevant to the request) 597 A.5. LDAP Message Type Registration Template 599 Subject: Request for LDAP Message Type Registration 601 LDAP Message Name: 603 Person & email address to contact for further information: 605 Specification: (Approved I-D) 607 Comments: 609 (Any comments that the requester deems relevant to the request) 611 A.6. LDAP Result Code Registration Template 613 Subject: Request for LDAP Result Code Registration 615 Result Code Name: 617 Person & email address to contact for further information: 619 Specification: (RFC, I-D, URI) 621 Author/Change Controller: 623 Comments: 625 (Any comments that the requester deems relevant to the request) 627 A.7. LDAP Authentication Method Registration Template 629 Subject: Request for LDAP Authentication Method Registration 631 Authentication Method Name: 633 Person & email address to contact for further information: 635 Specification: (RFC, I-D, URI) 637 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 639 Author/Change Controller: 641 Comments: 643 (Any comments that the requester deems relevant to the request) 645 Appendix B. Changes since RFC 3383 647 This informative appendix provides a summary of changes made since RFC 648 3383. 650 - Object Identifier Descriptors practices were updated to require 651 all descriptors defined in RFCs to be registered and 652 recommending all other descriptors (excepting those in 653 private-use name space) be registered. Additionally, all 654 requests for multiple registrations of the same descriptor are 655 now subject to Expert Review. 657 - Protocol Mechanisms practices were updated to include values of 658 the 'supportedFeatures' attribute type. 660 - References to RFCs comprising the LDAP technical specifications 661 have been updated to latest revisions. 663 - References to ISO 10646 have been replaced with [Unicode]. 665 - The "Assigned Values" appendix providing initial registry values 666 was removed. 668 - Numerous editorial changes were made. 670 Full Copyright 672 Copyright (C) The Internet Society (2004). This document is subject 673 to the rights, licenses and restrictions contained in BCP 78, and 674 except as set forth therein, the authors retain all their rights. 676 This document and the information contained herein are provided on an 677 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 678 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 679 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 680 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 681 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 682 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 684 Intellectual Property Rights 686 The IETF takes no position regarding the validity or scope of any 687 Intellectual Property Rights or other rights that might be claimed to 688 pertain to the implementation or use of the technology described in 689 this document or the extent to which any license under such rights 690 might or might not be available; nor does it represent that it has 691 made any independent effort to identify any such rights. Information 692 on the procedures with respect to rights in RFC documents can be found 693 in BCP 78 and BCP 79. 695 Copies of IPR disclosures made to the IETF Secretariat and any 696 assurances of licenses to be made available, or the result of an 697 attempt made to obtain a general license or permission for the use of 698 such proprietary rights by implementers or users of this specification 699 can be obtained from the IETF on-line IPR repository at 700 http://www.ietf.org/ipr. 702 The IETF invites any interested party to bring to its attention any 703 copyrights, patents or patent applications, or other proprietary 704 rights that may cover technology that may be required to implement 705 this standard. Please address the information to the IETF at 706 ietf-ipr@ietf.org.