idnits 2.17.1 draft-zeilenga-ldap-adlist-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 259. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 223), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (18 July 2005) is 6819 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- No information found for draft-zeilenga-ldap-readentry-xx - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Informational OpenLDAP Foundation 4 Expires in six months 18 July 2005 6 Requesting Attributes by Object Class in the 7 Lightweight Directory Access Protocol 8 10 Status of this Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as an Informational document. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document will take place on the IETF LDAP Extensions mailing list 16 . Please send editorial comments directly to the 17 author . 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware have 21 been or will be disclosed, and any of which he or she becomes aware 22 will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 The Lightweight Directory Access Protocol (LDAP) search operation 47 provides mechanisms for clients to request all user application 48 attributes, all operational attributes, and/or attributes selected by 49 their description. This document extends LDAP to support a mechanism 50 that LDAP clients may use to request the return of all attributes of 51 an object class. 53 1. Background and Intended Use 55 In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the 56 search operation [Protocol] support requesting the return of a set of 57 attributes. This set is determined by a list of attribute 58 descriptions. Two special descriptors are defined to request all user 59 attributes ("*") [Protocol] and all operational attributes ("+") 60 [RFC3673]. However, there is no convenient mechanism for requesting 61 pre-defined sets of attributes such as the set of attributes used to 62 represent a particular class of object. 64 This document extends LDAP to allow an object class identifier to be 65 specified in attributes lists, such as in Search requests, to request 66 the return all attributes belonging to an object class. The 67 COMMERCIAL AT ("@", U+0040) character is used to distinguish an object 68 class identifier from an attribute descriptions. 70 For example, the attribute list of "@country" is equivalent to the 71 attribute list of 'c', 'searchGuide', 'description', and 72 'objectClass'. This object class is described in [Schema]. 74 This extension is intended primarily to be used where the user is in 75 direct control of the parameters of the LDAP search operation, for 76 instance when entering a LDAP URL [LDAPURL] into a web browser. For 77 example, . 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in BCP 14 [RFC2119]. 85 DSA stands for Directory System Agent (or server). 86 DSE stands for DSA-specific Entry. 88 3. Return of all Attributes of an Object Class 89 This extension allows object class identifiers is to be provided in 90 the attributes field of the LDAP SearchRequest [Protocol] or other 91 request values of the AttributeSelection data type (e.g., attributes 92 field in pre/post read controls [ReadEntry]) and/or 93 production (e.g., attributes of an LDAP URL 94 [LDAPURL]). For each object class identified in the attributes field, 95 the request is to be treated as if each attribute allowed by that 96 class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was 97 itself listed. 99 This extension extends attributeSelector [Protocol] production as 100 indicated by the following ABNF [ABNF]: 102 attributeSelector /= objectclassdescription 103 objectclassdescription = ATSIGN oid options 104 ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040) 106 where and productions are as defined in [Models]. 108 The component of an production 109 identifies the object class by short name (descr) or object identifier 110 (numericoid). If the value of the component is unrecognized or 111 does not refer to an object class, the object class description is be 112 treated an an unrecognized attribute description. 114 The production is included in the grammar for extensibility 115 purposes. An object class description with an unrecognized or 116 inappropriate option is to be treated as an unrecognized. 118 While object class description options and attribute description 119 options share the same syntax, they are not semantically related. 120 This document does not define any object description option. 122 Servers supporting this feature SHOULD publish the object identifier 123 (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures' 124 [Models] attribute in the root DSE. Clients supporting this feature 125 SHOULD NOT use the feature unless they have knowledge the server 126 supports it. 128 3. Security Considerations 130 This extension provides a shorthand for requesting all attributes of 131 an object class. As these attributes which could have been listed 132 individually, introduction of this shorthand is not believed to raise 133 additional security considerations. 135 Implementors of this LDAP extension should be familiar with security 136 considerations applicable to the LDAP search operation [Protocol], as 137 well as general LDAP security considerations [Roadmap]. 139 4. IANA Considerations 141 Registration of the LDAP Protocol Mechanism [BCP64bis] defined in 142 document is requested. 144 Subject: Request for LDAP Protocol Mechanism Registration 145 Object Identifier: 1.3.6.1.4.1.4203.1.5.2 146 Description: OC AD Lists 147 Person & email address to contact for further information: 148 Kurt Zeilenga 149 Usage: Feature 150 Specification: RFC XXXX 151 Author/Change Controller: Kurt Zeilenga 152 Comments: none 154 This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its 155 IANA-assigned private enterprise allocation [PRIVATE], for use in this 156 specification. 158 5. Author's Address 160 Kurt D. Zeilenga 161 OpenLDAP Foundation 163 Email: Kurt@OpenLDAP.org 165 6. References 167 [[Note to the RFC Editor: please replace the citation tags used in 168 referencing Internet-Drafts with tags of the form RFCnnnn where 169 possible.]] 171 6.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 176 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 177 Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a 178 work in progress. 180 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 181 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 182 progress. 184 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 185 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 187 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 188 Models", draft-ietf-ldapbis-models-xx.txt, a work in 189 progress. 191 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 192 draft-ietf-ldapbis-url-xx.txt, a work in progress. 194 [X.680] International Telecommunication Union - 195 Telecommunication Standardization Sector, "Abstract 196 Syntax Notation One (ASN.1) - Specification of Basic 197 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 199 6.2. Informative References 201 [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC 202 3673, December 2003. 204 [Schema] Dally, K. (editor), "LDAP: User Schema", 205 draft-ietf-ldapbis-user-schema-xx.txt, a work in 206 progress. 208 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 209 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 211 [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls", 212 draft-zeilenga-ldap-readentry-xx.txt, a work in 213 progress. 215 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 216 http://www.openldap.org/foundation/oid-delegate.txt. 218 [PRIVATE] IANA, "Private Enterprise Numbers", 219 http://www.iana.org/assignments/enterprise-numbers. 221 Full Copyright 223 Copyright (C) The Internet Society (2005). 225 This document is subject to the rights, licenses and restrictions 226 contained in BCP 78, and except as set forth therein, the authors 227 retain all their rights. 229 This document and the information contained herein are provided on an 230 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 231 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 232 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 233 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 234 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 235 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 237 Intellectual Property Rights 239 The IETF takes no position regarding the validity or scope of any 240 Intellectual Property Rights or other rights that might be claimed to 241 pertain to the implementation or use of the technology described in 242 this document or the extent to which any license under such rights 243 might or might not be available; nor does it represent that it has 244 made any independent effort to identify any such rights. Information 245 on the procedures with respect to rights in RFC documents can be found 246 in BCP 78 and BCP 79. 248 Copies of IPR disclosures made to the IETF Secretariat and any 249 assurances of licenses to be made available, or the result of an 250 attempt made to obtain a general license or permission for the use of 251 such proprietary rights by implementers or users of this specification 252 can be obtained from the IETF on-line IPR repository at 253 http://www.ietf.org/ipr. 255 The IETF invites any interested party to bring to its attention any 256 copyrights, patents or patent applications, or other proprietary 257 rights that may cover technology that may be required to implement 258 this standard. Please address the information to the IETF at 259 ietf-ipr@ietf.org.