idnits 2.17.1 draft-ietf-asid-ldap-format-03.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-25) 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 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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 is 1 instance 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 ...' == (22 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 153 looks like a reference -- Missing reference section? '2' on line 156 looks like a reference -- Missing reference section? '4' on line 163 looks like a reference -- Missing reference section? '3' on line 159 looks like a reference -- Missing reference section? '5' on line 166 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 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 18 December, 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 RFC DRAFT December 1995 39 3. URL Definition 41 An LDAP URL begins with the protocol prefix "ldap" and is defined by the 42 following grammar. 44 ::= "ldap://" [ ] "/" [ "?" 45 [ "?" "?" ] ] 47 ::= [ ":" ] 49 ::= a string as defined in RFC 1485 51 ::= NULL | 53 ::= 54 | [ "," ] 56 ::= a string as defined in RFC 1777 58 ::= "base" | "one" | "sub" 60 ::= a string as defined in RFC 1558 62 The ldap prefix indicates an entry or entries residing in the LDAP 63 server running on the given at the given . The 64 default port is TCP port 389. The is an LDAP Distinguished Name 65 using the string format described in [1], with any URL-illegal charac- 66 ters (e.g., spaces) escaped using the % method described in RFC 1738. 68 The construct is used to indicate which attributes should 69 be returned from the entry or entries. Individual names 70 are as defined for AttributeType in RFC 1777. If the part 71 is omitted, all attributes of the entry or entries should be returned. 73 The construct is used to specify the scope of the search to per- 74 form in the given LDAP server. The allowable scopes are "base" for a 75 base object search, "one" for a one-level search, or "sub" for a subtree 76 search. If is omitted, a scope of "base" is assumed. 78 The is used to specify the search filter to apply to entries 79 within the specified scope during the search. It has the format speci- 80 fied in [4], with any URL-illegal characters escaped using the % method 81 described in RFC 1738. If is omitted, a filter of 82 "(objectClass=*)" is assumed. 84 Note that if the entry resides in the X.500 namespace, it should be 85 reachable from any LDAP server that is providing front-end access to the 86 X.500 directory. If the part of the URL is missing, the URL 88 RFC DRAFT December 1995 90 can be resolved by contacting any X.500-back-ended LDAP server. 92 4. Examples 94 The following are some example LDAP URLs using the format defined above. 95 An LDAP URL referring to the University of Michigan entry, available 96 from any X.500-capable LDAP server: 98 ldap:///o=University%20of%20Michigan,c=US 100 An LDAP URL referring to the University of Michigan entry in a particu- 101 lar ldap server: 103 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US 105 This URL corresponds to a base object search of the "o=University of 106 Michigan, c=US" entry using a filter of (objectclass=*), requesting all 107 attributes. 109 An LDAP URL referring to only the postalAddress attribute of the Univer- 110 sity of Michigan entry: 112 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress 114 The corresponding LDAP search operation is the same as in the previous 115 example, except that only the postalAddress attribute is requested. 117 An LDAP URL referring to the set of entries found by querying any 118 X.500-capable LDAP server and doing a subtree search of the University 119 of Michigan for any entry with a common name of "Babs Jensen", retriev- 120 ing all attributes: 122 ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen) 124 An LDAP URL referring to all children of the c=GB entry: 126 ldap://ldap.itd.umich.edu/c=GB?objectClass?one 128 The objectClass attribute is requested to be returned along with the 129 entries. 131 5. Security Considerations 133 The LDAP URL format does not provide a way to specify credentials to use 134 when resolving the URL. Therefore, it is expected that such requests 135 will be unauthenticated. The security implications of resolving an LDAP 136 URL are the same as those of resolving any LDAP query. See the RFC 1777 137 for more details. 139 RFC DRAFT December 1995 141 6. Prototype Implementation Availability 143 There is a prototype implementation of the specification defined in this 144 document available. It is an extension to the libwww client library, 145 provided in both source and binary forms. Also included are binary ver- 146 sions of the Mosaic WWW client for various platforms. See the following 147 URL for more details: 149 ftp://terminator.rs.itd.umich.edu/ldap/url/ 151 7. Bibliography 153 [1] A String Representation of Distinguished Names. S. Kille, Request 154 for Comment (RFC) 1779, March 1995. 156 [2] Lightweight Directory Access Protocol. Wengyik Yeong, Tim Howes, 157 Steve Kille, Request for Comment (RFC) 1777, March 1995. 159 [3] The String Representation of Standard Attribute Syntaxes. T. 160 Howes, S. Kille, W. Yeong, C.J. Robbins; Request for Comment (RFC) 161 1778, March 1995 163 [4] A String Representation of LDAP Search Filters. T. Howes; Request 164 for Comment (RFC) 1558, December 1993 166 [5] Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. 167 McCahill; Request for Comment (RFC) 1738, December 1994. 169 8. Acknowledgements 171 This material is based upon work supported by the National Science Foun- 172 dation under Grant No. NCR-9416667. 174 9. Author's Address 176 Tim Howes 177 University of Michigan 178 ITD Research Systems 179 535 W William St. 180 Ann Arbor, MI 48103-4943 181 USA 182 +1 313 747-4454 183 tim@umich.edu 185 Mark Smith 186 University of Michigan 187 ITD Research Systems 188 535 W William St. 190 RFC DRAFT December 1995 192 Ann Arbor, MI 48103-4943 193 USA 194 +1 313 764-2277 195 mcs@umich.edu 197 This Internet Draft expires June 18, 1996.