1 INTERNET-DRAFT Kurt D. Zeilenga
2 Intended Category: Standard Track OpenLDAP Foundation
3 Expires: 29 December 2000 29 June 2000
6 LDAPv3: All Operational Attributes
7 <draft-zeilenga-ldapv3bis-opattrs-00.txt>
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 Extension Working Group
19 mailing list <ietf-ldapext@netscape.com>. Please send editorial
20 comments directly to the author <Kurt@OpenLDAP.org>.
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 2000, The Internet Society. All Rights Reserved.
36 Please see the Copyright section near the end of this document for
42 X.500 provides a mechanism for clients to request all operational
43 attributes be returned with entries provided in response to a search
44 operation. LDAP [RFC2251] does not provide a similar mechanism to
45 clients to request the return of operational attributes. The lack of
46 such a mechanisms hinders discovery of operational attributes present
54 INTERNET-DRAFT draft-zeilenga-ldapv3bis-opattrs-00 13 June 2000
57 This document defines a simple mechanism which clients may use to
58 request all operation attributes. This document updates RFC 2251 as
61 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
62 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
63 this document are to be interpreted as described in RFC 2119
67 3. Changes to RFC 2251
69 This document updates RFC 2251 as follows:
71 In Section 3.2.1, Attributes of Entries, the paragraph:
72 Some attributes, termed operational attributes, are used by
73 servers for administering the directory system itself. They are
74 not returned in search results unless explicitly requested by
75 name. Attributes which are not operational, such as "mail", will
76 have their schema and syntax constraints enforced by servers, but
77 servers will generally not make use of their values.
80 Some attributes, termed operational attributes, are used by
81 servers for administering the directory system itself. They are
82 not returned in search results unless explicitly requested.
83 Attributes which are not operational, such as "mail", will have
84 their schema and syntax constraints enforced by servers, but
85 servers will generally not make use of their values.
87 In Section 4.5.1, Search Request, the paragraph:
88 - attributes: A list of the attributes to be returned from each
89 entry which matches the search filter. There are two special
90 values which may be used: an empty list with no attributes, and
91 the attribute description string "*". Both of these signify that
92 all user attributes are to be returned. (The "*" allows the
93 client to request all user attributes in addition to specific
94 operational attributes).
97 - attributes: A list of the attributes to be returned from each
98 entry which matches the search filter. There are three special
99 values which may be used. An empty list with no attributes
100 signifies that all user attributes are to be returned. An
101 attribute list containing the attribute description string "*"
102 signifies that all user attributes are to be returned. An
103 attribute list containing the attribute description string "+"
104 signifies that all operational attributes are to be returned.
110 INTERNET-DRAFT draft-zeilenga-ldapv3bis-opattrs-00 13 June 2000
113 (The "*" allows the client to request all user attributes in
114 addition to any requested operational attributes. The "+" allows
115 the client to request all operational attributes in addition to
116 requested user attributes. A client may list both "*" and "+" to
117 request all attributes.)
120 Client implementors should note that even if all user attributes
121 are requested, some attributes of the entry may not be included in
122 search results due to access control or other restrictions.
123 Furthermore, servers will not return operational attributes, such
124 as objectClasses or attributeTypes, unless they are listed by
125 name, since there may be extremely large number of values for
126 certain operational attributes. (A list of operational attributes
127 for use in LDAP is given in [5].)
130 Client implementors should note that results may not include all
131 requested attributes due to access controls or other restrictions.
132 In addition, client implementors should request types only be
133 returned when discovering operational attributes as certain
134 operational attributes may have extremely large number of values.
135 Furthermore, servers will not return operational attributes, such
136 as objectClasses or attributeTypes, unless they are requested,
137 since there may be extremely large number of values for certain
138 operational attributes. (A list of operational attributes for use
139 in LDAP is given in [5].)
142 5. Interoperability Considerations
144 The addition of this mechanism to LDAPv3 is not believed to cause
145 significant interoperability problems. A server which does not
146 support the "+" should ignore the attribute description per RFC 2251,
147 section 4.5.1 and only return the attributes for the attribute
148 descriptions strings they do recognize. From the client's
149 perspective, this is one possible "other restriction" noted above.
152 5. Security Considerations
154 This document provides a mechanism which clients may use to discover
155 operational attributes. Access controls should be used to restrict
156 access to operational attributes per local policy.
166 INTERNET-DRAFT draft-zeilenga-ldapv3bis-opattrs-00 13 June 2000
169 Copyright 2000, The Internet Society. All Rights Reserved.
171 This document and translations of it may be copied and furnished to
172 others, and derivative works that comment on or otherwise explain it
173 or assist in its implementation may be prepared, copied, published and
174 distributed, in whole or in part, without restriction of any kind,
175 provided that the above copyright notice and this paragraph are
176 included on all such copies and derivative works. However, this
177 document itself may not be modified in any way, such as by removing
178 the copyright notice or references to the Internet Society or other
179 Internet organizations, except as needed for the purpose of
180 developing Internet standards in which case the procedures for
181 copyrights defined in the Internet Standards process must be followed,
182 or as required to translate it into languages other than English.
184 The limited permissions granted above are perpetual and will not be
185 revoked by the Internet Society or its successors or assigns.
187 This document and the information contained herein is provided on an
188 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
189 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
190 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
191 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
192 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
196 [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
197 Requirement Levels", RFC 2119, March 1997.
199 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight
200 Directory Access Protocol (v3)", RFC 2251,
203 [X.500] ITU-T Rec. X.500, "The Directory: Overview of
204 Concepts, Models and Service", 1993.