idnits 2.17.1 draft-ietf-ldapbis-url-02.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 ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '...e =value portion MAY be omitted for op...' RFC 2119 keyword, line 143: '...y the client, the client MUST obey the...' RFC 2119 keyword, line 144: '...on is critical. The client SHOULD obey...' RFC 2119 keyword, line 147: '...ted by the client, the client MUST NOT...' RFC 2119 keyword, line 149: '...ical, the client MUST ignore the exten...' (15 more instances...) == 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 draft header indicates that this document obsoletes RFC2255, but the abstract doesn't seem to mention this, which it should. 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 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 (9 August 2002) is 7930 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) == Missing Reference: 'RFC2119' is mentioned on line 361, but not defined -- Looks like a reference, but probably isn't: '1' on line 497 == Missing Reference: 'RFC2251bis' is mentioned on line 535, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Unused Reference: 'RFC2279' is defined on line 370, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-iana-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPIANA' -- No information found for draft-ietf-ldapbis-filter-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Filters' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 16 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 Expires: 9 February 2003 Loudcloud, Inc. 7 9 August 2002 9 LDAP: Uniform Resource Locator 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. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Discussion of this document should take place on the LDAP (v3) 34 Revision (ldapbis) Working Group mailing list . 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 2. Abstract 41 This document describes a format for an LDAP Uniform Resource Locator 42 (URL). An LDAP URL describes an LDAP search operation that is used 43 to retrieve information from an LDAP directory, or, in the context of 44 an LDAPv3 referral or reference, an LDAP URL describes a service 45 where an LDAP operation may be progressed. 47 3. Table of Contents 49 1. Status of this Memo............................................1 50 2. Abstract.......................................................1 51 3. Table of Contents..............................................2 52 4. Introduction...................................................2 53 5. URL Definition.................................................2 54 6. Defaults for Fields of the LDAP URL............................4 55 7. Examples.......................................................5 56 8. Security Considerations........................................7 57 9. Acknowledgements...............................................8 58 10. Normative References...........................................8 59 11. Authors' Address...............................................9 60 12. Full Copyright Statement.......................................9 61 13. Appendix A: Changes Since RFC 2255.............................10 62 13.1. Technical Changes...........................................10 63 13.2. Editorial Changes...........................................10 64 14. Appendix B: Changes Since Previous Document Revision...........11 65 14.1. Technical Changes...........................................11 66 14.2. Editorial Changes...........................................12 68 4. Introduction 70 LDAP is the Lightweight Directory Access Protocol, defined in 71 [Protocol]. This document specifies the LDAP URL format for version 72 3 of LDAP and clarifies how LDAP URLs are resolved. This document 73 also defines an extension mechanism for LDAP URLs, so that future 74 documents can extend their functionality, for example, to provide 75 access to new LDAPv3 extensions as they are defined. Note: not all 76 of the parameters of the LDAP search operation described in 77 [Protocol] can be expressed using the format defined in this 78 document. 80 This document is an integral part of the LDAP Technical Specification 81 [Roadmap]. 83 This document replaces RFC 2255. See Appendix A for a list of changes 84 relative to RFC 2255. 86 The key words "MUST", "MAY", and "SHOULD" used in this document are 87 to be interpreted as described in [RFC2119]. 89 5. URL Definition 91 An LDAP URL begins with the protocol prefix "ldap" and is defined by 92 the following grammar, following the ABNF notation defined in 93 [RFC2234]. 95 ldapurl = scheme "://" [hostport] ["/" dn 96 ["?" [attributes] ["?" [scope] 97 ["?" [filter] ["?" extensions]]]]] 98 scheme = "ldap" 99 hostport = 100 dn = 101 attributes = attrdesc *("," attrdesc) 102 attrdesc = / "*" 103 scope = "base" / "one" / "sub" 104 filter = 105 extensions = extension *("," extension) 106 extension = ["!"] extype ["=" exvalue] 107 extype = oid / oiddescr 108 exvalue = 109 oid = 110 oiddescr = 112 The "ldap" prefix indicates an entry or entries residing in the LDAP 113 server running on the given hostname at the given portnumber. 115 The dn is an LDAP Distinguished Name using the string format 116 described in [LDAPDN]. It identifies the base object of the LDAP 117 search or the target of a non-search operation. 119 The attributes construct is used to indicate which attributes should 120 be returned from the entry or entries. Individual attrdesc names are 121 as defined for AttributeDescription in [Protocol]. 123 The scope construct is used to specify the scope of the search to 124 perform in the given LDAP server. The allowable scopes are "base" 125 for a base object search, "one" for a one-level search, or "sub" for 126 a subtree search. 128 The filter is used to specify the search filter to apply to entries 129 within the specified scope during the search. It has the format 130 specified in [Filters]. 132 The extensions construct provides the LDAP URL with an extensibility 133 mechanism, allowing the capabilities of the URL to be extended in the 134 future. Extensions are a simple comma-separated list of type=value 135 pairs, where the =value portion MAY be omitted for options not 136 requiring it. Each type=value pair is a separate extension. These 137 LDAP URL extensions are not necessarily related to any of the LDAPv3 138 extension mechanisms. Extensions may be supported or unsupported by 139 the client resolving the URL. An extension prefixed with a '!' 140 character (ASCII 33) is critical. An extension not prefixed with a 141 '!' character is non-critical. 143 If an extension is supported by the client, the client MUST obey the 144 extension if the extension is critical. The client SHOULD obey 145 supported extensions that are non-critical. 147 If an extension is unsupported by the client, the client MUST NOT 148 process the URL if the extension is critical. If an unsupported 149 extension is non-critical, the client MUST ignore the extension. 151 If a critical extension cannot be processed successfully by the 152 client, the client MUST NOT process the URL. If a non-critical 153 extension cannot be processed successfully by the client, the client 154 SHOULD ignore the extension. 156 The extension type (extype) MAY be specified using the oid form 157 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use 158 of the oiddesc form SHOULD be restricted to registered object 159 identifier descriptive names. See [LDAPIANA] for registration 160 details and usage guidelines for descriptive names. 162 No LDAP URL extensions are defined in this document. Other documents 163 or a future version of this document MAY define other extensions. 165 Note that characters that are not safe (e.g., spaces) (as defined in 166 section 2.1 of [RFC2396]), and the single Reserved character '?' 167 occurring inside a dn, filter, or other element of an LDAP URL MUST 168 be escaped using the % method described in section 2.4 of [RFC2396]. 169 If a comma character ',' occurs inside an extension value, the 170 character MUST also be escaped using the % method. 172 6. Defaults for Fields of the LDAP URL 174 Some fields of the LDAP URL are optional, as described above. In the 175 absence of any other specification, the following general defaults 176 SHOULD be used when a field is absent. Note: other documents MAY 177 specify different defaulting rules; for example, section 4.1.11 of 178 [Protocol] specifies a different rule for determining the correct DN 179 to use when it is absent in an LDAP URL that is returned as a 180 referral. 182 hostport 183 The default LDAP port is TCP port 389. If no hostport is given, 184 the client must have some apriori knowledge of an appropriate LDAP 185 server to contact. 187 dn 188 If no dn is given, the default is the zero-length DN, "". 190 attributes 191 If the attributes part is omitted, all user attributes of the 192 entry or entries should be requested (e.g., by setting the 193 attributes field AttributeDescriptionList in the LDAP search 194 request to a NULL list, or (in LDAPv3) by requesting the special 195 attribute name "*"). 197 scope 198 If scope is omitted, a scope of "base" is assumed. 200 filter 201 If filter is omitted, a filter of "(objectClass=*)" is assumed. 203 extensions 204 If extensions is omitted, no extensions are assumed. 206 7. Examples 208 The following are some example LDAP URLs using the format defined 209 above. The first example is an LDAP URL referring to the University 210 of Michigan entry, available from an LDAP server of the client's 211 choosing: 213 ldap:///o=University%20of%20Michigan,c=US 215 The next example is an LDAP URL referring to the University of 216 Michigan entry in a particular ldap server: 218 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 220 Both of these URLs correspond to a base object search of the 221 "o=University of Michigan,c=US" entry using a filter of 222 "(objectclass=*)", requesting all attributes. 224 The next example is an LDAP URL referring to only the postalAddress 225 attribute of the University of Michigan entry: 227 ldap://ldap1.example.net/o=University%20of%20Michigan, 228 c=US?postalAddress 230 The corresponding LDAP search operation is the same as in the 231 previous example, except that only the postalAddress attribute is 232 requested. 234 The next example is an LDAP URL referring to the set of entries found 235 by querying the given LDAP server on port 6666 and doing a subtree 236 search of the University of Michigan for any entry with a common name 237 of "Babs Jensen", retrieving all attributes: 239 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 240 c=US??sub?(cn=Babs%20Jensen) 242 The next example is an LDAP URL referring to all children of the c=GB 243 entry: 245 ldap://ldap1.example.com/c=GB?objectClass?one 247 The objectClass attribute is requested to be returned along with the 248 entries, and the default filter of "(objectclass=*)" is used. 250 The next example is an LDAP URL to retrieve the mail attribute for 251 the LDAP entry named "o=Question?,c=US" is given below, illustrating 252 the use of the escaping mechanism on the reserved character '?'. 254 ldap://ldap2.example.com/o=Question%3f,c=US?mail 256 The next example illustrates the interaction between LDAP and URL 257 quoting mechanisms. 259 ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) 261 The filter in this example uses the LDAP escaping mechanism of \ to 262 encode three zero or null bytes in the value. In LDAP, the filter 263 would be written as (int=\00\00\00\04). Because the \ character must 264 be escaped in a URL, the \'s are escaped as %5c in the URL encoding. 266 The following three URLs that are equivalent, assuming that the 267 defaulting rules specified in section 4 of this document are used: 269 ldap://ldap.example.net 270 ldap://ldap.example.net/ 271 ldap://ldap.example.net/? 273 These three URLs all point to the root DSE on the ldap.example.net 274 server. 276 The final two examples show use of a hypothetical, experimental bind 277 name extension (the value associated with the extension is an LDAP DN). 279 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 280 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 282 The two URLs are the same, except that the second one marks the e- 283 bindname extension as critical. Notice the use of the % encoding 284 method to encode the commas within the distinguished name value in 285 the e-bindname extension. 287 8. Security Considerations 289 General URL security considerations discussed in [RFC2396] are 290 relevant for LDAP URLs. 292 The use of security mechanisms when processing LDAP URLs requires 293 particular care, since clients may encounter many different servers 294 via URLs, and since URLs are likely to be processed automatically, 295 without user intervention. A client SHOULD have a user-configurable 296 policy about which servers to connect to using which security 297 mechanisms, and SHOULD NOT make connections that are inconsistent 298 with this policy. If a client chooses to reuse an existing 299 connection when resolving one or more LDAP URL, it MUST ensure that 300 the connection is compatible with the URL and that no security 301 policies are violated. 303 Sending authentication information, no matter the mechanism, may 304 violate a user's privacy requirements. In the absence of specific 305 policy permitting authentication information to be sent to a server, 306 a client should use an anonymous connection. (Note that clients 307 conforming to previous LDAP URL specifications, where all connections 308 are anonymous and unprotected, are consistent with this 309 specification; they simply have the default security policy.) Simply 310 opening a connection to another server may violate some users' 311 privacy requirements, so clients should provide the user with a way 312 to control URL processing. 314 Some authentication methods, in particular reusable passwords sent to 315 the server, may reveal easily-abused information to the remote server 316 or to eavesdroppers in transit, and should not be used in URL 317 processing unless explicitly permitted by policy. Confirmation by 318 the human user of the use of authentication information is 319 appropriate in many circumstances. Use of strong authentication 320 methods that do not reveal sensitive information is much preferred. 321 If the URL represents a referral for an update operation, strong 322 authentication methods SHOULD be used. Please refer to the Security 323 Considerations section of [AuthMeth] for more information. 325 The LDAP URL format allows the specification of an arbitrary LDAP 326 search operation to be performed when evaluating the LDAP URL. 327 Following an LDAP URL may cause unexpected results, for example, the 328 retrieval of large amounts of data, the initiation of a long-lived 329 search, etc. The security implications of resolving an LDAP URL are 330 the same as those of resolving an LDAP search query. 332 9. Acknowledgements 334 The LDAP URL format was originally defined at the University of 335 Michigan. This material is based upon work supported by the National 336 Science Foundation under Grant No. NCR-9416667. The support of both 337 the University of Michigan and the National Science Foundation is 338 gratefully acknowledged. 340 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 341 Changes included in this revised specification are based upon 342 discussions among the authors, discussions within the LDAP (v3) 343 Revision Working Group (ldapbis), and discussions within other IETF 344 Working Groups. The contributions of individuals in these working 345 groups is gratefully acknowledged. Several people in particular have 346 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 347 Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their 348 contributions. 350 10. Normative References 352 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 353 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in 354 progress. 356 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf- 357 ldapbis-iana-xx.txt, a work in progress. 359 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 360 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 361 progress. [RFC2119] Bradner, S., "Key Words for use in RFCs to 362 Indicate Requirement Levels," RFC 2119, BCP 14, March 1997. 364 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft- 365 ietf-ldapbis-protocol-xx.txt, a work in progress. 367 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 368 Specifications: ABNF", RFC 2234, November 1997. 370 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 371 RFC 2279, January 1998. 373 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 374 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 376 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 377 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in 378 progress. 380 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 381 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 383 11. Authors' Address 385 Mark Smith, Editor 386 Netscape Communications Corp. 387 360 W. Caribbean Drive 388 Sunnyvale, CA 94089 389 USA 390 +1 650 937-3477 391 mcs@netscape.com 393 Tim Howes 394 Loudcloud, Inc. 395 599 N. Mathilda Ave. 396 Sunnyvale, CA 94086 397 USA 398 +1 408 744-7509 399 howes@loudcloud.com 401 12. Full Copyright Statement 403 Copyright (C) The Internet Society (2002). All Rights Reserved. 405 This document and translations of it may be copied and furnished to 406 others, and derivative works that comment on or otherwise explain it 407 or assist in its implementation may be prepared, copied, published 408 and distributed, in whole or in part, without restriction of any 409 kind, provided that the above copyright notice and this paragraph are 410 included on all such copies and derivative works. However, this 411 document itself may not be modified in any way, such as by removing 412 the copyright notice or references to the Internet Society or other 413 Internet organizations, except as needed for the purpose of 414 developing Internet standards in which case the procedures for 415 copyrights defined in the Internet Standards process must be 416 followed, or as required to translate it into languages other than 417 English. 419 The limited permissions granted above are perpetual and will not be 420 revoked by the Internet Society or its successors or assigns. 422 This document and the information contained herein is provided on an 423 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 424 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 425 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 426 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 427 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 13. Appendix A: Changes Since RFC 2255 431 13.1. Technical Changes 433 "URL Definition" section: added missing "*" as an alternative for the 434 attrdesc part of the URL. It is believed that existing 435 implementations of RFC 2255 already support this. Added angle 436 brackets around free-form prose in the "dn", "hostport", "attrdesc", 437 "filter", and "exvalue" rules. Changed the ABNF for ldapurl to group 438 the dn component with the preceding slash. Changed the extype rule 439 to be an LDAPOID from [Protocol] or an OID description from 440 [LDAPIANA]. Changed the text about extension types so it references 441 [LDAPIANA]. Reordered rules to more closely follow the order the 442 elements appear in the URL. 444 "Bindname Extension": removed due to lack of known implementations. 446 13.2. Editorial Changes 448 "Abstract" section: separated from introductory material. 450 "Table of Contents" section: added. 452 "Introduction" section: new section; separated from the Abstract. 453 Changed the text indicate that RFC 2255 is replaced by this document 454 (instead of RFC 1959). Added text to indicate that LDAP URLs are 455 used for references and referrals. Fixed typo (replaced the nonsense 456 phrase "to perform to retrieve" with "used to retrieve"). Added a 457 note to let the reader know that not all of the parameters of the 458 LDAP search operation described in [Protocol] can be expressed using 459 this format. 461 IESG Note: removed note about lack of satisfactory mandatory 462 authentication mechanisms. 464 "URL Definition" section: removed second copy of ldapurl grammar and 465 following two paragraphs (editorial error in RFC 2255). Fixed line 466 break within '!' sequence. Reworded last paragraph to clarify which 467 characters must be URL escaped. Added text to indicate that LDAP 468 URLs are used for references and referrals. Added text that refers 469 to the ABNF from RFC 2234. 471 "Defaults for Fields of the LDAP URL" section: added; formed by 472 moving text about defaults out of the "URL Definition" section. 474 "URL Processing" section: clarified that connections MAY be reused 475 only if the open connection is compatible with the URL. Added text 476 to indicate that use of security services is encouraged and that they 477 SHOULD be used when updates are involved. Removed "dn" from 478 discussion of authentication methods. Added note that the client MAY 479 interrogate the server to determine the most appropriate method. 481 "Examples" section: Modified examples to use example.com and 482 example.net hostnames. Added missing '?' to the LDAP URL example 483 whose filter contains three null bytes. Removed space after one 484 comma within a DN. Revised the bindname example to use e-bindname. 485 Added some examples to show URL equivalence with respect to the dn 486 portion of the URL. 488 "Security Considerations" section: Added a note about connection 489 reuse. Added a note about using strong authentication methods for 490 updates. Added a reference to RFC 2829. Added note that simply 491 opening a connection may violate some users' privacy requirements. 493 "Acknowledgements" section: added statement about this being an 494 update to RFC 2255. Added Kurt Zeilenga and Jim Sermersheim. 496 "Normative References" section: renamed from "References" per new RFC 497 guidelines. Changed from [1] style to [Protocol] style throughout the 498 document. Added references to RFCs 2234 and 2829. Updated RFC 1738 499 references to the appropriate sections within RFC 2396. Updated the 500 references to refer to LDAPBis WG documents. Removed the reference to 501 the LDAP Attribute Syntaxes document and added references to the LDAP 502 IANA and Roadmap documents. 504 Header and "Authors' Address" sections: added "editor" next to Mark 505 Smith's name. Updated affiliation and contact information. 507 Copyright: updated the year. 509 14. Appendix B: Changes Since Previous Document Revision 511 This appendix lists all changes relative to the last published 512 revision, draft-ietf-ldapbis-url-01.txt. Note that these changes are 513 also included in Appendix A, but are included here for those who have 514 already reviewed draft-ietf-ldapbis-url-01.txt. 516 14.1. Technical Changes 518 None. 520 14.2. Editorial Changes 522 "Abstract" section: separated from introductory material. 524 "Table of Contents" section: moved to correct location (after 525 Abstract). 527 "Introduction" section: new section; separated from the Abstract. 529 Copyright: updated the year to 2002. 531 "URL Definition" section: updated section references to match current 532 LDAPBis drafts. 534 "Normative References" section: renamed from "References" per new RFC 535 guidelines. Replaced [RFC2251bis] style references with textual ones 536 like [Protocol] for LDAPBis documents and updated reference format to 537 match that used in other LDAPBis drafts. Removed references to 538 LDAPBis Attribute Syntaxes document and added a reference to the 539 Roadmap document. Added "BCP 14" to the RFC 2119 reference. 541 "Authors' Address" section: updated Mark Smith's postal address. 543 This Internet Draft expires on 9 February 2003.