From: Kurt Zeilenga Date: Fri, 7 Jul 2000 19:46:20 +0000 (+0000) Subject: Initial '+' draft X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~2463 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=8991c613b2f48736bba761f547c644b699972688;p=openldap Initial '+' draft --- diff --git a/doc/drafts/draft-zeilenga-ldapv3bis-opattrs-xx.txt b/doc/drafts/draft-zeilenga-ldapv3bis-opattrs-xx.txt new file mode 100644 index 0000000000..0daa771166 --- /dev/null +++ b/doc/drafts/draft-zeilenga-ldapv3bis-opattrs-xx.txt @@ -0,0 +1,221 @@ +INTERNET-DRAFT Kurt D. Zeilenga +Intended Category: Standard Track OpenLDAP Foundation +Expires: 29 December 2000 29 June 2000 + + + LDAPv3: All Operational Attributes + + + +1. Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + This document is intended to be, after appropriate review and + revision, submitted to the RFC Editor as a Standard Track document. + Distribution of this memo is unlimited. Technical discussion of this + document will take place on the IETF LDAP Extension Working Group + mailing list . Please send editorial + comments directly to the author . + + Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft + Shadow Directories can be accessed at http://www.ietf.org/shadow.html. + + Copyright 2000, The Internet Society. All Rights Reserved. + + Please see the Copyright section near the end of this document for + more information. + + +2. Overview + + X.500 provides a mechanism for clients to request all operational + attributes be returned with entries provided in response to a search + operation. LDAP [RFC2251] does not provide a similar mechanism to + clients to request the return of operational attributes. The lack of + such a mechanisms hinders discovery of operational attributes present + in an entry. + + + + +Zeilenga [Page 1] + +INTERNET-DRAFT draft-zeilenga-ldapv3bis-opattrs-00 13 June 2000 + + + This document defines a simple mechanism which clients may use to + request all operation attributes. This document updates RFC 2251 as + detailed below. + + The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL + NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in + this document are to be interpreted as described in RFC 2119 + [RFC2119]. + + +3. Changes to RFC 2251 + + This document updates RFC 2251 as follows: + + In Section 3.2.1, Attributes of Entries, the paragraph: + Some attributes, termed operational attributes, are used by + servers for administering the directory system itself. They are + not returned in search results unless explicitly requested by + name. Attributes which are not operational, such as "mail", will + have their schema and syntax constraints enforced by servers, but + servers will generally not make use of their values. + + is replaced with: + Some attributes, termed operational attributes, are used by + servers for administering the directory system itself. They are + not returned in search results unless explicitly requested. + Attributes which are not operational, such as "mail", will have + their schema and syntax constraints enforced by servers, but + servers will generally not make use of their values. + + In Section 4.5.1, Search Request, the paragraph: + - attributes: A list of the attributes to be returned from each + entry which matches the search filter. There are two special + values which may be used: an empty list with no attributes, and + the attribute description string "*". Both of these signify that + all user attributes are to be returned. (The "*" allows the + client to request all user attributes in addition to specific + operational attributes). + + is replaced with: + - attributes: A list of the attributes to be returned from each + entry which matches the search filter. There are three special + values which may be used. An empty list with no attributes + signifies that all user attributes are to be returned. An + attribute list containing the attribute description string "*" + signifies that all user attributes are to be returned. An + attribute list containing the attribute description string "+" + signifies that all operational attributes are to be returned. + + + +Zeilenga [Page 2] + +INTERNET-DRAFT draft-zeilenga-ldapv3bis-opattrs-00 13 June 2000 + + + (The "*" allows the client to request all user attributes in + addition to any requested operational attributes. The "+" allows + the client to request all operational attributes in addition to + requested user attributes. A client may list both "*" and "+" to + request all attributes.) + + and the paragraph: + Client implementors should note that even if all user attributes + are requested, some attributes of the entry may not be included in + search results due to access control or other restrictions. + Furthermore, servers will not return operational attributes, such + as objectClasses or attributeTypes, unless they are listed by + name, since there may be extremely large number of values for + certain operational attributes. (A list of operational attributes + for use in LDAP is given in [5].) + + is replaced with: + Client implementors should note that results may not include all + requested attributes due to access controls or other restrictions. + In addition, client implementors should request types only be + returned when discovering operational attributes as certain + operational attributes may have extremely large number of values. + Furthermore, servers will not return operational attributes, such + as objectClasses or attributeTypes, unless they are requested, + since there may be extremely large number of values for certain + operational attributes. (A list of operational attributes for use + in LDAP is given in [5].) + + +5. Interoperability Considerations + + The addition of this mechanism to LDAPv3 is not believed to cause + significant interoperability problems. A server which does not + support the "+" should ignore the attribute description per RFC 2251, + section 4.5.1 and only return the attributes for the attribute + descriptions strings they do recognize. From the client's + perspective, this is one possible "other restriction" noted above. + + +5. Security Considerations + + This document provides a mechanism which clients may use to discover + operational attributes. Access controls should be used to restrict + access to operational attributes per local policy. + + +6. Copyright + + + + +Zeilenga [Page 3] + +INTERNET-DRAFT draft-zeilenga-ldapv3bis-opattrs-00 13 June 2000 + + + Copyright 2000, The Internet Society. All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be followed, + or as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +7. Bibliography + + [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight + Directory Access Protocol (v3)", RFC 2251, + December 1997. + + [X.500] ITU-T Rec. X.500, "The Directory: Overview of + Concepts, Models and Service", 1993. + + +8. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + + + + + + + + +Zeilenga [Page 4] +