git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                      Kurt D. Zeilenga
   8 Intended Category: Standard Track                   OpenLDAP Foundation
   9 Expires in six months                               17 May 2002
  10
  11
  12
  13                     LDAPv3: All Operational Attributes
  14                    <draft-zeilenga-ldap-opattrs-03.txt>
  15
  16
  17 Status of this Memo
  18
  19   This document is an Internet-Draft and is in full conformance with all
  20   provisions of Section 10 of RFC2026.
  21
  22   This document is intended to be, after appropriate review and
  23   revision, submitted to the RFC Editor as a Standard Track document.
  24   Distribution of this memo is unlimited.  Technical discussion of this
  25   document will take place on the IETF LDAP Extensions Working Group
  26   mailing list <ietf-ldapext@netscape.com>.  Please send editorial
  27   comments directly to the author <Kurt@OpenLDAP.org>.
  28
  29   Internet-Drafts are working documents of the Internet Engineering Task
  30   Force (IETF), its areas, and its working groups.  Note that other
  31   groups may also distribute working documents as Internet-Drafts.
  32   Internet-Drafts are draft documents valid for a maximum of six months
  33   and may be updated, replaced, or obsoleted by other documents at any
  34   time.  It is inappropriate to use Internet-Drafts as reference
  35   material or to cite them other than as ``work in progress.''
  36
  37   The list of current Internet-Drafts can be accessed at
  38   <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
  39   Internet-Draft Shadow Directories can be accessed at
  40   <http://www.ietf.org/shadow.html>.
  41
  42   Copyright 2002, The Internet Society.  All Rights Reserved.
  43
  44   Please see the Copyright section near the end of this document for
  45   more information.
  46
  47
  48 Abstract
  49
  50   The Lightweight Directory Access Protocol (LDAP) supports a mechanism
  51   for requesting the return of all user attributes but does not all
  52   operational attributes.   This document describes an LDAP extension
  53   which clients may use to request the return of all operational
  54   attributes.
  55
  56
  57
  58 Zeilenga                    LDAP All Op Attrs                   [Page 1]
  59 \f
  60 INTERNET-DRAFT       draft-zeilenga-ldap-opattrs-03          17 May 2002
  61
  62
  63 1.  Overview
  64
  65   X.500 [X.500] provides a mechanism for clients to request all
  66   operational attributes be returned with entries provided in response
  67   to a search operation.   This mechanism is often used by clients to
  68   discover which operational attributes are present in an entry.
  69
  70   This documents extends LDAP [RFC2251] to provide a simple mechanism
  71   which clients may use to request the return of all operation
  72   attributes.  The mechanism is designed for use with existing general
  73   purpose LDAP clients (including web browsers which support LDAP URLs)
  74   and existing LDAP API.
  75
  76   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  77   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  78   document are to be interpreted as described in BCP 14 [RFC2119].
  79
  80
  81 2.  All Operational Attributes
  82
  83   The presence of the attribute description "+" (ASCII 43) in the list
  84   of attributes in a Search Request SHALL signify a request for the
  85   return of all operational attributes.
  86
  87   As with all search requests, client implementors should note that
  88   results may not include all requested attributes due to access
  89   controls or other restrictions.  Clients implementors should also note
  90   that certain operational attributes may be returned only if requested
  91   by name even when "+" is present.  This is because some operational
  92   attributes are very expensive to return.
  93
  94   Servers supporting this feature SHOULD publish the Object Identifier
  95   1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
  96   attribute in the root DSE.
  97
  98
  99 3.  Interoperability Considerations
 100
 101   This mechanism is specifically designed to allow users to request all
 102   operational attributes using existing LDAP clients.  In particular,
 103   the mechanism is designed to be compatible with existing general
 104   purpose LDAP clients includes web browsers which support LDAP URLs
 105   [RFC2255].
 106
 107   The addition of this mechanism to LDAPv3 is believed not to cause any
 108   significant interoperability issues (this has been confirmed through
 109   testing).   Servers which have yet to implement this specification
 110   should ignore the "+" as an unrecognized attribute description per
 111
 112
 113
 114 Zeilenga                    LDAP All Op Attrs                   [Page 2]
 115 \f
 116 INTERNET-DRAFT       draft-zeilenga-ldap-opattrs-03          17 May 2002
 117
 118
 119   [RFC2251, Section 4.5.1].  From the client's perspective, a server
 120   which does not return all operational attributes when "+" is requested
 121   should be viewed as having other restrictions.
 122
 123   It is also noted that this mechanism is believed to require no
 124   modification of existing LDAP APIs.
 125
 126
 127 4.  Security Considerations
 128
 129   This document provides a mechanism which clients may use to discover
 130   operational attributes.  Those relying on security by obscurity SHOULD
 131   implement appropriate access controls to restricts access to
 132   operational attributes per local policy.
 133
 134
 135 5.  IANA Considerations
 136
 137   No IANA assignments are requested.
 138
 139   This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
 140   feature described above.  This OID was assigned [ASSIGN] by OpenLDAP
 141   Foundation under its IANA assigned private enterprise allocation
 142   [PRIVATE] for use in this specification.
 143
 144
 145 6.  Acknowledgment
 146
 147   The "+" mechanism is believed to have been first suggested by Bruce
 148   Greenblatt in a November 1998 post to the IETF LDAPext Working Group
 149   mailing list.
 150
 151
 152 7.  Author's Address
 153
 154   Kurt D. Zeilenga
 155   OpenLDAP Foundation
 156   <Kurt@OpenLDAP.org>
 157
 158
 159 8. Normative References
 160
 161   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
 162             Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 163
 164   [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
 165             Protocol (v3)", RFC 2251, December 1997.
 166
 167
 168
 169
 170 Zeilenga                    LDAP All Op Attrs                   [Page 3]
 171 \f
 172 INTERNET-DRAFT       draft-zeilenga-ldap-opattrs-03          17 May 2002
 173
 174
 175   [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
 176             ldap-features-xx.txt (a work in progress).
 177
 178
 179 9. Informative References
 180
 181   [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
 182             December 1997.
 183
 184   [X.500]   ITU-T Rec. X.500, "The Directory: Overview of Concepts,
 185             Models and Service", 1993.
 186
 187   [ASSIGN]  OpenLDAP Foundation, "OpenLDAP OID Delegations",
 188             http://www.openldap.org/foundation/oid-delegate.txt.
 189
 190   [PRIVATE] IANA, "Private Enterprise Numbers",
 191             http://www.iana.org/assignments/enterprise-numbers.
 192
 193
 194 Copyright 2002, The Internet Society.  All Rights Reserved.
 195
 196   This document and translations of it may be copied and furnished to
 197   others, and derivative works that comment on or otherwise explain it
 198   or assist in its implementation may be prepared, copied, published and
 199   distributed, in whole or in part, without restriction of any kind,
 200   provided that the above copyright notice and this paragraph are
 201   included on all such copies and derivative works.  However, this
 202   document itself may not be modified in any way, such as by removing
 203   the copyright notice or references to the Internet Society or other
 204   Internet organizations, except as needed for the  purpose of
 205   developing Internet standards in which case the procedures for
 206   copyrights defined in the Internet Standards process must be followed,
 207   or as required to translate it into languages other than English.
 208
 209   The limited permissions granted above are perpetual and will not be
 210   revoked by the Internet Society or its successors or assigns.
 211
 212   This document and the information contained herein is provided on an
 213   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
 214   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 215   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 216   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 217   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 218
 219
 220
 221
 222
 223
 224
 225
 226 Zeilenga                    LDAP All Op Attrs                   [Page 4]
 227 \f