view Side-By-Side changes
Date: Tue, 09 Apr 2002 00:51:46 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 02 Mar 1996 13:59:22 GMT ETag: "304d87-1f20-3138543a" Accept-Ranges: bytes Content-Length: 7968 Connection: close Content-Type: text/plain Network Working GroupTimT. HowesINTERNET DRAFT MarkRequest for Comments: 1959 M. Smith Category: Standards Track University of Michigan18 December, 1995June 1996 An LDAP URL Format<draft-ietf-asid-ldap-format-03.txt> 1.Status of this Memo This documentisspecifies anInternet-Draft. Internet-Drafts are working docu- ments ofInternet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six monthsrequests discussion andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material orsuggestions for improvements. Please refer tocite them other than as ``work in progress.'' To learnthe currentstatusedition ofany Internet-Draft, please check the ``1id-abstracts.txt'' listing contained intheInternet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2."Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 1. Abstract LDAP is the Lightweight Directory Access Protocol, defined in [1] and [2]. This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. While LDAP currently is used only as a front end to the X.500 directory, the URL format described here is general enough tohan- dlehandle the case of stand-alone LDAP servers (i.e., LDAP servers notback- endedback-ended by X.500).Howes & Smith [Page 1] RFC DRAFT December 1995 3.2. URL Definition An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar. <ldapurl> ::= "ldap://" [ <hostport> ] "/" <dn> [ "?" <attributes> [ "?" <scope> "?" <filter> ] ] <hostport> ::= <hostname> [ ":" <portnumber> ] <dn> ::= a string as defined in RFC 1485 <attributes> ::= NULL | <attributelist> <attributelist> ::= <attributetype> | <attributetype> [ "," <attributelist> ] <attributetype> ::= a string as defined in RFC 1777 <scope> ::= "base" | "one" | "sub" <filter> ::= a string as defined in RFC 1558 Howes & Smith Standards Track [Page 1] RFC 1959 An LDAP URL Format June 1996 The ldap prefix indicates an entry or entries residing in the LDAP server running on the given <hostname> at the given <portnumber>. The default port is TCP port 389. The <dn> is an LDAP Distinguished Name using the string format described in [1], with any URL-illegalcharac- terscharacters (e.g., spaces) escaped using the % method described in RFC 1738. The <attributes> construct is used to indicate which attributes should be returned from the entry or entries. Individual <attributetype> names are as defined for AttributeType in RFC 1777. If the <attributes> part is omitted, all attributes of the entry or entries should be returned. The <scope> construct is used to specify the scope of the search toper- formperform in the given LDAP server. The allowable scopes are "base" for a base object search, "one" for a one-level search, or "sub" for 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 entries within the specified scope during the search. It has the formatspeci- fiedspecified in [4], with any URL-illegal characters escaped using the % method described in RFC 1738. If <filter> is omitted, a filter of "(objectClass=*)" is assumed. Note that if the entry resides in the X.500 namespace, it should be reachable from any LDAP server that is providing front-end access to the X.500 directory. If the <hostport> part of the URL is missing, the URLHowes & Smith [Page 2] RFC DRAFT December 1995can be resolved by contacting any X.500-back-ended LDAP server.4.3. Examples The following are some example LDAP URLs using the format defined above. An LDAP URL referring to the University of Michigan entry, available from any X.500-capable LDAP server: ldap:///o=University%20of%20Michigan,c=US An LDAP URL referring to the University of Michigan entry in aparticu- larparticular ldap server: ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US This URL corresponds to a base object search of the "o=University of Michigan, c=US" entry using a filter of (objectclass=*), requesting all attributes. Howes & Smith Standards Track [Page 2] RFC 1959 An LDAP URL Format June 1996 An LDAP URL referring to only the postalAddress attribute of theUniver- sityUniversity of Michigan entry: ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress The corresponding LDAP search operation is the same as in the previous example, except that only the postalAddress attribute is requested. An LDAP URL referring to the set of entries found by querying any X.500-capable LDAP server and doing a subtree search of the University of Michigan for any entry with a common name of "Babs Jensen",retriev- ingretrieving all attributes: ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen) An LDAP URL referring to all children of the c=GB entry: ldap://ldap.itd.umich.edu/c=GB?objectClass?one The objectClass attribute is requested to be returned along with the entries.5.4. Security Considerations The LDAP URL format does not provide a way to specify credentials to use when resolving the URL. Therefore, it is expected that such requests will be unauthenticated. The security implications of resolving an LDAP URL are the same as those of resolving any LDAP query. See the RFC 1777 for more details.Howes & Smith [Page 3] RFC DRAFT December 1995 6.5. Prototype Implementation Availability There is a prototype implementation of the specification defined in this document available. It is an extension to the libwww client library, provided in both source and binary forms. Also included are binaryver- sionsversions of the Mosaic WWW client for various platforms. See the following URL for more details: ftp://terminator.rs.itd.umich.edu/ldap/url/7.Howes & Smith Standards Track [Page 3] RFC 1959 An LDAP URL Format June 1996 6. Bibliography [1]AKille, S., "A String Representation of DistinguishedNames. S. Kille, Request for Comment (RFC)Names", RFC 1779, March 1995. [2]Lightweight Directory Access Protocol. WengyikYeong,TimW., Howes,SteveT., and S. Kille,Request for Comment (RFC)"Lightweight Directory Access Protocol", RFC 1777, March 1995. [3]TheHowes, R., Kille, S., Yeong, W., and C. Robbins, "The String Representation of Standard AttributeSyntaxes. T. Howes, S. Kille, W. Yeong, C.J. Robbins; Request for Comment (RFC)Syntaxes", RFC 1778, March19951995. [4]AHowes, T., "A String Representation of LDAP SearchFilters. T. Howes; Request for Comment (RFC)Filters", RFC 1558, December19931993. [5]Uniform Resource Locators (URL). T.Berners-Lee,L.T., Masinter, L., and M.McCahill; Request for Comment (RFC)McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.8.7. Acknowledgements This material is based upon work supported by the National ScienceFoun- dationFoundation under Grant No. NCR-9416667.9. Author's Address8. Authors' Addresses Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943 USA Phone: +1 313 747-4454 EMail: tim@umich.edu Mark Smith University of Michigan ITD Research Systems 535 W William St.Howes & Smith [Page 4] RFC DRAFT December 1995Ann Arbor, MI 48103-4943 USA Phone: +1 313 764-2277 EMail: mcs@umich.eduThis Internet Draft expires June 18, 1996.Howes & Smith Standards Track [Page5]4] ----