]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3673.txt
Fix prev commit
[openldap] / doc / rfc / rfc3673.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 3673                           OpenLDAP Foundation
9 Category: Standards Track                                  December 2003
10
11
12        Lightweight Directory Access Protocol version 3 (LDAPv3):
13                        All Operational Attributes
14
15 Status of this Memo
16
17    This document specifies an Internet standards track protocol for the
18    Internet community, and requests discussion and suggestions for
19    improvements.  Please refer to the current edition of the "Internet
20    Official Protocol Standards" (STD 1) for the standardization state
21    and status of this protocol.  Distribution of this memo is unlimited.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2003).  All Rights Reserved.
26
27 Abstract
28
29    The Lightweight Directory Access Protocol (LDAP) supports a mechanism
30    for requesting the return of all user attributes but not all
31    operational attributes.  This document describes an LDAP extension
32    which clients may use to request the return of all operational
33    attributes.
34
35 1.  Overview
36
37    X.500 [X.500] provides a mechanism for clients to request all
38    operational attributes be returned with entries provided in response
39    to a search operation.  This mechanism is often used by clients to
40    discover which operational attributes are present in an entry.
41
42    This documents extends the Lightweight Directory Access Protocol
43    (LDAP) [RFC3377] to provide a simple mechanism which clients may use
44    to request the return of all operational attributes.  The mechanism
45    is designed for use with existing general purpose LDAP clients
46    (including web browsers which support LDAP URLs) and existing LDAP
47    APIs.
48
49    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
50    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
51    document are to be interpreted as described in BCP 14 [RFC2119].
52
53
54
55
56
57
58 Zeilenga                    Standards Track                     [Page 1]
59 \f
60 RFC 3673           LDAPv3: All Operational Attributes      December 2003
61
62
63 2.  All Operational Attributes
64
65    The presence of the attribute description "+" (ASCII 43) in the list
66    of attributes in a Search Request [RFC2251] SHALL signify a request
67    for the return of all operational attributes.
68
69    As with all search requests, client implementors should note that
70    results may not include all requested attributes due to access
71    controls or other restrictions.  Client implementors should also note
72    that certain operational attributes may be returned only if requested
73    by name even when "+" is present.  This is because some operational
74    attributes are very expensive to return.
75
76    Servers supporting this feature SHOULD publish the Object Identifier
77    1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
78    [RFC3674] attribute in the root DSE.
79
80 3.  Interoperability Considerations
81
82    This mechanism is specifically designed to allow users to request all
83    operational attributes using existing LDAP clients.  In particular,
84    the mechanism is designed to be compatible with existing general
85    purpose LDAP clients including those supporting LDAP URLs [RFC2255].
86
87    The addition of this mechanism to LDAP is not believed to cause any
88    significant interoperability issues (this has been confirmed through
89    testing).  Servers which have yet to implement this specification
90    should ignore the "+" as an unrecognized attribute description per
91    [RFC2251, Section 4.5.1].  From the client's perspective, a server
92    which does not return all operational attributes when "+" is
93    requested should be viewed as having other restrictions.
94
95    It is also noted that this mechanism is believed to require no
96    modification of existing LDAP APIs.
97
98 4.  Security Considerations
99
100    This document provides a general mechanism which clients may use to
101    discover operational attributes.  Prior to the introduction of this
102    mechanism, operational attributes were only returned when requested
103    by name.  Some might have viewed this as obscurity feature.  However,
104    this feature offers a false sense of security as the attributes were
105    still transferable.
106
107    Implementations SHOULD implement appropriate access controls
108    mechanisms to restricts access to operational attributes.
109
110
111
112
113
114 Zeilenga                    Standards Track                     [Page 2]
115 \f
116 RFC 3673           LDAPv3: All Operational Attributes      December 2003
117
118
119 5.  IANA Considerations
120
121    This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
122    feature described above.  This OID was assigned [ASSIGN] by OpenLDAP
123    Foundation, under its IANA-assigned private enterprise allocation
124    [PRIVATE], for use in this specification.
125
126    Registration of this feature has been completed by IANA [RFC3674],
127    [RFC3383].
128
129    Subject: Request for LDAP Protocol Mechanism Registration
130
131    Object Identifier: 1.3.6.1.4.1.4203.1.5.1
132
133    Description: All Op Attrs
134
135    Person & email address to contact for further information:
136         Kurt Zeilenga <kurt@openldap.org>
137
138    Usage: Feature
139
140    Specification: RFC3673
141
142    Author/Change Controller: IESG
143
144    Comments: none
145
146 6.  Acknowledgment
147
148    The "+" mechanism is believed to have been first suggested by Bruce
149    Greenblatt in a November 1998 post to the IETF LDAPext Working Group
150    mailing list.
151
152 7.  Intellectual Property Statement
153
154    The IETF takes no position regarding the validity or scope of any
155    intellectual property or other rights that might be claimed to
156    pertain to the implementation or use of the technology described in
157    this document or the extent to which any license under such rights
158    might or might not be available; neither does it represent that it
159    has made any effort to identify any such rights.  Information on the
160    IETF's procedures with respect to rights in standards-track and
161    standards-related documentation can be found in BCP-11.  Copies of
162    claims of rights made available for publication and any assurances of
163    licenses to be made available, or the result of an attempt made to
164    obtain a general license or permission for the use of such
165    proprietary rights by implementors or users of this specification can
166    be obtained from the IETF Secretariat.
167
168
169
170 Zeilenga                    Standards Track                     [Page 3]
171 \f
172 RFC 3673           LDAPv3: All Operational Attributes      December 2003
173
174
175    The IETF invites any interested party to bring to its attention any
176    copyrights, patents or patent applications, or other proprietary
177    rights which may cover technology that may be required to practice
178    this standard.  Please address the information to the IETF Executive
179    Director.
180
181 8.  References
182
183 8.1.  Normative References
184
185    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
186               Requirement Levels", BCP 14, RFC 2119, March 1997.
187
188    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
189               Access Protocol (v3)", RFC 2251, December 1997.
190
191    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
192               Protocol (v3): Technical Specification", RFC 3377,
193               September 2002.
194
195    [RFC3674]  Zeilenga, K., "Feature Discovery in Lightweight Directory
196               Access Protocol (LDAP)", RFC 3674, December 2003.
197
198 8.2.  Informative References
199
200    [RFC2255]  Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
201               December 1997.
202
203    [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
204               Considerations for the Lightweight Directory Access
205               Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
206
207    [X.500]    ITU-T Rec.  X.500, "The Directory: Overview of Concepts,
208               Models and Service", 1993.
209
210    [ASSIGN]   OpenLDAP Foundation, "OpenLDAP OID Delegations",
211               http://www.openldap.org/foundation/oid-delegate.txt.
212
213    [PRIVATE]  IANA, "Private Enterprise Numbers",
214               http://www.iana.org/assignments/enterprise-numbers.
215
216 9.  Author's Address
217
218    Kurt D. Zeilenga
219    OpenLDAP Foundation
220
221    EMail: Kurt@OpenLDAP.org
222
223
224
225
226 Zeilenga                    Standards Track                     [Page 4]
227 \f
228 RFC 3673           LDAPv3: All Operational Attributes      December 2003
229
230
231 10.  Full Copyright Statement
232
233    Copyright (C) The Internet Society (2003).  All Rights Reserved.
234
235    This document and translations of it may be copied and furnished to
236    others, and derivative works that comment on or otherwise explain it
237    or assist in its implementation may be prepared, copied, published
238    and distributed, in whole or in part, without restriction of any
239    kind, provided that the above copyright notice and this paragraph are
240    included on all such copies and derivative works.  However, this
241    document itself may not be modified in any way, such as by removing
242    the copyright notice or references to the Internet Society or other
243    Internet organizations, except as needed for the purpose of
244    developing Internet standards in which case the procedures for
245    copyrights defined in the Internet Standards process must be
246    followed, or as required to translate it into languages other than
247    English.
248
249    The limited permissions granted above are perpetual and will not be
250    revoked by the Internet Society or its successors or assignees.
251
252    This document and the information contained herein is provided on an
253    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
254    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
255    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
256    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
257    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
258
259 Acknowledgement
260
261    Funding for the RFC Editor function is currently provided by the
262    Internet Society.
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Zeilenga                    Standards Track                     [Page 5]
283 \f