source4/ldap_server/devdocs/rfc4516.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      M. Smith, Ed.
   8 Request for Comments: 4516                           Pearl Crescent, LLC
   9 Obsoletes: 2255                                                 T. Howes
  10 Category: Standards Track                                  Opsware, Inc.
  11                                                                June 2006
  12
  13
  14              Lightweight Directory Access Protocol (LDAP):
  15                         Uniform Resource Locator
  16
  17 Status of This Memo
  18
  19    This document specifies an Internet standards track protocol for the
  20    Internet community, and requests discussion and suggestions for
  21    improvements.  Please refer to the current edition of the "Internet
  22    Official Protocol Standards" (STD 1) for the standardization state
  23    and status of this protocol.  Distribution of this memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2006).
  28
  29 Abstract
  30
  31    This document describes a format for a Lightweight Directory Access
  32    Protocol (LDAP) Uniform Resource Locator (URL).  An LDAP URL
  33    describes an LDAP search operation that is used to retrieve
  34    information from an LDAP directory, or, in the context of an LDAP
  35    referral or reference, an LDAP URL describes a service where an LDAP
  36    operation may be progressed.
  37
  38 Table of Contents
  39
  40    1. Introduction ....................................................2
  41    2. URL Definition ..................................................2
  42       2.1. Percent-Encoding ...........................................4
  43    3. Defaults for Fields of the LDAP URL .............................5
  44    4. Examples ........................................................6
  45    5. Security Considerations .........................................8
  46    6. Normative References ............................................9
  47    7. Informative References .........................................10
  48    8. Acknowledgements ...............................................10
  49    Appendix A: Changes Since RFC 2255 ................................11
  50       A.1. Technical Changes .........................................11
  51       A.2. Editorial Changes .........................................11
  52
  53
  54
  55
  56
  57
  58 Smith & Howes               Standards Track                     [Page 1]
  59 \f
  60 RFC 4516             LDAP: Uniform Resource Locator            June 2006
  61
  62
  63 1.  Introduction
  64
  65    LDAP is the Lightweight Directory Access Protocol [RFC4510].  This
  66    document specifies the LDAP URL format for version 3 of LDAP and
  67    clarifies how LDAP URLs are resolved.  This document also defines an
  68    extension mechanism for LDAP URLs.  This mechanism may be used to
  69    provide access to new LDAP extensions.
  70
  71    Note that not all the parameters of the LDAP search operation
  72    described in [RFC4511] can be expressed using the format defined in
  73    this document.  Note also that URLs may be used to represent
  74    reference knowledge, including that for non-search operations.
  75
  76    This document is an integral part of the LDAP technical specification
  77    [RFC4510], which obsoletes the previously defined LDAP technical
  78    specification, RFC 3377, in its entirety.
  79
  80    This document replaces RFC 2255.  See Appendix A for a list of
  81    changes relative to RFC 2255.
  82
  83    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  84    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  85    document are to be interpreted as described in BCP 14 [RFC2119].
  86
  87 2.  URL Definition
  88
  89    An LDAP URL begins with the protocol prefix "ldap" and is defined by
  90    the following grammar, following the ABNF notation defined in
  91    [RFC4234].
  92
  93       ldapurl     = scheme COLON SLASH SLASH [host [COLON port]]
  94                        [SLASH dn [QUESTION [attributes]
  95                        [QUESTION [scope] [QUESTION [filter]
  96                        [QUESTION extensions]]]]]
  97                                       ; <host> and <port> are defined
  98                                       ;   in Sections 3.2.2 and 3.2.3
  99                                       ;   of [RFC3986].
 100                                       ; <filter> is from Section 3 of
 101                                       ;   [RFC4515], subject to the
 102                                       ;   provisions of the
 103                                       ;   "Percent-Encoding" section
 104                                       ;   below.
 105
 106       scheme      = "ldap"
 107
 108
 109
 110
 111
 112
 113
 114 Smith & Howes               Standards Track                     [Page 2]
 115 \f
 116 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 117
 118
 119       dn          = distinguishedName ; From Section 3 of [RFC4514],
 120                                       ; subject to the provisions of
 121                                       ; the "Percent-Encoding"
 122                                       ; section below.
 123
 124       attributes  = attrdesc *(COMMA attrdesc)
 125       attrdesc    = selector *(COMMA selector)
 126       selector    = attributeSelector ; From Section 4.5.1 of
 127                                       ; [RFC4511], subject to the
 128                                       ; provisions of the
 129                                       ; "Percent-Encoding" section
 130                                       ; below.
 131
 132       scope       = "base" / "one" / "sub"
 133       extensions  = extension *(COMMA extension)
 134       extension   = [EXCLAMATION] extype [EQUALS exvalue]
 135       extype      = oid               ; From section 1.4 of [RFC4512].
 136
 137       exvalue     = LDAPString        ; From section 4.1.2 of
 138                                       ; [RFC4511], subject to the
 139                                       ; provisions of the
 140                                       ; "Percent-Encoding" section
 141                                       ; below.
 142
 143       EXCLAMATION = %x21              ; exclamation mark ("!")
 144       SLASH       = %x2F              ; forward slash ("/")
 145       COLON       = %x3A              ; colon (":")
 146       QUESTION    = %x3F              ; question mark ("?")
 147
 148    The "ldap" prefix indicates an entry or entries accessible from the
 149    LDAP server running on the given hostname at the given portnumber.
 150    Note that the <host> may contain literal IPv6 addresses as specified
 151    in Section 3.2.2 of [RFC3986].
 152
 153    The <dn> is an LDAP Distinguished Name using the string format
 154    described in [RFC4514].  It identifies the base object of the LDAP
 155    search or the target of a non-search operation.
 156
 157    The <attributes> construct is used to indicate which attributes
 158    should be returned from the entry or entries.
 159
 160    The <scope> construct is used to specify the scope of the search to
 161    perform in the given LDAP server.  The allowable scopes are "base"
 162    for a base object search, "one" for a one-level search, or "sub" for
 163    a subtree search.
 164
 165
 166
 167
 168
 169
 170 Smith & Howes               Standards Track                     [Page 3]
 171 \f
 172 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 173
 174
 175    The <filter> is used to specify the search filter to apply to entries
 176    within the specified scope during the search.  It has the format
 177    specified in [RFC4515].
 178
 179    The <extensions> construct provides the LDAP URL with an
 180    extensibility mechanism, allowing the capabilities of the URL to be
 181    extended in the future.  Extensions are a simple comma-separated list
 182    of type=value pairs, where the =value portion MAY be omitted for
 183    options not requiring it.  Each type=value pair is a separate
 184    extension.  These LDAP URL extensions are not necessarily related to
 185    any of the LDAP extension mechanisms.  Extensions may be supported or
 186    unsupported by the client resolving the URL.  An extension prefixed
 187    with a '!' character (ASCII 0x21) is critical.  An extension not
 188    prefixed with a '!' character is non-critical.
 189
 190    If an LDAP URL extension is implemented (that is, if the
 191    implementation understands it and is able to use it), the
 192    implementation MUST make use of it.  If an extension is not
 193    implemented and is marked critical, the implementation MUST NOT
 194    process the URL.  If an extension is not implemented and is not
 195    marked critical, the implementation MUST ignore the extension.
 196
 197    The extension type (<extype>) MAY be specified using the numeric OID
 198    <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
 199    (e.g., myLDAPURLExtension).  Use of the <descr> form SHOULD be
 200    restricted to registered object identifier descriptive names.  See
 201    [RFC4520] for registration details and usage guidelines for
 202    descriptive names.
 203
 204    No LDAP URL extensions are defined in this document.  Other documents
 205    or a future version of this document MAY define one or more
 206    extensions.
 207
 208 2.1.  Percent-Encoding
 209
 210    A generated LDAP URL MUST consist only of the restricted set of
 211    characters included in one of the following three productions defined
 212    in [RFC3986]:
 213
 214          <reserved>
 215          <unreserved>
 216          <pct-encoded>
 217
 218    Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
 219    input.  An octet MUST be encoded using the percent-encoding mechanism
 220    described in section 2.1 of [RFC3986] in any of these situations:
 221
 222
 223
 224
 225
 226 Smith & Howes               Standards Track                     [Page 4]
 227 \f
 228 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 229
 230
 231       The octet is not in the reserved set defined in section 2.2 of
 232       [RFC3986] or in the unreserved set defined in section 2.3 of
 233       [RFC3986].
 234
 235       It is the single Reserved character '?' and occurs inside a <dn>,
 236       <filter>, or other element of an LDAP URL.
 237
 238       It is a comma character ',' that occurs inside an <exvalue>.
 239
 240    Note that before the percent-encoding mechanism is applied, the
 241    extensions component of the LDAP URL may contain one or more null
 242    (zero) bytes.  No other component may.
 243
 244 3.  Defaults for Fields of the LDAP URL
 245
 246    Some fields of the LDAP URL are optional, as described above.  In the
 247    absence of any other specification, the following general defaults
 248    SHOULD be used when a field is absent.  Note that other documents MAY
 249    specify different defaulting rules; for example, section 4.1.10 of
 250    [RFC4511] specifies a different rule for determining the correct DN
 251    to use when it is absent in an LDAP URL that is returned as a
 252    referral.
 253
 254    <host>
 255       If no <host> is given, the client must have some a priori
 256       knowledge of an appropriate LDAP server to contact.
 257
 258    <port>
 259       The default LDAP port is TCP port 389.
 260
 261    <dn>
 262       If no <dn> is given, the default is the zero-length DN, "".
 263
 264    <attributes>
 265       If the <attributes> part is omitted, all user attributes of the
 266       entry or entries should be requested (e.g., by setting the
 267       attributes field AttributeDescriptionList in the LDAP search
 268       request to a NULL list, or by using the special <alluserattrs>
 269       selector "*").
 270
 271    <scope>
 272       If <scope> is omitted, a <scope> of "base" is assumed.
 273
 274    <filter>
 275       If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
 276
 277    <extensions>
 278       If <extensions> is omitted, no extensions are assumed.
 279
 280
 281
 282 Smith & Howes               Standards Track                     [Page 5]
 283 \f
 284 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 285
 286
 287 4.  Examples
 288
 289    The following are some example LDAP URLs that use the format defined
 290    above.  The first example is an LDAP URL referring to the University
 291    of Michigan entry, available from an LDAP server of the client's
 292    choosing:
 293
 294       ldap:///o=University%20of%20Michigan,c=US
 295
 296    The next example is an LDAP URL referring to the University of
 297    Michigan entry in a particular ldap server:
 298
 299       ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
 300
 301    Both of these URLs correspond to a base object search of the
 302    "o=University of Michigan,c=US" entry using a filter of
 303    "(objectclass=*)", requesting all attributes.
 304
 305    The next example is an LDAP URL referring to only the postalAddress
 306    attribute of the University of Michigan entry:
 307
 308       ldap://ldap1.example.net/o=University%20of%20Michigan,
 309              c=US?postalAddress
 310
 311    The corresponding LDAP search operation is the same as in the
 312    previous example, except that only the postalAddress attribute is
 313    requested.
 314
 315    The next example is an LDAP URL referring to the set of entries found
 316    by querying the given LDAP server on port 6666 and doing a subtree
 317    search of the University of Michigan for any entry with a common name
 318    of "Babs Jensen", retrieving all attributes:
 319
 320       ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
 321              c=US??sub?(cn=Babs%20Jensen)
 322
 323    The next example is an LDAP URL referring to all children of the c=GB
 324    entry:
 325
 326       LDAP://ldap1.example.com/c=GB?objectClass?ONE
 327
 328    The objectClass attribute is requested to be returned along with the
 329    entries, and the default filter of "(objectclass=*)" is used.
 330
 331    The next example is an LDAP URL to retrieve the mail attribute for
 332    the LDAP entry named "o=Question?,c=US", illustrating the use of the
 333    percent-encoding mechanism on the reserved character '?'.
 334
 335
 336
 337
 338 Smith & Howes               Standards Track                     [Page 6]
 339 \f
 340 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 341
 342
 343       ldap://ldap2.example.com/o=Question%3f,c=US?mail
 344
 345    The next example (which is broken into two lines for readability)
 346    illustrates the interaction between the LDAP string representation of
 347    the filters-quoting mechanism and the URL-quoting mechanisms.
 348
 349       ldap://ldap3.example.com/o=Babsco,c=US
 350               ???(four-octet=%5c00%5c00%5c00%5c04)
 351
 352    The filter in this example uses the LDAP escaping mechanism of \ to
 353    encode three zero or null bytes in the value.  In LDAP, the filter
 354    would be written as (four-octet=\00\00\00\04).  Because the \
 355    character must be escaped in a URL, the \s are percent-encoded as %5c
 356    (or %5C) in the URL encoding.
 357
 358    The next example illustrates the interaction between the LDAP string
 359    representation of the DNs-quoting mechanism and URL-quoting
 360    mechanisms.
 361
 362       ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
 363
 364    The DN encoded in the above URL is:
 365
 366       o=An Example\2C Inc.,c=US
 367
 368    That is, the left-most RDN value is:
 369
 370       An Example, Inc.
 371
 372    The following three URLs are equivalent, assuming that the defaulting
 373    rules specified in Section 3 of this document are used:
 374
 375       ldap://ldap.example.net
 376       ldap://ldap.example.net/
 377       ldap://ldap.example.net/?
 378
 379    These three URLs point to the root DSE on the ldap.example.net
 380    server.
 381
 382    The final two examples show use of a hypothetical, experimental bind
 383    name extension (the value associated with the extension is an LDAP
 384    DN).
 385
 386       ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
 387       ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
 388
 389
 390
 391
 392
 393
 394 Smith & Howes               Standards Track                     [Page 7]
 395 \f
 396 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 397
 398
 399    The two URLs are the same, except that the second one marks the
 400    e-bindname extension as critical.  Notice the use of the percent-
 401    encoding mechanism to encode the commas within the distinguished name
 402    value in the e-bindname extension.
 403
 404 5.  Security Considerations
 405
 406    The general URL security considerations discussed in [RFC3986] are
 407    relevant for LDAP URLs.
 408
 409    The use of security mechanisms when processing LDAP URLs requires
 410    particular care, since clients may encounter many different servers
 411    via URLs, and since URLs are likely to be processed automatically,
 412    without user intervention.  A client SHOULD have a user-configurable
 413    policy that controls which servers the client will establish LDAP
 414    sessions with and with which security mechanisms, and SHOULD NOT
 415    establish LDAP sessions that are inconsistent with this policy.  If a
 416    client chooses to reuse an existing LDAP session when resolving one
 417    or more LDAP URLs, it MUST ensure that the session is compatible with
 418    the URL and that no security policies are violated.
 419
 420    Sending authentication information, no matter the mechanism, may
 421    violate a user's privacy requirements.  In the absence of specific
 422    policy permitting authentication information to be sent to a server,
 423    a client should use an anonymous LDAP session.  (Note that clients
 424    conforming to previous LDAP URL specifications, where all LDAP
 425    sessions are anonymous and unprotected, are consistent with this
 426    specification; they simply have the default security policy.)  Simply
 427    opening a transport connection to another server may violate some
 428    users' privacy requirements, so clients should provide the user with
 429    a way to control URL processing.
 430
 431    Some authentication methods, in particular, reusable passwords sent
 432    to the server, may reveal easily-abused information to the remote
 433    server or to eavesdroppers in transit and should not be used in URL
 434    processing unless they are explicitly permitted by policy.
 435    Confirmation by the human user of the use of authentication
 436    information is appropriate in many circumstances.  Use of strong
 437    authentication methods that do not reveal sensitive information is
 438    much preferred.  If the URL represents a referral for an update
 439    operation, strong authentication methods SHOULD be used.  Please
 440    refer to the Security Considerations section of [RFC4513] for more
 441    information.
 442
 443    The LDAP URL format allows the specification of an arbitrary LDAP
 444    search operation to be performed when evaluating the LDAP URL.
 445    Following an LDAP URL may cause unexpected results, for example, the
 446    retrieval of large amounts of data or the initiation of a long-lived
 447
 448
 449
 450 Smith & Howes               Standards Track                     [Page 8]
 451 \f
 452 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 453
 454
 455    search.  The security implications of resolving an LDAP URL are the
 456    same as those of resolving an LDAP search query.
 457
 458 6.  Normative References
 459
 460    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 461               Requirement Levels", BCP 14, RFC 2119, March 1997.
 462
 463    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
 464               10646", STD 63, RFC 3629, November 2003.
 465
 466    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 467               Resource Identifier (URI): Generic Syntax", STD 66, RFC
 468               3986, January 2005.
 469
 470    [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
 471               Specifications: ABNF", RFC 4234, October 2005.
 472
 473    [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
 474               (LDAP): Technical Specification Road Map", RFC 4510, June
 475               2006.
 476
 477    [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
 478               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
 479
 480    [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
 481               (LDAP): Directory Information Models", RFC 4512, June
 482               2006.
 483
 484    [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
 485               (LDAP): Authentication Methods and Security Mechanisms",
 486               RFC 4513, June 2006.
 487
 488    [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
 489               (LDAP): String Representation of Distinguished Names", RFC
 490               4514, June 2006.
 491
 492    [RFC4515]  Smith, M. Ed. and T. Howes, "Lightweight Directory Access
 493               Protocol (LDAP): String Representation of Search Filters",
 494               RFC 4515, June 2006.
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Smith & Howes               Standards Track                     [Page 9]
 507 \f
 508 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 509
 510
 511 7.  Informative References
 512
 513    [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 514               Resource Identifiers (URI): Generic Syntax", RFC 2396,
 515               August 1998.
 516
 517    [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
 518               Considerations for the Lightweight Directory Access
 519               Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
 520
 521 8.  Acknowledgements
 522
 523    The LDAP URL format was originally defined at the University of
 524    Michigan.  This material is based upon work supported by the National
 525    Science Foundation under Grant No. NCR-9416667.  The support of both
 526    the University of Michigan and the National Science Foundation is
 527    gratefully acknowledged.
 528
 529    This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
 530    Changes included in this revised specification are based upon
 531    discussions among the authors, discussions within the LDAP (v3)
 532    Revision Working Group (ldapbis), and discussions within other IETF
 533    Working Groups.  The contributions of individuals in these working
 534    groups is gratefully acknowledged.  Several people in particular have
 535    made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
 536    Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
 537    thanks for their contributions.
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Smith & Howes               Standards Track                    [Page 10]
 563 \f
 564 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 565
 566
 567 Appendix A: Changes Since RFC 2255
 568
 569 A.1.  Technical Changes
 570
 571    The following technical changes were made to the contents of the "URL
 572    Definition" section:
 573
 574    Revised all of the ABNF to use common productions from [RFC4512].
 575
 576    Replaced references to [RFC2396] with a reference to [RFC3986] (this
 577    allows literal IPv6 addresses to be used inside the <host> portion of
 578    the URL, and a note was added to remind the reader of this
 579    enhancement).  Referencing [RFC3986] required changes to the ABNF and
 580    text so that productions that are no longer defined by [RFC3986] are
 581    not used.  For example, <hostport> is not defined by [RFC3986] so it
 582    has been replaced with host [COLON port].  Note that [RFC3986]
 583    includes new definitions for the "Reserved" and "Unreserved" sets of
 584    characters, and the net result is that the following two additional
 585    characters should be percent-encoded when they appear anywhere in the
 586    data used to construct an LDAP URL: "[" and "]" (these two characters
 587    were first added to the Reserved set by RFC 2732).
 588
 589    Changed the definition of <attrdesc> to refer to <attributeSelector>
 590    from [RFC4511].  This allows the use of "*" in the <attrdesc> part of
 591    the URL.  It is believed that existing implementations of RFC 2255
 592    already support this.
 593
 594    Avoided use of <prose-val> (bracketed-string) productions in the
 595    <dn>, <host>, <attrdesc>, and <exvalue> rules.
 596
 597    Changed the ABNF for <ldapurl> to group the <dn> component with the
 598    preceding <SLASH>.
 599
 600    Changed the <extype> rule to be an <oid> from [RFC4512].
 601
 602    Changed the text about extension types so it references [RFC4520].
 603    Reordered rules to more closely follow the order in which the
 604    elements appear in the URL.
 605
 606    "Bindname Extension": removed due to lack of known implementations.
 607
 608 A.2.  Editorial Changes
 609
 610    Changed document title to include "LDAP:" prefix.
 611
 612    IESG Note: removed note about lack of satisfactory mandatory
 613    authentication mechanisms.
 614
 615
 616
 617
 618 Smith & Howes               Standards Track                    [Page 11]
 619 \f
 620 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 621
 622
 623    "Status of this Memo" section: updated boilerplate to match current
 624    I-D guidelines.
 625
 626    "Abstract" section: separated from introductory material.
 627
 628    "Table of Contents" and "Intellectual Property" sections: added.
 629
 630    "Introduction" section: new section; separated from the Abstract.
 631    Changed the text indicate that RFC 2255 is replaced by this document
 632    (instead of RFC 1959).  Added text to indicate that LDAP URLs are
 633    used for references and referrals.  Fixed typo (replaced the nonsense
 634    phrase "to perform to retrieve" with "used to retrieve").  Added a
 635    note to let the reader know that not all of the parameters of the
 636    LDAP search operation described in [RFC4511] can be expressed using
 637    this format.
 638
 639    "URL Definition" section: removed second copy of <ldapurl> grammar
 640    and following two paragraphs (editorial error in RFC 2255).  Fixed
 641    line break within '!' sequence.  Reformatted the ABNF to improve
 642    readability by aligning comments and adding some blank lines.
 643    Replaced "residing in the LDAP server" with "accessible from the LDAP
 644    server" in the sentence immediately following the ABNF.  Removed the
 645    sentence "Individual attrdesc names are as defined for
 646    AttributeDescription in [RFC4511]."  because [RFC4511]'s
 647    <attributeSelector> is now used directly in the ABNF.  Reworded last
 648    paragraph to clarify which characters must be percent-encoded.  Added
 649    text to indicate that LDAP URLs are used for references and
 650    referrals.  Added text that refers to the ABNF from RFC 4234.
 651    Clarified and strengthened the requirements with respect to
 652    processing of URLs that contain implemented and not implemented
 653    extensions (the approach now closely matches that specified in
 654    [RFC4511] for LDAP controls).
 655
 656    "Defaults for Fields of the LDAP URL" section: added; formed by
 657    moving text about defaults out of the "URL Definition" section.
 658    Replaced direct reference to the attribute name "*" with a reference
 659    to the special <alluserattrs> selector "*" defined in [RFC4511].
 660
 661    "URL Processing" section: removed.
 662
 663    "Examples" section: Modified examples to use example.com and
 664    example.net hostnames.  Added missing '?' to the LDAP URL example
 665    whose filter contains three null bytes.  Removed space after one
 666    comma within a DN.  Revised the bindname example to use e-bindname.
 667    Changed the name of an attribute used in one example from "int" to
 668    "four-octet" to avoid potential confusion.  Added an example that
 669    demonstrates the interaction between DN escaping and URL percent-
 670    encoding.  Added some examples to show URL equivalence with respect
 671
 672
 673
 674 Smith & Howes               Standards Track                    [Page 12]
 675 \f
 676 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 677
 678
 679    to the <dn> portion of the URL.  Used uppercase in some examples to
 680    remind the reader that some tokens are case-insensitive.
 681
 682    "Security Considerations" section: Added a note about connection
 683    reuse.  Added a note about using strong authentication methods for
 684    updates.  Added a reference to [RFC4513].  Added note that simply
 685    opening a connection may violate some users' privacy requirements.
 686    Adopted the working group's revised LDAP terminology specification by
 687    replacing the word "connection" with "LDAP session" or "LDAP
 688    connection" as appropriate.
 689
 690    "Acknowledgements" section: added statement that this document
 691    obsoletes RFC 2255.  Added Kurt Zeilenga, Jim Sermersheim, and
 692    Hallvard Furuseth.
 693
 694    "Normative References" section: renamed from "References" per new RFC
 695    guidelines.  Changed from [1] style to [RFC4511] style throughout the
 696    document.  Added references to RFC 4234 and RFC 3629.  Updated all
 697    RFC 1738 references to point to the appropriate sections within
 698    [RFC3986].  Updated the LDAP references to refer to LDAPBis WG
 699    documents.  Removed the reference to the LDAP Attribute Syntaxes
 700    document and added references to the [RFC4513], [RFC4520], and
 701    [RFC4510] documents.
 702
 703    "Informative References" section: added.
 704
 705    Header and "Authors' Addresses" sections: added "editor" next to Mark
 706    Smith's name.  Updated affiliation and contact information.
 707
 708    Copyright: updated the year.
 709
 710    Throughout the document: surrounded the names of all ABNF productions
 711    with "<" and ">" where they are used in descriptive text.
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Smith & Howes               Standards Track                    [Page 13]
 731 \f
 732 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 733
 734
 735 Authors' Addresses
 736
 737    Mark Smith, Editor
 738    Pearl Crescent, LLC
 739    447 Marlpool Dr.
 740    Saline, MI 48176
 741    USA
 742
 743    Phone: +1 734 944-2856
 744    EMail: mcs@pearlcrescent.com
 745
 746
 747    Tim Howes
 748    Opsware, Inc.
 749    599 N. Mathilda Ave.
 750    Sunnyvale, CA 94085
 751    USA
 752
 753    Phone: +1 408 744-7509
 754    EMail: howes@opsware.com
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Smith & Howes               Standards Track                    [Page 14]
 787 \f
 788 RFC 4516             LDAP: Uniform Resource Locator            June 2006
 789
 790
 791 Full Copyright Statement
 792
 793    Copyright (C) The Internet Society (2006).
 794
 795    This document is subject to the rights, licenses and restrictions
 796    contained in BCP 78, and except as set forth therein, the authors
 797    retain all their rights.
 798
 799    This document and the information contained herein are provided on an
 800    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 801    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 802    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 803    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 804    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 805    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 806
 807 Intellectual Property
 808
 809    The IETF takes no position regarding the validity or scope of any
 810    Intellectual Property Rights or other rights that might be claimed to
 811    pertain to the implementation or use of the technology described in
 812    this document or the extent to which any license under such rights
 813    might or might not be available; nor does it represent that it has
 814    made any independent effort to identify any such rights.  Information
 815    on the procedures with respect to rights in RFC documents can be
 816    found in BCP 78 and BCP 79.
 817
 818    Copies of IPR disclosures made to the IETF Secretariat and any
 819    assurances of licenses to be made available, or the result of an
 820    attempt made to obtain a general license or permission for the use of
 821    such proprietary rights by implementers or users of this
 822    specification can be obtained from the IETF on-line IPR repository at
 823    http://www.ietf.org/ipr.
 824
 825    The IETF invites any interested party to bring to its attention any
 826    copyrights, patents or patent applications, or other proprietary
 827    rights that may cover technology that may be required to implement
 828    this standard.  Please address the information to the IETF at
 829    ietf-ipr@ietf.org.
 830
 831 Acknowledgement
 832
 833    Funding for the RFC Editor function is provided by the IETF
 834    Administrative Support Activity (IASA).
 835
 836
 837
 838
 839
 840
 841
 842 Smith & Howes               Standards Track                    [Page 15]
 843 \f