summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5020.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5020.txt')
-rw-r--r--doc/rfc/rfc5020.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc5020.txt b/doc/rfc/rfc5020.txt
new file mode 100644
index 0000000..e289f8b
--- /dev/null
+++ b/doc/rfc/rfc5020.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 5020 Isode Limited
+Category: Standards Track August 2007
+
+
+ The Lightweight Directory Access Protocol (LDAP) entryDN
+ Operational Attribute
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document describes the Lightweight Directory Access Protocol
+ (LDAP) / X.500 'entryDN' operational attribute. The attribute
+ provides a copy of the entry's distinguished name for use in
+ attribute value assertions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 5020 LDAP entryDN August 2007
+
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], such as those accessible using
+ the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry
+ is identified by its distinguished name (DN) [RFC4512]. However, as
+ an entry's DN is not an attribute of the entry, it is not possible to
+ perform attribute value assertions [RFC4511] against it.
+
+ This document describes the 'entryDN' operational attribute which
+ holds a copy of the entry's distinguished name. This attribute may
+ be used in search filters. For instance, searching the subtree
+ <dc=example,dc=com> with the filter:
+
+ (entryDN:componentFilterMatch:=or:{
+ item:{ component "3", rule rdnMatch, value "ou=A" },
+ item:{ component "3", rule rdnMatch, value "ou=B" } })
+
+ would return entries in the subtree <ou=A,dc=example,dc=com> and
+ entries in subtree <ou=B,dc=example,dc=com>, but would not return any
+ other entries in the subtree <dc=example,dc=com>.
+
+ In the above paragraph, DNs are presented using the string
+ representation defined in [RFC4514], and the example search filter is
+ presented using the string representation defined in [RFC4515] with
+ whitespace (line breaks and indentation) added to improve
+ readability. The 'componentFilterMatch' and 'rdnMatch' rules are
+ specified in [RFC3687].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. 'entryDN' Operational Attribute
+
+ The 'entryDN' operational attribute provides a copy of the entry's
+ current DN.
+
+ The following is an LDAP attribute type description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.20 NAME 'entryDN'
+ DESC 'DN of the entry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 5020 LDAP entryDN August 2007
+
+
+ Note that the DN of the entry cannot be modified through this
+ attribute.
+
+3. Security Considerations
+
+ As this attribute only provides an additional mechanism to access an
+ entry's DN, the introduction of this attribute is not believed to
+ introduce new security considerations.
+
+4. IANA Considerations
+
+4.1. Object Identifier Registration
+
+ IANA has registered (upon Standards Action) an LDAP Object Identifier
+ [RFC4520] for use in this document.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Specification: RFC 5020
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the 'entryDN' attribute type
+
+4.2. 'entryDN' Descriptor Registration
+
+ IANA has registered (upon Standards Action) the LDAP 'entryDN'
+ descriptor [RFC4520].
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryDN
+ Object Identifier: 1.3.6.1.1.20
+ Person & email address to contact for further information:
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Usage: Attribute Type
+ Specification: RFC 5020
+ Author/Change Controller: IESG
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 5020 LDAP entryDN August 2007
+
+
+5. References
+
+5.1. Normative References
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [X.501] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory -- Models,"
+ X.501(1993) (also ISO/IEC 9594-2:1994).
+
+5.2. Informative References
+
+ [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP)
+ and X.500 Component Matching Rules", RFC 3687, February
+ 2004.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names",
+ RFC 4514, June 2006.
+
+ [RFC4515] Smith, M., Ed., and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ Isode Limited
+
+ EMail: Kurt.Zeilenga@Isode.COM
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 5020 LDAP entryDN August 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+