git.sur5r.net Git - openldap/blob - doc/rfc/rfc5020.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        K. Zeilenga
   8 Request for Comments: 5020                                 Isode Limited
   9 Category: Standards Track                                    August 2007
  10
  11
  12        The Lightweight Directory Access Protocol (LDAP) entryDN
  13                          Operational Attribute
  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 IETF Trust (2007).
  26
  27 Abstract
  28
  29    This document describes the Lightweight Directory Access Protocol
  30    (LDAP) / X.500 'entryDN' operational attribute.  The attribute
  31    provides a copy of the entry's distinguished name for use in
  32    attribute value assertions.
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Zeilenga                    Standards Track                     [Page 1]
  59 \f
  60 RFC 5020                      LDAP entryDN                   August 2007
  61
  62
  63 1.  Background and Intended Use
  64
  65    In X.500 Directory Services [X.501], such as those accessible using
  66    the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry
  67    is identified by its distinguished name (DN) [RFC4512].  However, as
  68    an entry's DN is not an attribute of the entry, it is not possible to
  69    perform attribute value assertions [RFC4511] against it.
  70
  71    This document describes the 'entryDN' operational attribute which
  72    holds a copy of the entry's distinguished name.  This attribute may
  73    be used in search filters.  For instance, searching the subtree
  74    <dc=example,dc=com> with the filter:
  75
  76       (entryDN:componentFilterMatch:=or:{
  77           item:{ component "3", rule rdnMatch, value "ou=A" },
  78           item:{ component "3", rule rdnMatch, value "ou=B" } })
  79
  80    would return entries in the subtree <ou=A,dc=example,dc=com> and
  81    entries in subtree <ou=B,dc=example,dc=com>, but would not return any
  82    other entries in the subtree <dc=example,dc=com>.
  83
  84    In the above paragraph, DNs are presented using the string
  85    representation defined in [RFC4514], and the example search filter is
  86    presented using the string representation defined in [RFC4515] with
  87    whitespace (line breaks and indentation) added to improve
  88    readability.  The 'componentFilterMatch' and 'rdnMatch' rules are
  89    specified in [RFC3687].
  90
  91    Schema definitions are provided using LDAP description formats
  92    [RFC4512].  Definitions provided here are formatted (line wrapped)
  93    for readability.
  94
  95 2.  'entryDN' Operational Attribute
  96
  97    The 'entryDN' operational attribute provides a copy of the entry's
  98    current DN.
  99
 100    The following is an LDAP attribute type description suitable for
 101    publication in subschema subentries.
 102
 103       ( 1.3.6.1.1.20 NAME 'entryDN'
 104           DESC 'DN of the entry'
 105           EQUALITY distinguishedNameMatch
 106           SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
 107           SINGLE-VALUE
 108           NO-USER-MODIFICATION
 109           USAGE directoryOperation )
 110
 111
 112
 113
 114 Zeilenga                    Standards Track                     [Page 2]
 115 \f
 116 RFC 5020                      LDAP entryDN                   August 2007
 117
 118
 119    Note that the DN of the entry cannot be modified through this
 120    attribute.
 121
 122 3.  Security Considerations
 123
 124    As this attribute only provides an additional mechanism to access an
 125    entry's DN, the introduction of this attribute is not believed to
 126    introduce new security considerations.
 127
 128 4.  IANA Considerations
 129
 130 4.1.  Object Identifier Registration
 131
 132    IANA has registered (upon Standards Action) an LDAP Object Identifier
 133    [RFC4520] for use in this document.
 134
 135       Subject: Request for LDAP OID Registration
 136       Person & email address to contact for further information:
 137           Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
 138       Specification: RFC 5020
 139       Author/Change Controller: IESG
 140       Comments:
 141           Identifies the 'entryDN' attribute type
 142
 143 4.2.  'entryDN' Descriptor Registration
 144
 145    IANA has registered (upon Standards Action) the LDAP 'entryDN'
 146    descriptor [RFC4520].
 147
 148       Subject: Request for LDAP Descriptor Registration
 149       Descriptor (short name): entryDN
 150       Object Identifier: 1.3.6.1.1.20
 151       Person & email address to contact for further information:
 152           Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
 153       Usage: Attribute Type
 154       Specification: RFC 5020
 155       Author/Change Controller: IESG
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Zeilenga                    Standards Track                     [Page 3]
 171 \f
 172 RFC 5020                      LDAP entryDN                   August 2007
 173
 174
 175 5.  References
 176
 177 5.1.  Normative References
 178
 179    [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
 180                (LDAP): Technical Specification Road Map", RFC 4510, June
 181                2006.
 182
 183    [RFC4512]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
 184                (LDAP): Directory Information Models", RFC 4512, June
 185                2006.
 186
 187    [X.501]     International Telecommunication Union - Telecommunication
 188                Standardization Sector, "The Directory -- Models,"
 189                X.501(1993) (also ISO/IEC 9594-2:1994).
 190
 191 5.2.  Informative References
 192
 193    [RFC3687]   Legg, S., "Lightweight Directory Access Protocol (LDAP)
 194                and X.500 Component Matching Rules", RFC 3687, February
 195                2004.
 196
 197    [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
 198                Protocol (LDAP): The Protocol", RFC 4511, June 2006.
 199
 200    [RFC4514]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
 201                (LDAP): String Representation of Distinguished Names",
 202                RFC 4514, June 2006.
 203
 204    [RFC4515]   Smith, M., Ed., and T. Howes, "Lightweight Directory
 205                Access Protocol (LDAP): String Representation of Search
 206                Filters", RFC 4515, June 2006.
 207
 208    [RFC4520]   Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
 209                Considerations for the Lightweight Directory Access
 210                Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
 211
 212 Author's Address
 213
 214    Kurt D. Zeilenga
 215    Isode Limited
 216
 217    EMail: Kurt.Zeilenga@Isode.COM
 218
 219
 220
 221
 222
 223
 224
 225
 226 Zeilenga                    Standards Track                     [Page 4]
 227 \f
 228 RFC 5020                      LDAP entryDN                   August 2007
 229
 230
 231 Full Copyright Statement
 232
 233    Copyright (C) The IETF Trust (2007).
 234
 235    This document is subject to the rights, licenses and restrictions
 236    contained in BCP 78, and except as set forth therein, the authors
 237    retain all their rights.
 238
 239    This document and the information contained herein are provided on an
 240    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 241    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 242    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 243    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 244    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 245    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 246
 247 Intellectual Property
 248
 249    The IETF takes no position regarding the validity or scope of any
 250    Intellectual Property Rights or other rights that might be claimed to
 251    pertain to the implementation or use of the technology described in
 252    this document or the extent to which any license under such rights
 253    might or might not be available; nor does it represent that it has
 254    made any independent effort to identify any such rights.  Information
 255    on the procedures with respect to rights in RFC documents can be
 256    found in BCP 78 and BCP 79.
 257
 258    Copies of IPR disclosures made to the IETF Secretariat and any
 259    assurances of licenses to be made available, or the result of an
 260    attempt made to obtain a general license or permission for the use of
 261    such proprietary rights by implementers or users of this
 262    specification can be obtained from the IETF on-line IPR repository at
 263    http://www.ietf.org/ipr.
 264
 265    The IETF invites any interested party to bring to its attention any
 266    copyrights, patents or patent applications, or other proprietary
 267    rights that may cover technology that may be required to implement
 268    this standard.  Please address the information to the IETF at
 269    ietf-ipr@ietf.org.
 270
 271 Acknowledgement
 272
 273    Funding for the RFC Editor function is currently provided by the
 274    Internet Society.
 275
 276
 277
 278
 279
 280
 281
 282 Zeilenga                    Standards Track                     [Page 5]
 283 \f