idnits 2.17.1 draft-ietf-ldapbis-bcp64-01.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 655 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 (27 October 2003) is 7487 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: 'Features' is mentioned on line 165, but not defined == Missing Reference: 'IANADSN' is mentioned on line 327, but not defined ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-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' -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- 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: 6 errors (**), 0 flaws (~~), 6 warnings (==), 15 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 27 October 2003 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 (2003). 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 characters from the Universal Character Set (UCS) [ISO10646] 120 restricted to the production. 122 3. IANA Considerations for LDAP 124 This section details each kind of protocol value which can be 125 registered and provides IANA guidelines on how to assign new values. 127 IANA may reject obviously bogus registrations described. 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). Numbers under this OID 137 arc will be assigned upon Expert Review with Specification Required. 138 Only one OID per specification will be assigned. The specification 139 MAY then assign any number of OIDs within this arc without further 140 coordination with IANA. 142 For elements developed by others, any properly delegated OID can be 143 used, including those under "Internet Private Enterprise Numbers" 144 (1.3.6.1.4.1.x) assigned by IANA 145 . 147 To avoid interoperability problems between early implementations of a 148 "work in progress" and implementations of the published specification 149 (e.g., the RFC), experimental OIDs SHOULD be used in "works in 150 progress" and early implementations. OIDs under the Internet 151 Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 153 Experimental OIDs SHALL NOT be used in published specifications (e.g. 154 RFCs). 156 Practices for IANA assignment of Internet Enterprise and Experimental 157 OIDs are detailed in STD 16 [RFC1155]. 159 3.2 Protocol Mechanisms 161 LDAP provides a number of Root DSE attributes for discovery of 162 protocol mechanisms identified by OIDs, including: 163 - supportedControl [Models], 164 - supportedExtension [Models], and 165 - supportedFeatures [Features], 167 A registry of OIDs used for discover of protocol mechanisms is 168 provided to allow implementors and others to locate the technical 169 specification for these protocol mechanisms. Future specifications 170 of additional Root DSE attributes holding values identifying protocol 171 mechanisms MAY extend this registry for their values. 173 OIDs associated with discoverable protocol mechanisms SHOULD be 174 registered. These are be considered on a First Come First Served 175 with Specification Required basis. 177 OIDs associated with Standard Track mechanisms MUST be registered and 178 require Standards Action. 180 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 UCS characters 198 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 206 conforming to the ABNF: 208 numericoid = number *( DOT number ) ; e.g. 1.1.0.23.40 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 values ending with a hyphen ("-") reserve all descriptors which 215 start with the 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 UCS characters limited by the following ABNF: 238 option = keystring 240 Options are case-insensitive. 242 While the protocol places no maximum length restriction upon option 243 strings, they should be short. Options longer than 24 characters may 244 be viewed as too long to register. 246 Values ending with a hyphen ("-") reserve all option names which 247 start with the name. For example, the registration of the option 248 "optionFamily-" reserves all options which start with "optionFamily-" 249 for some related purpose. 251 Options beginning with "x-" are for Private Use and cannot be 252 registered. 254 Options beginning with "e-" are reserved for experiments and will be 255 registered on a First Come First Served basis. 257 All other options require Standards Action or Expert Review with 258 Specification Required to be registered. 260 3.5. LDAP Message Types 262 Each protocol message is encapsulated in an LDAPMessage envelope 263 [Protocol]. The protocolOp CHOICE indicates the type of message 264 encapsulated. Each message type consists of a keyword and a 265 non-negative choice number is combined with the class (APPLICATION) 266 and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in 267 the message's encoding. The choice numbers for existing protocol 268 messages are implicit in the protocol's ASN.1 defined in [Protocol]. 270 New values will be registered upon Standards Action. 272 Note: LDAP provides extensible messages which reduces, but does not 273 eliminate, the need to add new message types. 275 3.6. LDAP Result Codes 277 LDAP result messages carry an resultCode enumerated value to indicate 278 the outcome of the operation [Protocol]. Each result code consists 279 of a keyword and a non-negative integer. 281 New resultCodes integers in the range 0-1023 require Standards Action 282 to be registered. New resultCode integers in the range 1024-4095 283 require Expert Review with Specification Required. New resultCode 284 integers in the range 4096-16383 will be registered on a First Come 285 First Served basis. Keywords associated with integers in the range 286 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 287 integers in the range 4096-16383 SHALL start with "e-". Values 288 greater than or equal to 16384 and keywords starting with "x-" are 289 for Private Use and cannot be registered. 291 3.7. LDAP Authentication Method 293 The LDAP Bind operation supports multiple authentication methods 294 [Protocol]. Each authentication choice consists of a keyword and a 295 non-negative integer. 297 The registrant SHALL classify the authentication method usage using 298 one of the following terms: 300 COMMON - method is appropriate for common use on the 301 Internet, 302 LIMITED USE - method is appropriate for limited use, 303 OBSOLETE - method has been deprecated or otherwise found to be 304 inappropriate for any use. 306 Methods without publicly available specifications SHALL NOT be 307 classified as COMMON. New registrations of class OBSOLETE cannot be 308 registered. 310 New authentication method integers in the range 0-1023 require 311 Standards Action to be registered. New authentication method 312 integers in the range 1024-4095 require Expert Review with 313 Specification Required. New authentication method integers in the 314 range 4096-16383 will be registered on a First Come First Served 315 basis. Keywords associated with integers in the range 0-4095 SHALL 316 NOT start with "e-" or "x-". Keywords associated with integers in 317 the range 4096-16383 SHALL start with "e-". Values greater than or 318 equal to 16384 and keywords starting with "x-" are for Private Use 319 and cannot be registered. 321 Note: LDAP supports Simple Authentication and Security Layers [SASL] 322 as an authentication choice. SASL is an extensible LDAP 323 authentication method. 325 3.8. Directory Systems Names 327 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 328 valid keywords for well known attributes used in the LDAPv2 string 329 representation of a distinguished name [RFC1779], now Historic 330 [RFC3494]. 332 Directory systems names are not known to be used in any other 333 context. LDAPv3 uses Object Identifier Descriptors [Section 3.2] 334 (which have a different syntax than directory system names). 336 New Directory System Names will no longer be accepted. For 337 historical purposes, the current list of registered names should 338 remain publicly available. 340 4. Registration Procedure 342 The procedure given here MUST be used by anyone who wishes to use a 343 new value of a type described in Section 3 of this document. 345 The first step is for the requester to fill out the appropriate form. 346 Templates are provided in Appendix A. 348 If the policy is Standards Action, the completed form SHOULD be 349 provided to the IESG with the request for Standards Action. Upon 350 approval of the Standards Action, the IESG SHALL forward the request 351 (possibly revised) to IANA. The IESG SHALL be viewed as the owner of 352 all values requiring Standards Action. 354 If the policy is Expert Review, the requester SHALL post the 355 completed form to the mailing list for 356 public review. The review period is two (2) weeks. If a revised 357 form is later submitted, the review period is restarted. Anyone may 358 subscribe to this list by sending a request to 359 . During the review, objections may 360 be raised by anyone (including the Expert) on the list. After 361 completion of the review, the Expert, based upon public comments, 362 SHALL either approve the request and forward it to the IESG OR deny 363 the request. In either case, the Expert SHALL promptly notify the 364 requester of the action. Actions of the Expert may be appealed 365 [RFC2026]. The Expert is appointed by Applications Area Director(s). 366 The requester is viewed as the owner of values registered under 367 Expert Review. 369 If the policy is First Come First Served, the requester SHALL submit 370 the completed form directly to the IANA: . The 371 requester is viewed as the owner of values registered under First 372 Come First Served. 374 Neither the Expert nor IANA will take position on the claims of 375 copyright or trademarks issues regarding completed forms. 377 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 378 after IESG review and tentative approval, the document editor SHOULD 379 revise the I-D to use registered values. 381 5. Registration Maintenance 383 This section discusses maintenance of registrations. 385 5.1. Lists of Registered Values 387 IANA makes lists of registered values readily available to the 388 Internet community on their web site: . 390 5.2. Change Control 392 The registration owner MAY update the registration subject to the 393 same constraints and review as with new registrations. In cases 394 where the owner is not unable or unwilling to make necessary updates, 395 the IESG MAY assert ownership in order to update the registration. 397 5.3. Comments 399 For cases where others (anyone other than the owner) have significant 400 objections to the claims in a registration and the owner does not 401 agree to change the registration, comments MAY be attached to a 402 registration upon Expert Review. For registrations owned by the 403 IESG, the objections SHOULD be addressed by initiating a request for 404 Expert Review. 406 The form to these requests is ad hoc, but MUST include the specific 407 objections to be reviewed and SHOULD contain (directly or by 408 reference) materials supporting the objections. 410 6. Security Considerations 411 The security considerations detailed in BCP 26 [RFC2434] are 412 generally applicable to this document. Additional security 413 considerations specific to each name space are discussed in Section 3 414 where appropriate. 416 Security considerations for LDAP are discussed in documents 417 comprising the technical specification [Roadmap]. 419 7. Acknowledgment 421 This document is a product of the IETF LDAP Revision (LDAPBIS) 422 Working Group (WG). This document is a revision of RFC 3383, also a 423 product of the LDAPBIS WG. 425 This document includes text borrowed from "Guidelines for Writing an 426 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 427 Harald Alvestrand. 429 8. Author's Address 431 Kurt D. Zeilenga 432 OpenLDAP Foundation 434 Email: Kurt@OpenLDAP.org 436 9. Normative References 438 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 439 Identification of Management Information for TCP/IP- 440 based Internets", STD 16 (also RFC 1155), May 1990. 442 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 443 3", BCP 9 (also RFC 2026), October 1996. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 448 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 449 Specifications: ABNF", RFC 2234, November 1997. 451 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 452 IANA Considerations Section in RFCs", BCP 26 (also RFC 453 2434), October 1998. 455 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 456 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 457 progress. 459 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 460 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 462 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 463 Models", draft-ietf-ldapbis-models-xx.txt, a work in 464 progress. 466 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 467 draft-ietf-ldapbis-url-xx.txt, a work in progress. 469 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 470 10646", draft-yergeau-rfc2279bis-xx.txt, a work in 471 progress. 473 [ISO10646] International Organization for Standardization, 474 "Universal Multiple-Octet Coded Character Set (UCS) - 475 Architecture and Basic Multilingual Plane", ISO/IEC 476 10646-1 : 1993. 478 [X.680] International Telecommunication Union - 479 Telecommunication Standardization Sector, "Abstract 480 Syntax Notation One (ASN.1) - Specification of Basic 481 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 483 10. Informative References 485 [RFC1779] Kille, S., "A String Representation of Distinguished 486 Names", RFC 1779, March 1995. 488 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 489 version 2 (LDAPv2) to Historic Status", RFC 3494, March 490 2003. 492 [SASL] Melnikov, A. (Editor), "Simple Authentication and 493 Security Layer (SASL)", 494 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 496 Appendix A. Registration Templates 498 This appendix provides registration templates for registering new 499 LDAP values. 501 A.1. LDAP Object Identifier Registration Template 502 Subject: Request for LDAP OID Registration 504 Person & email address to contact for further information: 506 Specification: (I-D) 508 Author/Change Controller: 510 Comments: 512 (Any comments that the requester deems relevant to the request) 514 A.2. LDAP Protocol Mechanism Registration Template 516 Subject: Request for LDAP Protocol Mechanism Registration 518 Object Identifier: 520 Description: 522 Person & email address to contact for further information: 524 Usage: (One of Control or Extension or Feature) 526 Specification: (I-D) 528 Author/Change Controller: 530 Comments: 532 (Any comments that the requester deems relevant to the request) 534 A.3. LDAP Descriptor Registration Template 536 Subject: Request for LDAP Descriptor Registration 538 Descriptor (short name): 540 Object Identifier: 542 Person & email address to contact for further information: 544 Usage: (One of attribute type, URL extension, 545 object class, or other) 547 Specification: (RFC, I-D, URI) 548 Author/Change Controller: 550 Comments: 552 (Any comments that the requester deems relevant to the request) 554 A.4. LDAP Attribute Description Option Registration Template 556 Subject: Request for LDAP Attribute Description Option Registration 558 Option Name: 560 Family of Options: (YES or NO) 562 Person & email address to contact for further information: 564 Specification: (RFC, I-D, URI) 566 Author/Change Controller: 568 Comments: 570 (Any comments that the requester deems relevant to the request) 572 A.5. LDAP Message Type Registration Template 574 Subject: Request for LDAP Message Type Registration 576 LDAP Message Name: 578 Person & email address to contact for further information: 580 Specification: (Approved I-D) 582 Comments: 584 (Any comments that the requester deems relevant to the request) 586 A.6. LDAP Result Code Registration Template 588 Subject: Request for LDAP Result Code Registration 590 Result Code Name: 592 Person & email address to contact for further information: 594 Specification: (RFC, I-D, URI) 596 Author/Change Controller: 598 Comments: 600 (Any comments that the requester deems relevant to the request) 602 A.7. LDAP Authentication Method Registration Template 604 Subject: Request for LDAP Authentication Method Registration 606 Authentication Method Name: 608 Person & email address to contact for further information: 610 Specification: (RFC, I-D, URI) 612 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 614 Author/Change Controller: 616 Comments: 618 (Any comments that the requester deems relevant to the request) 620 Appendix B. Changes since RFC 3383 622 This informative appendix provides a summary of changes made since RFC 623 3383. 625 - Object Identifier Descriptors practices were updated to require 626 all descriptors defined in RFCs to be registered and 627 recommending all other descriptors (excepting those in 628 private-use name space) be registered. Additionally, all 629 requests for multiple registrations of the same descriptor are 630 now subject to Expert Review. 632 - Protocol Mechanisms practices were updated to include values of 633 the 'supportedFeatures' attribute type. 635 - References to RFCs comprising the LDAP technical specifications 636 have been updated to latest revisions. 638 - The "Assigned Values" appendix providing initial registry values 639 was removed. 641 - Numerous editorial changes were made. 643 Full Copyright 645 Copyright (C) The Internet Society (2003). All Rights Reserved. 647 This document and translations of it may be copied and furnished to 648 others, and derivative works that comment on or otherwise explain it 649 or assist in its implmentation may be prepared, copied, published and 650 distributed, in whole or in part, without restriction of any kind, 651 provided that the above copyright notice and this paragraph are 652 included on all such copies and derivative works. However, this 653 document itself may not be modified in any way, such as by removing 654 the copyright notice or references to the Internet Society or other 655 Internet organizations, except as needed for the purpose of 656 developing Internet standards in which case the procedures for 657 copyrights defined in the Internet Standards process must be followed, 658 or as required to translate it into languages other than English.