idnits 2.17.1 draft-ietf-ldapbis-url-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([RFC2251bis], [RFC2119], [RFC2253bis], [RFC2252bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. -- The abstract seems to indicate that this document obsoletes RFC2251, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2252, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2253, but the header doesn't have an 'Obsoletes:' line to match this. 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. (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 (10 May 2001) is 8386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 468 == Unused Reference: 'RFC2279' is defined on line 350, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LDAP-IANA' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2829 (Obsoleted by RFC 4510, RFC 4513) Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mark Smith, Editor 3 Request for Comments: DRAFT Netscape Communications Corp. 4 Obsoletes: RFC 2255 Tim Howes 5 Loudcloud, Inc. 7 10 May 2001 9 The LDAP URL Format 10 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Discussion of this document should take place on the LDAP (v3) 32 Revison (ldapbis) Working Group mailing list . After appropriate review and discussion, this 34 document will be submitted as a Standards Track replacement for RFC 35 2255. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 2. Abstract 43 LDAP is the Lightweight Directory Access Protocol, defined in 44 [RFC2251bis], [RFC2252bis], and [RFC2253bis]. This document 45 describes a format for an LDAP Uniform Resource Locator. The format 46 describes an LDAP search operation used to retrieve information from 47 an LDAP directory, or, in the context of an LDAPv3 referral or 48 reference, the format describes a service where an LDAP operation may 49 be progressed. Note: not all of the parameters of the LDAP search 50 operation described in [RFC2251bis] can be expressed using the format 51 defined in this document. 53 This document specifies the LDAP URL format for version 3 of LDAP and 54 clarifies how LDAP URLs are resolved. This document also defines an 55 extension mechanism for LDAP URLs, so that future documents can 56 extend their functionality, for example, to provide access to new 57 LDAPv3 extensions as they are defined. 59 This document replaces RFC 2255. See Appendix A for a list of changes 60 relative to RFC 2255. 62 The key words "MUST", "MAY", and "SHOULD" used in this document are 63 to be interpreted as described in [RFC2119]. 65 3. URL Definition 67 An LDAP URL begins with the protocol prefix "ldap" and is defined by 68 the following grammar, following the ABNF notation defined in 69 [RFC2234]. 71 ldapurl = scheme "://" [hostport] ["/" dn 72 ["?" [attributes] ["?" [scope] 73 ["?" [filter] ["?" extensions]]]]] 74 scheme = "ldap" 75 hostport = 76 dn = 77 attributes = attrdesc *("," attrdesc) 78 attrdesc = / "*" 79 scope = "base" / "one" / "sub" 80 filter = 81 extensions = extension *("," extension) 82 extension = ["!"] extype ["=" exvalue] 83 extype = oid / oiddescr 84 exvalue = 85 oid = 86 oiddescr = 88 The "ldap" prefix indicates an entry or entries residing in the LDAP 89 server running on the given hostname at the given portnumber. 91 The dn is an LDAP Distinguished Name using the string format 92 described in [RFC2253bis]. It identifies the base object of the LDAP 93 search or the target of a non-search operation. 95 The attributes construct is used to indicate which attributes should 96 be returned from the entry or entries. Individual attrdesc names are 97 as defined for AttributeDescription in [RFC2251bis]. 99 The scope construct is used to specify the scope of the search to 100 perform in the given LDAP server. The allowable scopes are "base" 101 for a base object search, "one" for a one-level search, or "sub" for 102 a subtree search. 104 The filter is used to specify the search filter to apply to entries 105 within the specified scope during the search. It has the format 106 specified in [RFC2254bis]. 108 The extensions construct provides the LDAP URL with an extensibility 109 mechanism, allowing the capabilities of the URL to be extended in the 110 future. Extensions are a simple comma-separated list of type=value 111 pairs, where the =value portion MAY be omitted for options not 112 requiring it. Each type=value pair is a separate extension. These 113 LDAP URL extensions are not necessarily related to any of the LDAPv3 114 extension mechanisms. Extensions may be supported or unsupported by 115 the client resolving the URL. An extension prefixed with a '!' 116 character (ASCII 33) is critical. An extension not prefixed with a 117 '!' character is non-critical. 119 If an extension is supported by the client, the client MUST obey the 120 extension if the extension is critical. The client SHOULD obey 121 supported extensions that are non-critical. 123 If an extension is unsupported by the client, the client MUST NOT 124 process the URL if the extension is critical. If an unsupported 125 extension is non-critical, the client MUST ignore the extension. 127 If a critical extension cannot be processed successfully by the 128 client, the client MUST NOT process the URL. If a non-critical 129 extension cannot be processed successfully by the client, the client 130 SHOULD ignore the extension. 132 The extension type (extype) MAY be specified using the oid form 133 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use 134 of the oiddesc form SHOULD be restricted to registered object 135 identifier descriptive names. See [LDAP-IANA] for registration 136 details and usage guidelines for descriptive names. 138 No LDAP URL extensions are defined in this document. Other documents 139 or a future version of this document MAY define other extensions. 141 Note that characters that are not safe (e.g., spaces) (as defined in 142 section 2.1 of [RFC2396]), and the single Reserved character '?' 143 occurring inside a dn, filter, or other element of an LDAP URL MUST 144 be escaped using the % method described in section 2.4 of [RFC2396]. 145 If a comma character ',' occurs inside an extension value, the 146 character MUST also be escaped using the % method. 148 4. Defaults for Fields of the LDAP URL 150 Some fields of the LDAP URL are optional, as described above. In the 151 absence of any other specification, the following general defaults 152 SHOULD be used when a field is absent. Note: other documents MAY 153 specify different defaulting rules; for example, section 4.1.11 of 154 [RFC2251bis] specifies a different rule for determining the correct 155 DN to use when it is absent in an LDAP URL that is returned as a 156 referral. 158 hostport 159 The default LDAP port is TCP port 389. If no hostport is given, 160 the client must have some apriori knowledge of an appropriate LDAP 161 server to contact. 163 dn 164 If no dn is given, the default is the zero-length DN, "". 166 attributes 167 If the attributes part is omitted, all user attributes of the 168 entry or entries should be requested (e.g., by setting the 169 attributes field AttributeDescriptionList in the LDAP search 170 request to a NULL list, or (in LDAPv3) by requesting the special 171 attribute name "*"). 173 scope 174 If scope is omitted, a scope of "base" is assumed. 176 filter 177 If filter is omitted, a filter of "(objectClass=*)" is assumed. 179 extensions 180 If extensions is omitted, no extensions are assumed. 182 5. Examples 184 The following are some example LDAP URLs using the format defined 185 above. The first example is an LDAP URL referring to the University 186 of Michigan entry, available from an LDAP server of the client's 187 choosing: 189 ldap:///o=University%20of%20Michigan,c=US 191 The next example is an LDAP URL referring to the University of 192 Michigan entry in a particular ldap server: 194 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 196 Both of these URLs correspond to a base object search of the 197 "o=University of Michigan,c=US" entry using a filter of 198 "(objectclass=*)", requesting all attributes. 200 The next example is an LDAP URL referring to only the postalAddress 201 attribute of the University of Michigan entry: 203 ldap://ldap1.example.net/o=University%20of%20Michigan, 204 c=US?postalAddress 206 The corresponding LDAP search operation is the same as in the 207 previous example, except that only the postalAddress attribute is 208 requested. 210 The next example is an LDAP URL referring to the set of entries found 211 by querying the given LDAP server on port 6666 and doing a subtree 212 search of the University of Michigan for any entry with a common name 213 of "Babs Jensen", retrieving all attributes: 215 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 216 c=US??sub?(cn=Babs%20Jensen) 218 The next example is an LDAP URL referring to all children of the c=GB 219 entry: 221 ldap://ldap1.example.com/c=GB?objectClass?one 223 The objectClass attribute is requested to be returned along with the 224 entries, and the default filter of "(objectclass=*)" is used. 226 The next example is an LDAP URL to retrieve the mail attribute for 227 the LDAP entry named "o=Question?,c=US" is given below, illustrating 228 the use of the escaping mechanism on the reserved character '?'. 230 ldap://ldap2.example.com/o=Question%3f,c=US?mail 232 The next example illustrates the interaction between LDAP and URL 233 quoting mechanisms. 235 ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) 237 The filter in this example uses the LDAP escaping mechanism of \ to 238 encode three zero or null bytes in the value. In LDAP, the filter 239 would be written as (int=\00\00\00\04). Because the \ character must 240 be escaped in a URL, the \'s are escaped as %5c in the URL encoding. 242 The following three URLs that are equivalent, assuming that the 243 defaulting rules specified in section 4 of this document are used: 245 ldap://ldap.example.net 246 ldap://ldap.example.net/ 247 ldap://ldap.example.net/? 249 These three URLs all point to the root DSE on the ldap.example.net 250 server. 252 The final two examples show use of a hypothetical, experimental bind 253 name extension (the value associated with the extension is an LDAP DN). 255 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 256 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 258 The two URLs are the same, except that the second one marks the e- 259 bindname extension as critical. Notice the use of the % encoding 260 method to encode the commas within the distinguished name value in 261 the e-bindname extension. 263 6. Security Considerations 265 General URL security considerations discussed in [RFC2396] are 266 relevant for LDAP URLs. 268 The use of security mechanisms when processing LDAP URLs requires 269 particular care, since clients may encounter many different servers 270 via URLs, and since URLs are likely to be processed automatically, 271 without user intervention. A client SHOULD have a user-configurable 272 policy about which servers to connect to using which security 273 mechanisms, and SHOULD NOT make connections that are inconsistent 274 with this policy. If a client chooses to reuse an existing 275 connection when resolving one or more LDAP URL, it MUST ensure that 276 the connection is compatible with the URL and that no security 277 policies are violated. 279 Sending authentication information, no matter the mechanism, may 280 violate a user's privacy requirements. In the absence of specific 281 policy permitting authentication information to be sent to a server, 282 a client should use an anonymous connection. (Note that clients 283 conforming to previous LDAP URL specifications, where all connections 284 are anonymous and unprotected, are consistent with this 285 specification; they simply have the default security policy.) Simply 286 opening a connection to another server may violate some users' 287 privacy requirements, so clients should provide the user with a way 288 to control URL processing. 290 Some authentication methods, in particular reusable passwords sent to 291 the server, may reveal easily-abused information to the remote server 292 or to eavesdroppers in transit, and should not be used in URL 293 processing unless explicitly permitted by policy. Confirmation by 294 the human user of the use of authentication information is 295 appropriate in many circumstances. Use of strong authentication 296 methods that do not reveal sensitive information is much preferred. 297 If the URL represents a referral for an update operation, strong 298 authentication methods SHOULD be used. Please refer to the Security 299 Considerations section of [RFC2829bis] for more information. 301 The LDAP URL format allows the specification of an arbitrary LDAP 302 search operation to be performed when evaluating the LDAP URL. 303 Following an LDAP URL may cause unexpected results, for example, the 304 retrieval of large amounts of data, the initiation of a long-lived 305 search, etc. The security implications of resolving an LDAP URL are 306 the same as those of resolving an LDAP search query. 308 7. Acknowledgements 310 The LDAP URL format was originally defined at the University of 311 Michigan. This material is based upon work supported by the National 312 Science Foundation under Grant No. NCR-9416667. The support of both 313 the University of Michigan and the National Science Foundation is 314 gratefully acknowledged. 316 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 317 Changes included in this revised specification are based upon 318 discussions among the authors, discussions within the LDAP (v3) 319 Revision Working Group (ldapbis), and discussions within other IETF 320 Working Groups. The contributions of individuals in these working 321 groups is gratefully acknowledged. Several people in particular have 322 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 323 Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their 324 contributions. 326 8. References 328 [LDAP-IANA] IETF LDAPBis WG, "IANA Considerations for LDAP", a work 329 in progress. 331 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 332 Requirement Levels," RFC 2119, March 1997. 334 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 335 Specifications: ABNF", RFC 2234, November 1997. 337 [RFC2251bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol 338 (v3)", a work in progress. 340 [RFC2252bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol 341 (v3): Attribute Syntax Definitions", a work in progress. 343 [RFC2253bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol 344 (v3): UTF-8 String Representation of Distinguished Names", a work in 345 progress. 347 [RFC2254bis] IETF LDAPBis WG, "A String Representation of LDAP Search 348 Filters", a work in progress. 350 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 351 RFC 2279, January 1998. 353 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 354 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 356 [RFC2829bis] IETF LDAPBis WG, "Authentication Methods for LDAP", a 357 work in progress. 359 9. Authors' Address 361 Mark Smith, Editor 362 Netscape Communications Corp. 363 Mailstop USCA17-201 364 4170 Network Circle 365 Santa Clara, CA 95054 366 USA 367 +1 650 937-3477 368 mcs@netscape.com 370 Tim Howes 371 Loudcloud, Inc. 372 599 N. Mathilda Ave. 373 Sunnyvale, CA 94086 374 USA 375 +1 408 744-7509 376 howes@loudcloud.com 378 10. Full Copyright Statement 380 Copyright (C) The Internet Society (2001). All Rights Reserved. 382 This document and translations of it may be copied and furnished to 383 others, and derivative works that comment on or otherwise explain it 384 or assist in its implementation may be prepared, copied, published 385 and distributed, in whole or in part, without restriction of any 386 kind, provided that the above copyright notice and this paragraph are 387 included on all such copies and derivative works. However, this 388 document itself may not be modified in any way, such as by removing 389 the copyright notice or references to the Internet Society or other 390 Internet organizations, except as needed for the purpose of 391 developing Internet standards in which case the procedures for 392 copyrights defined in the Internet Standards process must be 393 followed, or as required to translate it into languages other than 394 English. 396 The limited permissions granted above are perpetual and will not be 397 revoked by the Internet Society or its successors or assigns. 399 This document and the information contained herein is provided on an 400 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 401 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 402 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 403 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 404 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 11. Appendix A: Changes Since RFC 2255 408 11.1. Technical Changes 410 "URL Definition" section: added missing "*" as an alternative for the 411 attrdesc part of the URL. It is believed that existing 412 implementations of RFC 2255 already support this. Added angle 413 brackets around free-form prose in the "dn", "hostport", "attrdesc", 414 "filter", and "exvalue" rules. Changed the ABNF for ldapurl to group 415 the dn component with the preceding slash. Changed the extype rule 416 to be an LDAPOID from RFC2251bis or an OID description from LDAP- 417 IANA. Changed the text about extension types so it references LDAP- 418 IANA. Reordered rules to more closely follow the order the elements 419 appear in the URL. 421 "Bindname Extension": removed due to lack of known implementations. 423 11.2. Editorial Changes 425 "Abstract" section: changed the text indicate that RFC 2255 is 426 replaced by this document (instead of RFC 1959). Added text to 427 indicate that LDAP URLs are used for references and referrals. Fixed 428 typo (replaced the nonsense phrase "to perform to retrieve" with 429 "used to retrieve"). Added a note to let the reader know that not 430 all of the parameters of the LDAP search operation described in 431 [RFC2251bis] can be expressed using this format. 433 IESG Note: removed note about lack of satisfactory mandatory 434 authentication mechanisms. 436 "URL Definition" section: removed second copy of ldapurl grammar and 437 following two paragraphs (editorial error in RFC 2255). Fixed line 438 break within '!' sequence. Reworded last paragraph to clarify which 439 characters must be URL escaped. Added text to indicate that LDAP 440 URLs are used for references and referrals. Added text that refers 441 to the ABNF from RFC 2234. 443 "Defaults for Fields of the LDAP URL" section: added; formed by 444 moving text about defaults out of the "URL Definition" section. 446 "URL Processing" section: clarified that connections MAY be reused 447 only if the open connection is compatible with the URL. Added text 448 to indicate that use of security services is encouraged and that they 449 SHOULD be used when updates are involved. Removed "dn" from 450 discussion of authentication methods. Added note that the client MAY 451 interrogate the server to determine the most appropriate method. 453 "Examples" section: Modified examples to use example.com and 454 example.net hostnames. Added missing '?' to the LDAP URL example 455 whose filter contains three null bytes. Removed space after one 456 comma within a DN. Revised the bindname example to use e-bindname. 457 Added some examples to show URL equivalence with respect to the dn 458 portion of the URL. 460 "Security Considerations" section: Added a note about connection 461 reuse. Added a note about using strong authentication methods for 462 updates. Added a reference to RFC 2829. Added note that simply 463 opening a connection may violate some users' privacy requirements. 465 "Acknowledgements" section: added statement about this being an 466 update to RFC 2255. Added added Kurt Zeilenga and Jim Sermersheim. 468 "References" section: changed from [1] style to [RFC2251bis] style 469 throughout the document. Added references to RFCs 2234 and 2829. 470 Updated RFC 1738 references to the appropriate sections within RFC 471 2396. Updated the references to refer to LDAPBis WG documents. 472 Added a reference to the LDAP IANA document. 474 Header and "Authors' Addresses" sections: added "editor" next to Mark 475 Smith's name. Updated affiliation and contact information. 477 Copyright: updated the year. 479 "Table of Contents" section: added. 481 12. Appendix B: Changes Since Previous Document Revision 483 This appendix lists all changes relative to the last published 484 revision, draft-ietf-ldapbis-url-00.txt. Note that these changes are 485 also included in Appendix A, but are included here for those who have 486 already reviewed draft-ietf-ldapbis-url-00.txt. 488 12.1. Technical Changes 490 "URL Definition" section: changed the ABNF for ldapurl to group the 491 dn component with the preceding slash. Changed the extype rule to be 492 is an LDAPOID from RFC2251bis or an OID description from LDAP-IANA. 493 Changed the text about extension types so it references LDAP-IANA. 495 "Bindname Extension": removed due to lack of known implementations. 497 12.2. Editorial Changes 499 "Examples" section: revised the bindname example to use e-bindname 500 and added some examples to show URL equivalence with respect to the 501 dn portion of the URL. 503 "Appendix C: Loose Ends": removed this section entirely. 505 References: updated references to refer to LDAPBis WG documents. 506 Added a reference to the LDAP IANA document. 508 This Internet Draft expires on 10 November 2001. 510 1. Status of this Memo............................................1 511 2. Abstract.......................................................1 512 3. URL Definition.................................................2 513 4. Defaults for Fields of the LDAP URL............................4 514 5. Examples.......................................................4 515 6. Security Considerations........................................6 516 7. Acknowledgements...............................................7 517 8. References.....................................................7 518 9. Authors' Address...............................................8 519 10. Full Copyright Statement.......................................9 520 11. Appendix A: Changes Since RFC 2255.............................9 521 11.1. Technical Changes...........................................9 522 11.2. Editorial Changes...........................................10 523 12. Appendix B: Changes Since Previous Document Revision...........11 524 12.1. Technical Changes...........................................11 525 12.2. Editorial Changes...........................................11