idnits 2.17.1 draft-zeilenga-ldapv3bis-opattrs-06.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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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.) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 187 has weird spacing: '...for the purpo...' -- 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 April 2001) is 8425 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) -- Missing reference section? 'RFC2251' on line 154 looks like a reference -- Missing reference section? 'RFC2119' on line 57 looks like a reference -- Missing reference section? '5' on line 119 looks like a reference -- Missing reference section? 'RFC 2255' on line 129 looks like a reference -- Missing reference section? 'RFC2219' on line 151 looks like a reference -- Missing reference section? 'RFC2255' on line 157 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: 1 October 2001 1 April 2001 5 Updates: RFC 2251 7 LDAPv3: All Operational Attributes 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of this 18 document will take place on the IETF LDAP Extensions Working Group 19 mailing list . Please send editorial 20 comments directly to the author . 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 32 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 34 Copyright 2001, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 2. Overview 41 X.500 [X.500] provides a mechanism for clients to request all 42 operational attributes be returned with entries provided in response 43 to a search operation. This mechanism is often used by clients to 44 discover which operational attributes are present in an entry. LDAP 45 [RFC2251] does not provide a similar mechanism to clients. 47 This document defines a simple mechanism which clients may use to 48 request the return of all operation attributes. The mechanism is 49 designed for use with existing general purpose LDAP clients (including 50 web browsers which support LDAP URLs). This document updates the 51 LDAPv3 technical specification as detailed below. 53 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 54 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in 55 this document are to be interpreted as described in RFC 2119 56 [RFC2119]. 58 3. Changes to LDAP version 3 60 This document updates RFC 2251 as follows: 62 In Section 3.2.1, Attributes of Entries, the paragraph: 63 Some attributes, termed operational attributes, are used by 64 servers for administering the directory system itself. They are 65 not returned in search results unless explicitly requested by 66 name. Attributes which are not operational, such as "mail", will 67 have their schema and syntax constraints enforced by servers, but 68 servers will generally not make use of their values. 70 is replaced with: 71 Some attributes, termed operational attributes, are used by 72 servers for administering the directory system itself. They are 73 not returned in search results unless explicitly requested. 74 Attributes which are not operational, such as "mail", will have 75 their schema and syntax constraints enforced by servers, but 76 servers will generally not make use of their values. 78 In Section 4.5.1, Search Request, the paragraph: 79 - attributes: A list of the attributes to be returned from each 80 entry which matches the search filter. There are two special 81 values which may be used: an empty list with no attributes, and 82 the attribute description string "*". Both of these signify that 83 all user attributes are to be returned. (The "*" allows the 84 client to request all user attributes in addition to specific 85 operational attributes). 87 is replaced with: 88 - attributes: A list of the attributes to be returned from each 89 entry which matches the search filter. There are three special 90 values which may be used. An empty list with no attributes 91 signifies that all user attributes are to be returned. An 92 attribute list containing the attribute description string "*" 93 signifies that all user attributes are to be returned. An 94 attribute list containing the attribute description string "+" 95 signifies that all operational attributes are to be returned. 96 (The "*" allows the client to request all user attributes in 97 addition to any requested operational attributes. The "+" allows 98 the client to request all operational attributes in addition to 99 requested user attributes. A client may list both "*" and "+" to 100 request all attributes.) 102 and the paragraph: 103 Client implementors should note that even if all user attributes 104 are requested, some attributes of the entry may not be included in 105 search results due to access control or other restrictions. 106 Furthermore, servers will not return operational attributes, such 107 as objectClasses or attributeTypes, unless they are listed by 108 name, since there may be extremely large number of values for 109 certain operational attributes. (A list of operational attributes 110 for use in LDAP is given in [5].) 112 is replaced with: 113 Client implementors should note that results may not include all 114 requested attributes due to access controls or other restrictions. 115 Furthermore, servers will not return operational attributes, such 116 as objectClasses or attributeTypes, unless they are requested (by 117 name or by "+"), since there may be extremely large number of 118 values for certain operational attributes. (A list of operational 119 attributes for use in LDAP is given in [5].) Clients should also 120 note that certain operational attributes may be returned only if 121 requested by name. 123 5. Interoperability Considerations 125 This mechanism is specifically designed to allow users to request all 126 operational attributes using existing LDAP clients. In particular, 127 the mechanism is designed to be compatible with existing general 128 purpose LDAP clients includes web browsers which support LDAP URLs 129 [RFC 2255]. 131 The addition of this mechanism to LDAPv3 is believed not to cause any 132 significant interoperability issues (this has been confirmed through 133 testing). Servers which have yet to implement this specification 134 should ignore the "+" as an unrecognized attribute description per 135 [RFC 2251, Section 4.5.1]. From the client's perspective, a server 136 which does not return all operational attributes when "+" is requested 137 should be viewed as having other restrictions. 139 It is also noted that this mechanism is believed to require no 140 modification of existing LDAP SDKs. 142 6. Security Considerations 144 This document provides a mechanism which clients may use to discover 145 operational attributes. Those relying on security by obscurity should 146 implement appropriate access controls to restricts access to 147 operational attributes per local policy. 149 7. Bibliography 151 [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate 152 Requirement Levels", RFC 2119, March 1997. 154 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 155 Protocol (v3)", RFC 2251, December 1997. 157 [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255, 158 December 1997. 160 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 161 Models and Service", 1993. 163 8. Acknowledgment 165 The "+" mechanism is believed to have been first suggested by Bruce 166 Greenblatt in a November 1998 post to the IETF LDAPext Working Group 167 mailing list. 169 9. Author's Address 171 Kurt D. Zeilenga 172 OpenLDAP Foundation 173 175 10. Full Copyright 177 Copyright 2001, The Internet Society. All Rights Reserved. 179 This document and translations of it may be copied and furnished to 180 others, and derivative works that comment on or otherwise explain it 181 or assist in its implementation may be prepared, copied, published and 182 distributed, in whole or in part, without restriction of any kind, 183 provided that the above copyright notice and this paragraph are 184 included on all such copies and derivative works. However, this 185 document itself may not be modified in any way, such as by removing 186 the copyright notice or references to the Internet Society or other 187 Internet organizations, except as needed for the purpose of 188 developing Internet standards in which case the procedures for 189 copyrights defined in the Internet Standards process must be followed, 190 or as required to translate it into languages other than English. 192 The limited permissions granted above are perpetual and will not be 193 revoked by the Internet Society or its successors or assigns. 195 This document and the information contained herein is provided on an 196 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 197 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 198 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 199 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 200 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.