home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldapv3-url-01.txt < prev    next >
Text File  |  1997-04-21  |  8KB  |  239 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        Tim Howes
  8. INTERNET DRAFT                                              Mark Smith
  9. OBSOLETES: RFC 1959                      Netscape Communications Corp.
  10. Expires in six months                                       April 1997
  11.  
  12.  
  13.                           The LDAP URL Format
  14.                   <draft-ietf-asid-ldapv3-url-01.txt>
  15.  
  16.  
  17.  
  18. 1.  Status of this Memo
  19.  
  20. This document is an Internet-Draft.  Internet-Drafts are  working  docu-
  21. ments  of the Internet Engineering Task Force (IETF), its areas, and its
  22. working groups.  Note that other  groups  may  also  distribute  working
  23. documents as Internet-Drafts.
  24.  
  25. Internet-Drafts are draft documents valid for a maximum  of  six  months
  26. and  may  be  updated,  replaced, or obsoleted by other documents at any
  27. time.  It is inappropriate to use Internet- Drafts as reference material
  28. or to cite them other than as ``work in progress.''
  29.  
  30. To learn the current status of  any  Internet-Draft,  please  check  the
  31. ``1id-abstracts.txt''  listing  contained in the Internet- Drafts Shadow
  32. Directories on ds.internic.net (US East Coast), nic.nordu.net  (Europe),
  33. ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  34.  
  35. 2.  Abstract
  36.  
  37. LDAP is the Lightweight Directory Access Protocol, defined in  [1],  [2]
  38. and  [3].  This document describes a format for an LDAP Uniform Resource
  39. Locator.  The format describes an LDAP search operation  to  perform  to
  40. retrieve  information from an LDAP directory. This document replaces RFC
  41. 1959. It updates the LDAP URL format for version 3 of LDAP.  This  docu-
  42. ment  also  defines a second URL scheme prefix for LDAP running over the
  43. TLS protocol defined in [6].
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Howes & Smith                                                   [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. RFC DRAFT                                                     April 1997
  65.  
  66.  
  67. 3.  URL Definition
  68.  
  69. An LDAP URL begins with  the  protocol  prefix  "ldap"  (or  the  prefix
  70. "ldaps" for LDAP over TLS) and is defined by the following grammar.
  71.  
  72.     ldapurl    = scheme "://" [hostport] "/"
  73.                  [dn ["?" [attributes] ["?" [scope]
  74.                  ["?" [filter]]]]]
  75.     scheme     = "ldap" / "ldaps"
  76.     attributes = [attrdesc *("," attrdesc)]
  77.     scope      = "base" / "one" / "sub"
  78.     dn         = distinguishedName from Section 3 of [1]
  79.     hostport   = hostport from Section 5 of RFC 1738 [5]
  80.     attrdesc   = AttributeDescription from Section 4.1.5 of [2]
  81.     filter     = filter from Section 4 of [4]
  82.  
  83. The "ldap" and "ldaps" prefixes indicate an entry or entries residing in
  84. the  LDAP  server running on the given hostname at the given portnumber.
  85. For regular LDAP servers, the default port is TCP port  389.   For  LDAP
  86. servers running over the TLS protocol [6], the default port is 636.
  87.  
  88. The dn is an LDAP Distinguished Name using the string  format  described
  89. in [1]. It identifies the base object of the LDAP search.
  90.  
  91. The attributes construct is used to indicate which attributes should  be
  92. returned  from  the  entry or entries.  Individual attrdesc names are as
  93. defined for AttributeDescription in [2].   If  the  attributes  part  is
  94. omitted, all attributes of the entry or entries should be returned.
  95.  
  96. The scope construct is used to specify the scope of the search  to  per-
  97. form  in  the  given LDAP server.  The allowable scopes are "base" for a
  98. base object search, "one" for a one-level search, or "sub" for a subtree
  99. search.  If scope is omitted, a scope of "base" is assumed.
  100.  
  101. The filter is used to specify the search  filter  to  apply  to  entries
  102. within  the specified scope during the search.  It has the format speci-
  103. fied in [4].  If filter is omitted, a  filter  of  "(objectClass=*)"  is
  104. assumed.
  105.  
  106. If the entry or entries reside in the X.500 namespace,  they  should  be
  107. reachable from any LDAP server that is providing front-end access to the
  108. X.500 directory. If the hostport part of the URL is missing, the URL can
  109. be resolved by contacting any X.500-back-ended LDAP server.
  110.  
  111. Note that any URL-illegal characters (e.g.,  spaces)  and  the  reserved
  112. character '?' occurring inside a dn, filter, or other element of an LDAP
  113. URL must be escaped using the % method described in RFC 1738 [5].
  114.  
  115.  
  116.  
  117.  
  118. Howes & Smith                                                   [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. RFC DRAFT                                                     April 1997
  125.  
  126.  
  127. 4.  Examples
  128.  
  129. The following are some example LDAP URLs using the format defined above.
  130. An  LDAP  URL  referring  to the University of Michigan entry, available
  131. from any X.500-capable LDAP server:
  132.  
  133.   ldap:///o=University%20of%20Michigan,c=US
  134.  
  135. An LDAP URL referring to the University of Michigan entry in a  particu-
  136. lar ldap server:
  137.  
  138.   ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
  139.  
  140. This URL corresponds to a base object search  of  the  "o=University  of
  141. Michigan,  c=US" entry using a filter of (objectclass=*), requesting all
  142. attributes.
  143.  
  144. An LDAP URL referring to only the postalAddress attribute of the Univer-
  145. sity of Michigan entry:
  146.  
  147.   ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
  148.  
  149. The corresponding LDAP search operation is the same as in  the  previous
  150. example, except that only the postalAddress attribute is requested.
  151.  
  152. An LDAP URL referring to the  set  of  entries  found  by  querying  any
  153. X.500-capable  LDAP  server and doing a subtree search of the University
  154. of Michigan for any entry with a common name of "Babs Jensen",  retriev-
  155. ing all attributes:
  156.  
  157.   ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
  158.  
  159. A secure LDAP URL referring to all children of the c=GB entry:
  160.  
  161.   ldaps://ldap.itd.umich.edu/c=GB?objectClass?one
  162.  
  163. The objectClass attribute is requested to be  returned  along  with  the
  164. entries, and the default filter of "(objectclass=*)" is used.
  165.  
  166. An LDAP URL to retrieve the mail attribute  for  the  LDAP  entry  named
  167. "o=Question?,c=US"  is given below, illustrating the use of the escaping
  168. mechanism on the reserved character '?'.
  169.  
  170.   ldap://ldap.question.com/o=Question%3f,c=US?mail
  171.  
  172. 5.  Security Considerations
  173.  
  174. The LDAP URL format does not provide a way to specify credentials to use
  175.  
  176.  
  177.  
  178. Howes & Smith                                                   [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. RFC DRAFT                                                     April 1997
  185.  
  186.  
  187. when  resolving  the  URL.  Therefore, it is expected that such requests
  188. will be unauthenticated, unless some out-of-band mechanism is used.
  189.  
  190. The LDAP URL format allows the specification of an arbitrary LDAP search
  191. operation  to  be  performed when evaluating the LDAP URL.  Following an
  192. LDAP URL may cause unexpected results, for  example,  the  retrieval  of
  193. large  amounts of data, the initiation of a long-lived search, etc.  The
  194. security implications of resolving an LDAP URL are the same as those  of
  195. resolving an LDAP search query.
  196.  
  197. 6.  References
  198.  
  199. [1]  Lightweight Directory Access Protocol (v3): UTF-8 String  Represen-
  200.      tation  of  Distinguished  Names.   M.  Wahl, S. Kille, draft-ietf-
  201.      asid-ldapv3-dn-02.txt, March 1997.
  202.  
  203. [2]  Lightweight Directory Access Protocol (v3).  M. Wahl, T. Howes,  S.
  204.      Kille, draft-ietf-asid-ldapv3-protocol-04.txt, March 1997.
  205.  
  206. [3]  Lightweight Directory Access Protocol (v3): Attribute Syntax Defin-
  207.      itions.   M.  Wahl,  A.  Coulbeck,  T. Howes, S. Kille, draft-ietf-
  208.      asid-ldapv3-attributes-04.txt, March 1997.
  209.  
  210. [4]  A String Representation of LDAP Search Filters.  T.  Howes,  draft-
  211.      ietf-asid-ldapv3-filter.00.txt, March 1997.
  212.  
  213. [5]  Uniform Resource Locators (URL). T. Berners-Lee,  L.  Masinter,  M.
  214.      McCahill, Request for Comment (RFC) 1738, December 1994.
  215.  
  216. [6]  The TLS Protocol Version 1.0., T.  Dierks,  C.  Allen,  draft-ietf-
  217.      tls-protocol-02.txt, March 1997.
  218.  
  219. 7.  Author's Address
  220.  
  221.    Tim Howes
  222.    Netscape Communications Corp.
  223.    501 E. Middlefield Rd.
  224.    Mountain View, CA 94043
  225.    USA
  226.    +1 415 937-3419
  227.    howes@netscape.com
  228.  
  229.    Mark Smith
  230.    501 E. Middlefield Rd.
  231.    Mountain View, CA 94043
  232.    USA
  233.    +1 415 937-3477
  234.    mcs@netscape.com
  235.  
  236.  
  237.  
  238. Howes & Smith                                                   [Page 4]
  239.