idnits 2.17.1 draft-ietf-ldapbis-bcp64-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 == Line 670 has weird spacing: '...for the purpo...' == 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 (15 February 2004) is 7375 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 118, but not defined == Missing Reference: 'RFC3674' is mentioned on line 164, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Unused Reference: 'RFC3639' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'Features' is defined on line 462, 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) ** Downref: Normative reference to an Informational RFC: RFC 3639 ** 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: 9 errors (**), 0 flaws (~~), 8 warnings (==), 13 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 15 February 2004 5 Obsoletes: RFC 3383 7 IANA Considerations for LDAP 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Best Current Practice 17 document. Distribution of this memo is unlimited. Technical 18 discussion of this document will take place on the IETF LDAP Revision 19 Working Group (LDAPBIS) mailing list . 20 Please send editorial comments directly to the document editor 21 . 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. Internet-Drafts are draft documents valid for a 27 maximum of six months and may be updated, replaced, or obsoleted by 28 other documents at any time. It is inappropriate to use 29 Internet-Drafts as reference material or to cite them other than as 30 ``work in progress.'' 32 The list of current Internet-Drafts can be accessed at 33 . The list of 34 Internet-Draft Shadow Directories can be accessed at 35 . 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Please see the Full Copyright section near the end of this document 40 for more information. 42 Abstract 44 This document provides procedures for registering extensible elements 45 of Lightweight Directory Access Protocol (LDAP). The document also 46 provides guidelines to Internet Assigned Numbers Authority (IANA) 47 describing conditions under which new values can be assigned. 49 1. Introduction 51 The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an 52 extensible protocol. LDAP supports: 54 - addition of new operations, 55 - extension of existing operations, and 56 - extensible schema. 58 This document details procedures for registering values of used to 59 unambiguously identify extensible elements of the protocol including: 61 - LDAP message types; 62 - LDAP extended operations and controls; 63 - LDAP result codes; 64 - LDAP authentication methods; 65 - LDAP attribute description options; and 66 - Object Identifier descriptors. 68 These registries are maintained by the Internet Assigned Numbers 69 Authority (IANA). 71 In addition, this document provides guidelines to IANA describing the 72 conditions under which new values can be assigned. 74 This document replaces RFC 3383. 76 2. Terminology and Conventions 78 This section details terms and conventions used in this document. 80 2.1. Policy Terminology 82 The terms "IESG Approval", "Standards Action", "IETF Consensus", 83 "Specification Required", "First Come First Served", "Expert Review", 84 and "Private Use" are used as defined in BCP 26 [RFC2434]. 86 2.2. Requirement Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in BCP 14 [RFC2119]. In 91 this case, "the specification" as used by BCP 14 refers to the 92 processing of protocols being submitted to the IETF standards 93 process. 95 2.3. Common ABNF Productions 97 A number of syntaxes in this document are described using ABNF 98 [RFC2234]. These syntaxes rely on the following common productions: 100 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 102 LDIGIT = %x31-39 ; 1-9 104 DIGIT = %x30 / LDIGIT ; 0-9 106 HYPHEN = %x2D ; "-" 108 DOT = %x2E ; "." 110 number = DIGIT / ( LDIGIT 1*DIGIT ) 112 keychar = ALPHA / DIGIT / HYPHEN 114 leadkeychar = ALPHA 116 keystring = leadkeychar *keychar 118 A keyword is a case-insensitive string of UTF-8 [UTF-8] encoded 119 Unicode [Unicode] restricted to the production. 121 3. IANA Considerations for LDAP 123 This section details each kind of protocol value which can be 124 registered and provides IANA guidelines on how to assign new values. 126 IANA may reject obviously bogus registrations described. 128 3.1. Object Identifiers 130 Numerous LDAP schema and protocol elements are identified by Object 131 Identifiers (OIDs) [X.680]. Specifications which assign OIDs to 132 elements SHOULD state who delegated the OIDs for its use. 134 For IETF developed elements, specifications SHOULD use OIDs under 135 "Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID 136 arc will be assigned upon Expert Review with Specification Required. 137 Only one OID per specification will be assigned. The specification 138 MAY then assign any number of OIDs within this arc without further 139 coordination with IANA. 141 For elements developed by others, any properly delegated OID can be 142 used, including those under "Internet Private Enterprise Numbers" 143 (1.3.6.1.4.1.x) assigned by IANA 144 . 146 To avoid interoperability problems between early implementations of a 147 "work in progress" and implementations of the published specification 148 (e.g., the RFC), experimental OIDs SHOULD be used in "works in 149 progress" and early implementations. OIDs under the Internet 150 Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 152 Experimental OIDs SHALL NOT be used in published specifications (e.g. 153 RFCs). 155 Practices for IANA assignment of Internet Enterprise and Experimental 156 OIDs are detailed in STD 16 [RFC1155]. 158 3.2 Protocol Mechanisms 160 LDAP provides a number of Root DSE attributes for discovery of 161 protocol mechanisms identified by OIDs, including: 162 - supportedControl [Models], 163 - supportedExtension [Models], and 164 - supportedFeatures [RFC3674], 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 OIDs associated with discoverable protocol mechanisms SHOULD be 173 registered. These are be considered on a First Come First Served 174 with Specification Required basis. 176 OIDs associated with Standard Track mechanisms MUST be registered and 177 require Standards Action. 179 3.3. Object Identifier Descriptors 181 LDAP allows short descriptive names (or descriptors) to be used 182 instead of a numeric Object Identifier to identify protocol 183 extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] 184 extensions, and other objects. 186 Descriptors SHOULD be registered unless in private-use name space 187 (e.g., they begin with "x-"). Descriptors defined in RFCs MUST be 188 registered. 190 While the protocol allows the same descriptor to refer to different 191 object identifiers in certain cases and the registry supports 192 multiple registrations of the same descriptor (each indicating a 193 different kind of schema element and different object identifier), 194 multiple registrations of the same descriptor are to be avoided. All 195 such registration requests require Expert Review. 197 Descriptors are restricted to strings of UTF-8 encoded Unicode 198 characters restricted by the following ABNF: 200 name = keystring 202 Descriptors are case-insensitive. 204 Multiple names may be assigned to a given OID. For purposes of 205 registration, an OID is to be represented in numeric OID form (e.g., 206 1.1.0.23.40) conforming to the ABNF: 208 numericoid = number 1*( DOT number ) 210 While the protocol places no maximum length restriction upon 211 descriptors, they should be short. Descriptors longer than 48 212 characters may be viewed as too long to register. 214 A value ending with a hyphen ("-") reserves all descriptors which 215 start with that value. For example, the registration of the option 216 "descrFamily-" reserves all options which start with "descrFamily-" 217 for some related purpose. 219 Descriptors beginning with "x-" are for Private Use and cannot be 220 registered. 222 Descriptors beginning with "e-" are reserved for experiments and will 223 be registered on a First Come First Served basis. 225 All other descriptors require Expert Review to be registered. 227 The registrant need not "own" the OID being named. 229 The OID name space is managed by The ISO/IEC Joint Technical 230 Committee 1 - Subcommittee 6. 232 3.4. AttributeDescription Options 234 An AttributeDescription [Models] can contain zero or more options 235 specifying additional semantics. An option SHALL be restricted to a 236 string UTF-8 encoded Unicode characters limited by the following 237 ABNF: 239 option = keystring 241 Options are case-insensitive. 243 While the protocol places no maximum length restriction upon option 244 strings, they should be short. Options longer than 24 characters may 245 be viewed as too long to register. 247 Values ending with a hyphen ("-") reserve all option names which 248 start with the name. For example, the registration of the option 249 "optionFamily-" reserves all options which start with "optionFamily-" 250 for some related purpose. 252 Options beginning with "x-" are for Private Use and cannot be 253 registered. 255 Options beginning with "e-" are reserved for experiments and will be 256 registered on a First Come First Served basis. 258 All other options require Standards Action or Expert Review with 259 Specification Required to be registered. 261 3.5. LDAP Message Types 263 Each protocol message is encapsulated in an LDAPMessage envelope 264 [Protocol]. The protocolOp CHOICE indicates the type of message 265 encapsulated. Each message type consists of an ASN.1 identifier in 266 the form of a keyword and a non-negative choice number. The choice 267 number is combined with the class (APPLICATION) and data type 268 (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's 269 encoding. The choice numbers for existing protocol messages are 270 implicit in the protocol's ASN.1 defined in [Protocol]. 272 New values will be registered upon Standards Action. 274 Note: LDAP provides extensible messages which reduces, but does not 275 eliminate, the need to add new message types. 277 3.6. LDAP Result Codes 279 LDAP result messages carry an resultCode enumerated value to indicate 280 the outcome of the operation [Protocol]. Each result code consists 281 of a ASN.1 identifier in the form of a keyword and a non-negative 282 integer. 284 New resultCodes integers in the range 0-1023 require Standards Action 285 to be registered. New resultCode integers in the range 1024-4095 286 require Expert Review with Specification Required. New resultCode 287 integers in the range 4096-16383 will be registered on a First Come 288 First Served basis. Keywords associated with integers in the range 289 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 290 integers in the range 4096-16383 SHALL start with "e-". Values 291 greater than or equal to 16384 and keywords starting with "x-" are 292 for Private Use and cannot be registered. 294 3.7. LDAP Authentication Method 296 The LDAP Bind operation supports multiple authentication methods 297 [Protocol]. Each authentication choice consists of an ASN.1 298 identifier in the form of a keyword and a non-negative integer. 300 The registrant SHALL classify the authentication method usage using 301 one of the following terms: 303 COMMON - method is appropriate for common use on the 304 Internet, 305 LIMITED USE - method is appropriate for limited use, 306 OBSOLETE - method has been deprecated or otherwise found to be 307 inappropriate for any use. 309 Methods without publicly available specifications SHALL NOT be 310 classified as COMMON. New registrations of class OBSOLETE cannot be 311 registered. 313 New authentication method integers in the range 0-1023 require 314 Standards Action to be registered. New authentication method 315 integers in the range 1024-4095 require Expert Review with 316 Specification Required. New authentication method integers in the 317 range 4096-16383 will be registered on a First Come First Served 318 basis. Keywords associated with integers in the range 0-4095 SHALL 319 NOT start with "e-" or "x-". Keywords associated with integers in 320 the range 4096-16383 SHALL start with "e-". Values greater than or 321 equal to 16384 and keywords starting with "x-" are for Private Use 322 and cannot be registered. 324 Note: LDAP supports Simple Authentication and Security Layers [SASL] 325 as an authentication choice. SASL is an extensible 326 authentication framework. 328 3.8. Directory Systems Names 330 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 331 valid keywords for well known attributes was used in the LDAPv2 332 string representation of a distinguished name [RFC1779]. LDAPv2 is 333 now Historic [RFC3494]. 335 Directory systems names are not known to be used in any other 336 context. LDAPv3 uses Object Identifier Descriptors [Section 3.2] 337 (which have a different syntax than directory system names). 339 New Directory System Names will no longer be accepted. For 340 historical purposes, the current list of registered names should 341 remain publicly available. 343 4. Registration Procedure 345 The procedure given here MUST be used by anyone who wishes to use a 346 new value of a type described in Section 3 of this document. 348 The first step is for the requester to fill out the appropriate form. 349 Templates are provided in Appendix A. 351 If the policy is Standards Action, the completed form SHOULD be 352 provided to the IESG with the request for Standards Action. Upon 353 approval of the Standards Action, the IESG SHALL forward the request 354 (possibly revised) to IANA. The IESG SHALL be viewed as the owner of 355 all values requiring Standards Action. 357 If the policy is Expert Review, the requester SHALL post the 358 completed form to the mailing list for 359 public review. The review period is two (2) weeks. If a revised 360 form is later submitted, the review period is restarted. Anyone may 361 subscribe to this list by sending a request to 362 . During the review, objections may 363 be raised by anyone (including the Expert) on the list. After 364 completion of the review, the Expert, based upon public comments, 365 SHALL either approve the request and forward it to the IESG OR deny 366 the request. In either case, the Expert SHALL promptly notify the 367 requester of the action. Actions of the Expert may be appealed 368 [RFC2026]. The Expert is appointed by Applications Area Director(s). 369 The requester is viewed as the owner of values registered under 370 Expert Review. 372 If the policy is First Come First Served, the requester SHALL submit 373 the completed form directly to the IANA: . The 374 requester is viewed as the owner of values registered under First 375 Come First Served. 377 Neither the Expert nor IANA will take position on the claims of 378 copyright or trademarks issues regarding completed forms. 380 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 381 after IESG review and tentative approval, the document editor SHOULD 382 revise the I-D to use registered values. 384 5. Registration Maintenance 386 This section discusses maintenance of registrations. 388 5.1. Lists of Registered Values 390 IANA makes lists of registered values readily available to the 391 Internet community on their web site: . 393 5.2. Change Control 395 The registration owner MAY update the registration subject to the 396 same constraints and review as with new registrations. In cases 397 where the owner is not unable or unwilling to make necessary updates, 398 the IESG MAY assert ownership in order to update the registration. 400 5.3. Comments 402 For cases where others (anyone other than the owner) have significant 403 objections to the claims in a registration and the owner does not 404 agree to change the registration, comments MAY be attached to a 405 registration upon Expert Review. For registrations owned by the 406 IESG, the objections SHOULD be addressed by initiating a request for 407 Expert Review. 409 The form to these requests is ad hoc, but MUST include the specific 410 objections to be reviewed and SHOULD contain (directly or by 411 reference) materials supporting the objections. 413 6. Security Considerations 415 The security considerations detailed in BCP 26 [RFC2434] are 416 generally applicable to this document. Additional security 417 considerations specific to each name space are discussed in Section 3 418 where appropriate. 420 Security considerations for LDAP are discussed in documents 421 comprising the technical specification [Roadmap]. 423 7. Acknowledgment 425 This document is a product of the IETF LDAP Revision (LDAPBIS) 426 Working Group (WG). This document is a revision of RFC 3383, also a 427 product of the LDAPBIS WG. 429 This document includes text borrowed from "Guidelines for Writing an 430 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 431 Harald Alvestrand. 433 8. Author's Address 435 Kurt D. Zeilenga 436 OpenLDAP Foundation 438 Email: Kurt@OpenLDAP.org 440 9. Normative References 442 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 443 Identification of Management Information for TCP/IP- 444 based Internets", STD 16 (also RFC 1155), May 1990. 446 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 447 3", BCP 9 (also RFC 2026), October 1996. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 452 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 453 Specifications: ABNF", RFC 2234, November 1997. 455 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 456 IANA Considerations Section in RFCs", BCP 26 (also RFC 457 2434), October 1998. 459 [RFC3639] Yergeau, F., "UTF-8, a transformation format of ISO 460 10646", RFC 3639 (also STD 63), November 2003. 462 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 463 December 2003. 465 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 466 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 467 progress. 469 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 470 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 472 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 473 Models", draft-ietf-ldapbis-models-xx.txt, a work in 474 progress. 476 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 477 draft-ietf-ldapbis-url-xx.txt, a work in progress. 479 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 480 3.2.0" is defined by "The Unicode Standard, Version 3.0" 481 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 482 as amended by the "Unicode Standard Annex #27: Unicode 483 3.1" (http://www.unicode.org/reports/tr27/) and by the 484 "Unicode Standard Annex #28: Unicode 3.2" 485 (http://www.unicode.org/reports/tr28/). 487 [X.680] International Telecommunication Union - 488 Telecommunication Standardization Sector, "Abstract 489 Syntax Notation One (ASN.1) - Specification of Basic 490 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 492 10. Informative References 494 [RFC1779] Kille, S., "A String Representation of Distinguished 495 Names", RFC 1779, March 1995. 497 [IANADSN] IANA, "Directory Systems Names", 498 http://www.iana.org/assignments/directory-system-names. 500 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 501 version 2 (LDAPv2) to Historic Status", RFC 3494, March 502 2003. 504 [SASL] Melnikov, A. (Editor), "Simple Authentication and 505 Security Layer (SASL)", 506 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 508 Appendix A. Registration Templates 510 This appendix provides registration templates for registering new 511 LDAP values. 513 A.1. LDAP Object Identifier Registration Template 515 Subject: Request for LDAP OID Registration 517 Person & email address to contact for further information: 519 Specification: (I-D) 521 Author/Change Controller: 523 Comments: 525 (Any comments that the requester deems relevant to the request) 527 A.2. LDAP Protocol Mechanism Registration Template 529 Subject: Request for LDAP Protocol Mechanism Registration 531 Object Identifier: 533 Description: 535 Person & email address to contact for further information: 537 Usage: (One of Control or Extension or Feature) 539 Specification: (I-D) 541 Author/Change Controller: 543 Comments: 545 (Any comments that the requester deems relevant to the request) 547 A.3. LDAP Descriptor Registration Template 549 Subject: Request for LDAP Descriptor Registration 550 Descriptor (short name): 552 Object Identifier: 554 Person & email address to contact for further information: 556 Usage: (One of attribute type, URL extension, object class, 557 or other) 559 Specification: (RFC, I-D, URI) 561 Author/Change Controller: 563 Comments: 565 (Any comments that the requester deems relevant to the request) 567 A.4. LDAP Attribute Description Option Registration Template 569 Subject: Request for LDAP Attribute Description Option Registration 571 Option Name: 573 Family of Options: (YES or NO) 575 Person & email address to contact for further information: 577 Specification: (RFC, I-D, URI) 579 Author/Change Controller: 581 Comments: 583 (Any comments that the requester deems relevant to the request) 585 A.5. LDAP Message Type Registration Template 587 Subject: Request for LDAP Message Type Registration 589 LDAP Message Name: 591 Person & email address to contact for further information: 593 Specification: (Approved I-D) 595 Comments: 597 (Any comments that the requester deems relevant to the request) 599 A.6. LDAP Result Code Registration Template 601 Subject: Request for LDAP Result Code Registration 603 Result Code Name: 605 Person & email address to contact for further information: 607 Specification: (RFC, I-D, URI) 609 Author/Change Controller: 611 Comments: 613 (Any comments that the requester deems relevant to the request) 615 A.7. LDAP Authentication Method Registration Template 617 Subject: Request for LDAP Authentication Method Registration 619 Authentication Method Name: 621 Person & email address to contact for further information: 623 Specification: (RFC, I-D, URI) 625 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 627 Author/Change Controller: 629 Comments: 631 (Any comments that the requester deems relevant to the request) 633 Appendix B. Changes since RFC 3383 635 This informative appendix provides a summary of changes made since RFC 636 3383. 638 - Object Identifier Descriptors practices were updated to require 639 all descriptors defined in RFCs to be registered and 640 recommending all other descriptors (excepting those in 641 private-use name space) be registered. Additionally, all 642 requests for multiple registrations of the same descriptor are 643 now subject to Expert Review. 645 - Protocol Mechanisms practices were updated to include values of 646 the 'supportedFeatures' attribute type. 648 - References to RFCs comprising the LDAP technical specifications 649 have been updated to latest revisions. 651 - References to ISO 10646 have been replaced with [Unicode]. 653 - The "Assigned Values" appendix providing initial registry values 654 was removed. 656 - Numerous editorial changes were made. 658 Full Copyright 660 Copyright (C) The Internet Society (2004). All Rights Reserved. 662 This document and translations of it may be copied and furnished to 663 others, and derivative works that comment on or otherwise explain it 664 or assist in its implementation may be prepared, copied, published and 665 distributed, in whole or in part, without restriction of any kind, 666 provided that the above copyright notice and this paragraph are 667 included on all such copies and derivative works. However, this 668 document itself may not be modified in any way, such as by removing 669 the copyright notice or references to the Internet Society or other 670 Internet organizations, except as needed for the purpose of 671 developing Internet standards in which case the procedures for 672 copyrights defined in the Internet Standards process must be followed, 673 or as required to translate it into languages other than English.