idnits 2.17.1 draft-ietf-asid-ldap-format-01.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...fts are worki...' == Line 13 has weird spacing: '...ments of the ...' == Line 14 has weird spacing: '...t other group...' == Line 18 has weird spacing: '...and may be ...' == Line 22 has weird spacing: '...atus of any ...' == (25 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '1' on line 155 looks like a reference -- Missing reference section? '2' on line 158 looks like a reference -- Missing reference section? '3' on line 161 looks like a reference -- Missing reference section? '4' on line 165 looks like a reference -- Missing reference section? '5' on line 168 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tim Howes 3 INTERNET DRAFT Mark Smith 4 University of Michigan 5 20 September, 1995 7 An LDAP URL Format 8 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 2. Abstract 29 LDAP is the Lightweight Directory Access Protocol, defined in [1] and 30 [2]. This document describes a format for an LDAP Uniform Resource 31 Locator which will allow Internet clients to have direct access to the 32 LDAP protocol. While LDAP currently is used only as a front end to the 33 X.500 directory, the URL format described here is general enough to han- 34 dle the case of stand-alone LDAP servers (i.e., LDAP servers not back- 35 ended by X.500). 37 This document is meant to provide information to the Internet community. 38 The format it describes is at the experimental stage. It is anticipated 39 that once more experience with the format is gained, a standards track 40 version of this document will be pursued. Please send comments to the 41 authors. 43 RFC DRAFT September 1995 45 3. URL Definition 47 An LDAP URL begins with the protocol prefix "ldap" and is defined by the 48 following grammar. 50 ::= "ldap://" [ ] "/" [ "?" 51 [ "?" "?" ] ] 53 ::= [ ":" ] 55 ::= a string as defined in RFC 1485 57 ::= NULL | 59 ::= | [ "," ] 61 ::= a string as defined in RFC 1487 63 ::= "base" | "one" | "sub" 65 ::= a string as defined in RFC 1558 67 The ldap prefix indicates an entry or entries residing in the LDAP 68 server running on the given at the given . The 69 default port is TCP port 389. The is an LDAP Distinguished Name 70 using the string format described in [1], with any URL-illegal charac- 71 ters (e.g., spaces) escaped using the % method described in RFC 1738. 73 The construct is used to indicate which attributes should 74 be returned from the entry or entries. Individual attribute names are 75 as defined in [3]. If the part is omitted, all attributes 76 of the entry or entries should be returned. 78 The construct is used to specify the scope of the search to per- 79 form in the given LDAP server. The allowable scopes are "base" for a 80 base object search, "one" for a one-level search, or "sub" for a subtree 81 search. The default is "base". 83 The is used to specify the search filter to apply to entries 84 within the specified scope during the search. It has the format speci- 85 fied in [4]. The default is "(objectClass=*)". 87 Note that if the entry resides in the X.500 namespace, it should be 88 reachable from any LDAP server that is providing front-end access to the 89 X.500 directory. If the part of the URL is missing, the URL 90 can be resolved by contacting any X.500-back-ended LDAP server. 92 RFC DRAFT September 1995 94 4. Examples 96 The following are some example LDAP URLs using the format defined above. 97 An LDAP URL referring to the University of Michigan entry, available 98 from any X.500-capable LDAP server: 100 ldap:///o=University%20of%20Michigan,c=US 102 An LDAP URL referring to the University of Michigan entry in a particu- 103 lar ldap server: 105 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US 107 This URL corresponds to a base object search of the "o=University of 108 Michigan, c=US" entry using a filter of (objectclass=*), requesting all 109 attributes. 111 An LDAP URL referring to only the postalAddress attribute of the Univer- 112 sity of Michigan entry: 114 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress 116 The corresponding LDAP search operation is the same as in the previous 117 example, except that only the postalAddress attribute is requested. 119 An LDAP URL referring to the set of entries found by qyerying any 120 X.500-capable LDAP server and doing a subtree search of the University 121 of Michigan for any entry with a common name of "Babs Jensen", retriev- 122 ing all attributes: 124 ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen) 126 An LDAP URL referring to all children of the c=GB entry: 128 ldap://ldap.itd.umich.edu/c=GB?objectClass?one 130 The objectClass attribute is requested to be returned along with the 131 entries. 133 5. Security Considerations 135 The LDAP URL format does not provide a way to specify credentials to use 136 when resolving the URL. Therefore, it is expected that such requests 137 will be unauthenticated. The security implications of resolving an LDAP 138 URL are the same as those of resolving any LDAP query. See the RFC 1777 139 for more details. 141 RFC DRAFT September 1995 143 6. Prototype Implementation Availability 145 There is a prototype implementation of the specification defined in this 146 document available. It is an extension to the libwww client library, 147 provided in both source and binary forms. Also included are binary ver- 148 sions of the Mosaic WWW client for various platforms. See the following 149 URL for more details: 151 ftp://terminator.rs.itd.umich.edu/ldap/url/ 153 7. Bibliography 155 [1] A String Representation of Distinguished Names. S. Kille, Request 156 for Comment (RFC) 1779, March 1995. 158 [2] Lightweight Directory Access Protocol. Wengyik Yeong, Tim Howes, 159 Steve Kille, Request for Comment (RFC) 1777, March 1995. 161 [3] The String Representation of Standard Attribute Syntaxes. T. 162 Howes, S. Kille, W. Yeong, C.J. Robbins; Request for Comment (RFC) 163 1778, March 1995 165 [4] A String Representation of LDAP Search Filters. T. Howes; Request 166 for Comment (RFC) 1558, December 1993 168 [5] Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. 169 McCahill; Request for Comment (RFC) 1738, December 1994. 171 8. Acknowledgements 173 This material is based upon work supported by the National Science Foun- 174 dation under Grant No. NCR-9416667. 176 9. Author's Address 178 Tim Howes 179 University of Michigan 180 ITD Research Systems 181 535 W William St. 182 Ann Arbor, MI 48103-4943 183 USA 184 +1 313 747-4454 185 tim@umich.edu 187 Mark Smith 188 University of Michigan 189 ITD Research Systems 190 535 W William St. 192 RFC DRAFT September 1995 194 Ann Arbor, MI 48103-4943 195 USA 196 +1 313 764-2277 197 mcs@umich.edu 199 This Internet Draft expires March 20, 1996.