idnits 2.17.1 draft-ietf-asid-ldap-format-00.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-19) 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 3 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 11 has weird spacing: '...fts are worki...' == Line 12 has weird spacing: '...ments of the ...' == Line 13 has weird spacing: '...t other group...' == Line 17 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '...atus of any ...' == (23 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 145 looks like a reference -- Missing reference section? '2' on line 148 looks like a reference -- Missing reference section? '3' on line 151 looks like a reference -- Missing reference section? '4' on line 155 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Howes 2 INTERNET DRAFT Mark Smith 3 University of Michigan 4 14 March, 1995 6 An LDAP URL Format 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 2. Abstract 28 LDAP is the Lightweight Directory Access Protocol, defined in [1] and 29 [2]. This document describes a format for an LDAP Uniform Resource 30 Locator which will allow World Wide Web clients to have direct access to 31 the LDAP protocol. While LDAP currently is used only as a front end to 32 the X.500 directory, the URL format described here is general enough to 33 handle the case of stand-alone LDAP servers (i.e., LDAP servers not 34 back-ended by X.500). 36 This document is meant to provide information to the Internet community. 37 The format it describes is at the experimental stage. It is anticipated 38 that once more experience with the format is gained, a standards track 39 version of this document will be pursued. Please send comments to the 40 authors. 42 RFC DRAFT March 1995 44 3. URL Definition 46 An LDAP URL begins with the protocol prefix "ldap" and is defined by the 47 following grammar. 49 ::= "ldap://" [ ] "/" [ "?" 50 [ "?" "?" ] ] 52 ::= [ ":" ] 54 ::= a string as defined in RFC 1485 56 ::= NULL | 58 ::= | [ "," ] 60 ::= a string as defined in RFC 1487 62 ::= "base" | "one" | "sub" 64 ::= a string as defined in RFC 1558 66 The ldap prefix indicates an entry or entries residing in the LDAP 67 server running on the given at the given . The 68 default port is TCP port 389. The is an LDAP Distinguished Name 69 using the string format described in [1], with any URL-illegal charac- 70 ters (e.g., spaces) escaped using the % method. 72 The construct is used to indicate which attributes should 73 be returned from the entry or entries. Individual attribute names are 74 as defined in [3]. If the part is omitted, all attributes 75 of the entry or entries should be returned. 77 The construct is used to specify the scope of the search to per- 78 form in the given LDAP server. The allowable scopes are "base" for a 79 base object search, "one" for a one-level search, or "sub" for a subtree 80 search. The default is "base". 82 The is used to specify the search filter to apply to entries 83 within the specified scope during the search. It has the format speci- 84 fied in [4]. The default is "(objectClass=*)". 86 Note that if the entry resides in the X.500 namespace, it should be 87 reachable from any LDAP server that is providing front-end access to the 88 X.500 directory. If the part of the URL is missing, the URL 89 can be resolved by contacting any X.500-back-ended LDAP server. 91 RFC DRAFT March 1995 93 4. Examples 95 The following are some example LDAP URLs using the format defined above. 97 An LDAP URL referring to the University of Michigan entry: 99 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US 101 This URL corresponds to a base object search of the "o=University of 102 Michigan, c=US" entry using a filter of (objectclass=*), requesting all 103 attributes. 105 An LDAP URL referring to only the postalAddress attribute of the Univer- 106 sity of Michigan entry: 108 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress 110 The corresponding LDAP search operation is the same as in the previous 111 example, except that only the postalAddress attribute is requested. 113 An LDAP URL referring to the set of entries found by qyerying any 114 X.500-capable LDAP server and doing a subtree search of the University 115 of Michigan for any entry with a common name of "Babs Jensen", retriev- 116 ing all attributes: 118 ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen) 120 An LDAP URL referring to all children of the c=GB entry: 122 ldap://ldap.itd.umich.edu/c=GB?objectClass?one 124 The objectClass attribute is requested to be returned along with the 125 entries. 127 5. Security Considerations 129 Security considerations are not discussed in this document. 131 6. Prototype Implementation Availability 133 There is a prototype implementation of the specification defined in this 134 document available. It is an extension to the libwww client library, 135 provided in both source and binary forms. Also included are binary ver- 136 sions of the Mosaic WWW client for various platforms. See the following 137 URL for more details: 139 ftp://terminator.rs.itd.umich.edu/ldap/url/ 141 RFC DRAFT March 1995 143 7. Bibliography 145 [1] A String Representation of Distinguished Names. S. Kille, Request 146 for Comment (RFC) 1485, July 1993 148 [2] Lightweight Directory Access Protocol. Wengyik Yeong, Tim Howes, 149 Steve Kille, Request for Comment (RFC) 1487, July 1993 151 [3] The String Representation of Standard Attribute Syntaxes. T. 152 Howes, S. Kille, W. Yeong, C.J. Robbins; Request for Comment (RFC) 153 1488, July 1993 155 [4] A String Representation of LDAP Search Filters. T. Howes; Request 156 for Comment (RFC) 1558, December 1993 158 8. Acknowledgements 160 This material is based upon work supported by the National Science Foun- 161 dation under Grant No. NCR-9416667. 163 9. Author's Address 165 Tim Howes 166 University of Michigan 167 ITD Research Systems 168 535 W William St. 169 Ann Arbor, MI 48103-4943 170 USA 171 +1 313 747-4454 172 tim@umich.edu 174 Mark Smith 175 University of Michigan 176 ITD Research Systems 177 535 W William St. 178 Ann Arbor, MI 48103-4943 179 USA 180 +1 313 764-2277 181 mcs@umich.edu 183 This Internet Draft expires September 14, 1995.