home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / ldapsdk.zip / doc / drafts / draft-zeilenga-ldapv3bis-opattrs-xx.txt < prev    next >
Text File  |  2000-07-29  |  9KB  |  222 lines
  1. INTERNET-DRAFT                                      Kurt D. Zeilenga
  2. Intended Category: Standard Track                   OpenLDAP Foundation
  3. Expires: 29 December 2000                           29 June 2000
  4.  
  5.  
  6.                     LDAPv3: All Operational Attributes
  7.                 <draft-zeilenga-ldapv3bis-opattrs-00.txt>
  8.  
  9.  
  10. 1.      Status of this Memo
  11.  
  12.   This document is an Internet-Draft and is in full conformance with all
  13.   provisions of Section 10 of RFC2026.
  14.  
  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>.
  21.  
  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.''
  29.  
  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.
  33.  
  34.   Copyright 2000, The Internet Society.  All Rights Reserved.
  35.  
  36.   Please see the Copyright section near the end of this document for
  37.   more information.
  38.  
  39.  
  40. 2.      Overview
  41.  
  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
  47.   in an entry.
  48.  
  49.  
  50.  
  51.  
  52. Zeilenga                                                        [Page 1]
  53.  
  54. INTERNET-DRAFT     draft-zeilenga-ldapv3bis-opattrs-00      13 June 2000
  55.  
  56.  
  57.   This document defines a simple mechanism which clients may use to
  58.   request all operation attributes.  This document updates RFC 2251 as
  59.   detailed below.
  60.  
  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
  64.   [RFC2119].
  65.  
  66.  
  67. 3.      Changes to RFC 2251
  68.  
  69.   This document updates RFC 2251 as follows:
  70.  
  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.
  78.  
  79.   is replaced with:
  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.
  86.  
  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).
  95.  
  96.   is replaced with:
  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.
  105.  
  106.  
  107.  
  108. Zeilenga                                                        [Page 2]
  109.  
  110. INTERNET-DRAFT     draft-zeilenga-ldapv3bis-opattrs-00      13 June 2000
  111.  
  112.  
  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.)
  118.  
  119.   and the paragraph:
  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].)
  128.  
  129.   is replaced with:
  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].)
  140.  
  141.  
  142. 5.      Interoperability Considerations
  143.  
  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.
  150.  
  151.  
  152. 5.      Security Considerations
  153.  
  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.
  157.  
  158.  
  159. 6.      Copyright
  160.  
  161.  
  162.  
  163.  
  164. Zeilenga                                                        [Page 3]
  165.  
  166. INTERNET-DRAFT     draft-zeilenga-ldapv3bis-opattrs-00      13 June 2000
  167.  
  168.  
  169.   Copyright 2000, The Internet Society.  All Rights Reserved.
  170.  
  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.
  183.  
  184.   The limited permissions granted above are perpetual and will not be
  185.   revoked by the Internet Society or its successors or assigns.
  186.  
  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.
  193.  
  194. 7.      Bibliography
  195.  
  196.   [RFC2219]       S. Bradner, "Key words for use in RFCs to Indicate
  197.                   Requirement Levels", RFC 2119, March 1997.
  198.  
  199.   [RFC2251]       M. Wahl, T. Howes, S. Kille, "Lightweight
  200.                   Directory Access Protocol (v3)", RFC 2251,
  201.                   December 1997.
  202.  
  203.   [X.500]         ITU-T Rec. X.500, "The Directory: Overview of
  204.                   Concepts, Models and Service",  1993.
  205.  
  206.  
  207. 8.     Author's Address
  208.  
  209.   Kurt D. Zeilenga
  210.   OpenLDAP Foundation
  211.   <Kurt@OpenLDAP.org>
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. Zeilenga                                                        [Page 4]
  221.  
  222.