idnits 2.17.1 draft-zeilenga-ldap-opattrs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 188 has weird spacing: '...for the purpo...' == 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 (1 November 2002) is 7845 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-zeilenga-ldap-features-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FEATURES' -- Obsolete informational reference (is this intentional?): RFC 2255 (Obsoleted by RFC 4510, RFC 4516) -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 1 November 2002 6 LDAPv3: All Operational Attributes 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as a Standard Track document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Extensions Working Group 18 mailing list . Please send editorial comments 19 directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright 2002, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Abstract 41 The Lightweight Directory Access Protocol (LDAP) supports a mechanism 42 for requesting the return of all user attributes but not all 43 operational attributes. This document describes an LDAP extension 44 which clients may use to request the return of all operational 45 attributes. 47 1. Overview 49 X.500 [X.500] provides a mechanism for clients to request all 50 operational attributes be returned with entries provided in response 51 to a search operation. This mechanism is often used by clients to 52 discover which operational attributes are present in an entry. 54 This documents extends the Lightweight Directory Access Protocol 55 (LDAP) [RFC3377] to provide a simple mechanism which clients may use 56 to request the return of all operational attributes. The mechanism is 57 designed for use with existing general purpose LDAP clients (including 58 web browsers which support LDAP URLs) and existing LDAP APIs. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in BCP 14 [RFC2119]. 64 2. All Operational Attributes 66 The presence of the attribute description "+" (ASCII 43) in the list 67 of attributes in a Search Request [RFC2251] SHALL signify a request 68 for the return of all operational attributes. 70 As with all search requests, client implementors should note that 71 results may not include all requested attributes due to access 72 controls or other restrictions. Client implementors should also note 73 that certain operational attributes may be returned only if requested 74 by name even when "+" is present. This is because some operational 75 attributes are very expensive to return. 77 Servers supporting this feature SHOULD publish the Object Identifier 78 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' 79 [FEATURES] attribute in the root DSE. 81 3. Interoperability Considerations 83 This mechanism is specifically designed to allow users to request all 84 operational attributes using existing LDAP clients. In particular, 85 the mechanism is designed to be compatible with existing general 86 purpose LDAP clients including those supporting LDAP URLs [RFC2255]. 88 The addition of this mechanism to LDAP is not believed to cause any 89 significant interoperability issues (this has been confirmed through 90 testing). Servers which have yet to implement this specification 91 should ignore the "+" as an unrecognized attribute description per 92 [RFC2251, Section 4.5.1]. From the client's perspective, a server 93 which does not return all operational attributes when "+" is requested 94 should be viewed as having other restrictions. 96 It is also noted that this mechanism is believed to require no 97 modification of existing LDAP APIs. 99 4. Security Considerations 101 This document provides a general mechanism which clients may use to 102 discover operational attributes. Prior to the introduction of this 103 mechanism, operational attributes where only returned when requested 104 by name. Some might have viewed this as obscurity" feature. However, 105 this sense of security as the attributes were still transferable. 107 Implementations SHOULD implement appropriate access controls 108 mechanisms to restricts access to operational attributes. 110 5. IANA Considerations 112 This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the 113 feature described above. This OID was assigned [ASSIGN] by OpenLDAP 114 Foundation, under its IANA-assigned private enterprise allocation 115 [PRIVATE], for use in this specification. 117 Registration of this feature is requested [FEATURES][RFC3383]. 119 Subject: Request for LDAP Protocol Mechanism Registration 121 Object Identifier: 1.3.6.1.4.1.4203.1.5.1 123 Description: All Op Attrs 125 Person & email address to contact for further information: 126 Kurt Zeilenga 128 Usage: Feature 130 Specification: RFCxxxx 132 Author/Change Controller: IESG 134 Comments: none 136 6. Acknowledgment 137 The "+" mechanism is believed to have been first suggested by Bruce 138 Greenblatt in a November 1998 post to the IETF LDAPext Working Group 139 mailing list. 141 7. Author's Address 143 Kurt D. Zeilenga 144 OpenLDAP Foundation 145 147 8. Normative References 149 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 150 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 152 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 153 Protocol (v3)", RFC 2251, December 1997. 155 [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol 156 (v3): Technical Specification", RFC 3377, September 2002. 158 [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga- 159 ldap-features-xx.txt (a work in progress). 161 9. Informative References 163 [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255, 164 December 1997. 166 [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also 167 RFC 3383), September 2002. 169 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 170 Models and Service", 1993. 172 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 173 http://www.openldap.org/foundation/oid-delegate.txt. 175 [PRIVATE] IANA, "Private Enterprise Numbers", 176 http://www.iana.org/assignments/enterprise-numbers. 178 Copyright 2002, The Internet Society. All Rights Reserved. 180 This document and translations of it may be copied and furnished to 181 others, and derivative works that comment on or otherwise explain it 182 or assist in its implementation may be prepared, copied, published and 183 distributed, in whole or in part, without restriction of any kind, 184 provided that the above copyright notice and this paragraph are 185 included on all such copies and derivative works. However, this 186 document itself may not be modified in any way, such as by removing 187 the copyright notice or references to the Internet Society or other 188 Internet organizations, except as needed for the purpose of 189 developing Internet standards in which case the procedures for 190 copyrights defined in the Internet Standards process must be followed, 191 or as required to translate it into languages other than English. 193 The limited permissions granted above are perpetual and will not be 194 revoked by the Internet Society or its successors or assigns. 196 This document and the information contained herein is provided on an 197 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 198 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 199 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 200 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 201 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.