As per Relevance of the word extension, we have this rfc below:
Network Working Group T.
Request for Comments: 2255 M.
Category: Standards Track Netscape Communications Corp
December 1997
The LDAP URL
1. Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
IESG
This document describes a directory access protocol that
both read and update access. Update access requires
authentication, but this document does not mandate implementation
any satisfactory authentication mechanisms
In accordance with RFC 2026, section 4.4.1, this specification
being approved by IESG as a Proposed Standard despite
limitation, for the following reasons
a. to encourage implementation and interoperability testing
these protocols (with or without update access) before
are deployed,
b. to encourage deployment and use of these protocols in read-
applications. (e.g. applications where LDAPv3 is used
a query language for directories which are updated by
secure mechanism other than LDAP),
c. to avoid delaying the advancement and deployment of other
standards-track protocols which require the ability to query,
not update, LDAPv3 directory servers
Howes & Smith Standards Track [Page 1]
RFC 2255 LDAP URL Format December 1997
Readers are hereby warned that until mandatory
mechanisms are standardized, clients and servers written according
this specification which make use of update functionality
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL
Implementors are hereby discouraged from deploying LDAPv3 clients
servers which implement the update functionality, until a
Standard for mandatory authentication in LDAPv3 has been approved
published as an RFC
2.
LDAP is the Lightweight Directory Access Protocol, defined in [1],
[2] and [3]. This document describes a format for an LDAP
Resource Locator. The format describes an LDAP search operation
perform to retrieve information from an LDAP directory. This
replaces RFC 1959. It updates the LDAP URL format for version 3
LDAP and clarifies how LDAP URLs are resolved. This document
defines an extension mechanism for LDAP URLs, so that
documents can extend their functionality, for example, to
access to new LDAPv3 extensions as they are defined
The key words "MUST", "MAY", and "SHOULD" used in this document
to be interpreted as described in [6].
Howes & Smith Standards Track [Page 2]
RFC 2255 LDAP URL Format December 1997
3. URL
An LDAP URL begins with the protocol prefix "ldap" and is defined
the following grammar
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap
attributes = attrdesc *("," attrdesc
scope = "base" / "one" / "sub
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension
extension = ["!"] extype ["=" exvalue
extype = token /
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-")
The "ldap" prefix indicates an entry or entries residing in the
server running on the given hostname at the given portnumber.
default LDAP port is TCP port 389. If no hostport is given,
client must have some apriori knowledge of an appropriate LDAP
to contact
The dn is an LDAP Distinguished Name using the string
described in [1]. It identifies the base object of the LDAP search
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap
attributes = attrdesc *("," attrdesc
scope = "base" / "one" / "sub
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension
extension = ["!"] extype ["=" exvalue
extype = token /
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-")
Howes & Smith Standards Track [Page 3]
RFC 2255 LDAP URL Format December 1997
The "ldap" prefix indicates an entry or entries residing in the
server running on the given hostname at the given portnumber.
default LDAP port is TCP port 389. If no hostport is given,
client must have some apriori knowledge of an appropriate LDAP
to contact
The dn is an LDAP Distinguished Name using the string
described in [1]. It identifies the base object of the LDAP search
The attributes construct is used to indicate which attributes
be returned from the entry or entries. Individual attrdesc names
as defined for AttributeDescription in [2]. If the attributes
is omitted, all user attributes of the entry or entries should
requested (e.g., by setting the attributes
AttributeDescriptionList in the LDAP search request to a NULL list
or (in LDAPv3) by requesting the special attribute name "*").
The scope construct is used to specify the scope of the search
perform in the given LDAP server. The allowable scopes are "base
for a base object search, "one" for a one-level search, or "sub"
a subtree search. If scope is omitted, a scope of "base" is assumed
The filter is used to specify the search filter to apply to
within the specified scope during the search. It has the
specified in [4]. If filter is omitted, a filter
"(objectClass=*)" is assumed
The extensions construct provides the LDAP URL with an
mechanism, allowing the capabilities of the URL to be extended in
future. Extensions are a simple comma-separated list of type=
pairs, where the =value portion MAY be omitted for options
requiring it. Each type=value pair is a separate extension.
LDAP URL extensions are not necessarily related to any of the LDAPv
extension mechanisms. Extensions may be supported or unsupported
the client resolving the URL. An extension prefixed with a '!'
character (ASCII 33) is critical. An extension not prefixed with a '
!' character is non-critical
If an extension is supported by the client, the client MUST obey
extension if the extension is critical. The client SHOULD
supported extensions that are non-critical
If an extension is unsupported by the client, the client MUST
process the URL if the extension is critical. If an
extension is non-critical, the client MUST ignore the extension
Howes & Smith Standards Track [Page 4]
RFC 2255 LDAP URL Format December 1997
If a critical extension cannot be processed successfully by
client, the client MUST NOT process the URL. If a non-
extension cannot be processed successfully by the client, the
SHOULD ignore the extension
Extension types prefixed by "X-" or "x-" are reserved for use
bilateral agreements between communicating parties. Other
types MUST be defined in this document, or in other standards-
documents
One LDAP URL extension is defined in this document in the
section. Other documents or a future version of this document
define other extensions
Note that any URL-illegal characters (e.g., spaces), URL
characters (as defined in section 2.2 of RFC 1738) and the
character '?' (ASCII 63) occurring inside a dn, filter, or
element of an LDAP URL MUST be escaped using the % method
in RFC 1738 [5]. If a comma character ',' occurs inside an
value, the character MUST also be escaped using the % method
4. The Bindname
This section defines an LDAP URL extension for representing
distinguished name for a client to use when authenticating to an
directory during resolution of an LDAP URL. Clients MAY
this extension
The extension type is "bindname". The extension value is
distinguished name of the directory entry to authenticate as, in
same form as described for dn in the grammar above. The dn may be
NULL string to specify unauthenticated access. The extension may
either critical (prefixed with a '!' character) or non-critical (
prefixed with a '!' character).
If the bindname extension is critical, the client resolving the
MUST authenticate to the directory using the given distinguished
and an appropriate authentication method. Note that for a
distinguished name, no bind MAY be required to obtain
access to the directory. If the extension is non-critical, the
MAY bind to the directory using the given distinguished name
5. URL
This section describes how an LDAP URL SHOULD be resolved by
client
Howes & Smith Standards Track [Page 5]
RFC 2255 LDAP URL Format December 1997
First, the client obtains a connection to the LDAP server
in the URL, or an LDAP server of the client's choice if no
server is explicitly referenced. This connection MAY be
specifically for the purpose of resolving the URL or the client
reuse an already open connection. The connection MAY
confidentiality, integrity, or other services, e.g., using TLS.
of security services is at the client's discretion if not
in the URL
Next, the client authenticates itself to the LDAP server. This
is optional, unless the URL contains a critical bindname
with a non-NULL value. If a bindname extension is given, the
proceeds according to the section above
If a bindname extension is not specified, the client MAY bind to
directory using a appropriate dn and authentication method of its
choosing (including NULL authentication).
Next, the client performs the LDAP search operation specified in
URL. Additional fields in the LDAP protocol search request, such
sizelimit, timelimit, deref, and anything else not specified
defaulted in the URL specification, MAY be set at the client'
discretion
Once the search has completed, the client MAY close the connection
the LDAP server, or the client MAY keep the connection open
future use
6.
The following are some example LDAP URLs using the format
above. The first example is an LDAP URL referring to the
of Michigan entry, available from an LDAP server of the client'
choosing
ldap:///o=University%20of%20Michigan,c=
The next example is an LDAP URL referring to the University
Michigan entry in a particular ldap server
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=
Both of these URLs correspond to a base object search of
"o=University of Michigan, c=US" entry using a filter
"(objectclass=*)", requesting all attributes
The next example is an LDAP URL referring to only the
attribute of the University of Michigan entry
Howes & Smith Standards Track [Page 6]
RFC 2255 LDAP URL Format December 1997
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan
c=US?
The corresponding LDAP search operation is the same as in
previous example, except that only the postalAddress attribute
requested
The next example is an LDAP URL referring to the set of entries
by querying the given LDAP server on port 6666 and doing a
search of the University of Michigan for any entry with a common
of "Babs Jensen", retrieving all attributes
ldap://host.com:6666/o=University%20of%20Michigan
c=US??sub?(cn=Babs%20Jensen
The next example is an LDAP URL referring to all children of the c=
entry
ldap://ldap.itd.umich.edu/c=GB?objectClass?
The objectClass attribute is requested to be returned along with
entries, and the default filter of "(objectclass=*)" is used
The next example is an LDAP URL to retrieve the mail attribute
the LDAP entry named "o=Question?,c=US" is given below,
the use of the escaping mechanism on the reserved character '?'.
ldap://ldap.question.com/o=Question%3f,c=US?
The next example illustrates the interaction between LDAP and
quoting mechanisms
ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \
encode three zero or null bytes in the value. In LDAP, the
would be written as (int=\00\00\00\04). Because the \ character
be escaped in a URL, the \'s are escaped as %5c in the URL encoding
The final example shows the use of the bindname extension to
the dn a client should use for authentication when resolving the URL
ldap:///??sub??bindname=cn=Manager%2co=
ldap:///??sub??!bindname=cn=Manager%2co=
The two URLs are the same, except that the second one marks
bindname extension as critical. Notice the use of the %
method to encode the comma in the distinguished name value in
Howes & Smith Standards Track [Page 7]
RFC 2255 LDAP URL Format December 1997
bindname extension
7. Security
General URL security considerations discussed in [5] are relevant
LDAP URLs
The use of security mechanisms when processing LDAP URLs
particular care, since clients may encounter many different
via URLs, and since URLs are likely to be processed automatically
without user intervention. A client SHOULD have a user-
policy about which servers to connect to using which
mechanisms, and SHOULD NOT make connections that are
with this policy
Sending authentication information, no matter the mechanism,
violate a user's privacy requirements. In the absence of
policy permitting authentication information to be sent to a server
a client should use an anonymous connection. (Note that
conforming to previous LDAP URL specifications, where all
are anonymous and unprotected, are consistent with
specification; they simply have the default security policy.)
Some authentication methods, in particular reusable passwords sent
the server, may reveal easily-abused information to the remote
or to eavesdroppers in transit, and should not be used in
processing unless explicitly permitted by policy. Confirmation
the human user of the use of authentication information
appropriate in many circumstances. Use of strong
methods that do not reveal sensitive information is much preferred
The LDAP URL format allows the specification of an arbitrary
search operation to be performed when evaluating the LDAP URL
Following an LDAP URL may cause unexpected results, for example,
retrieval of large amounts of data, the initiation of a long-
search, etc. The security implications of resolving an LDAP URL
the same as those of resolving an LDAP search query
8.
The LDAP URL format was originally defined at the University
Michigan. This material is based upon work supported by the
Science Foundation under Grant No. NCR-9416667. The support of
the University of Michigan and the National Science Foundation
gratefully acknowledged
Howes & Smith Standards Track [Page 8]
RFC 2255 LDAP URL Format December 1997
Several people have made valuable comments on this document.
particular RL "Bob" Morgan and Mark Wahl deserve special thanks
their contributions
9.
[1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
Protocol (v3): UTF-8 String Representation of Distinguished Names",
RFC 2253, December 1997.
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Protocol (v3)", RFC 2251, December 1997.
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "
Directory Access Protocol (v3): Attribute Syntax Definitions",
2252, December 1997.
[4] Howes, T., "A String Representation of LDAP Search Filters",
2254, December 1997.
[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Locators (URL)," RFC 1738, December 1994.
[6] Bradner, S., "Key Words for use in RFCs to Indicate
Levels," RFC 2119, March 1997.
Authors'
Tim
Netscape Communications Corp
501 E. Middlefield Rd
Mountain View, CA 94043
Phone: +1 415 937-3419
EMail: howes@netscape.
Mark
Netscape Communications Corp
501 E. Middlefield Rd
Mountain View, CA 94043
Phone: +1 415 937-3477
EMail: mcs@netscape.
Howes & Smith Standards Track [Page 9]
RFC 2255 LDAP URL Format December 1997
Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Howes & Smith Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
