idnits 2.17.1 draft-zeilenga-ldap-entrydn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 201. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 April 2007) is 6212 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track Isode Limited 4 Expires in six months 25 April 2007 6 The LDAP entryDN Operational Attribute 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as an Standard Track document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF LDAP Extensions mailing list 15 . Please send editorial comments directly to the 16 author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright (C) The IETF Trust (2007). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 This document describes the LDAP/X.500 'entryDN' operational 46 attribute. The attribute provides a copy of the entry's distinguished 47 name for use in attribute value assertions. 49 1. Background and Intended Use 51 In X.500 Directory Services [X.501], such as those accessible using 52 the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry 53 is identified by its distinguished name (DN) [RFC4512]. However, as 54 an entry's DN is not an attribute of the entry, it is not possible to 55 perform attribute value assertions [RFC4511] against it. 57 This document describes the 'entryDN' operational attribute which 58 holds a copy of the entry's distinguished name. This attribute may be 59 used in search filters. For instance, searching the subtree 60 with the filter: 62 (entryDN:componentFilterMatch:=or:{ 63 item:{ component "3", rule rdnMatch, value "ou=A" }, 64 item:{ component "3", rule rdnMatch, value "ou=B" } }) 66 would return entries in the subtree and 67 entries in subtree , but would not return any 68 other entries in the subtree . 70 In the above paragraph, DNs are presented using the string 71 representation defined in [RFC4514] and the example search filter is 72 presented using the string representation defined in [RFC4515] with 73 whitespace (line breaks and indentation) added to improve readability. 74 The 'componentFilterMatch' and 'rdnMatch' rules are specified in 75 [RFC3687]. 77 Schema definitions are provided using LDAP description formats 78 [RFC4512]. Definitions provided here are formatted (line wrapped) for 79 readability. 81 2. 'entryDN' Operational Attribute 83 The 'entryDN' operational attribute provides a copy of the entry's 84 current DN. 86 The following is a LDAP attribute type description suitable for 87 publication in subschema subentries. 89 ( IANA-ASSIGNED-OID NAME 'entryDN' 90 DESC 'DN of the entry' 91 EQUALITY distinguishedNameMatch 92 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 93 SINGLE-VALUE 94 NO-USER-MODIFICATION 95 USAGE directoryOperation ) 97 Note that the DN of the entry cannot be modified through this 98 attribute. 100 3. Security Considerations 102 As this attribute only provides an additional mechanism to access an 103 entry's DN, the introduction of this attribute is not believed to 104 introduce new security considerations. 106 4. IANA Considerations 108 4.1. Object Identifier Registration 110 It is requested that IANA register (upon Standards Action) an LDAP 111 Object Identifier [RFC4520] for use in this document. 113 Subject: Request for LDAP OID Registration 114 Person & email address to contact for further information: 115 Kurt Zeilenga 116 Specification: RFC XXXX 117 Author/Change Controller: IESG 118 Comments: 119 Identifies the 'entryDN' attribute type 121 [[Note to RFC Editor: The string IANA-ASSIGNED-OID, as it appears in 122 this document, is to be replaced by Object Identifier assigned by IANA 123 for use in document.]] 125 4.2. 'entryDN' Descriptor Registration 127 It is requested that IANA register (upon Standards Action) the LDAP 128 'entryDN' descriptor [RFC4520]. 130 Subject: Request for LDAP Descriptor Registration 131 Descriptor (short name): entryDN 132 Object Identifier: IANA-ASSIGNED-OID 133 Person & email address to contact for further information: 134 Kurt Zeilenga 135 Usage: Attribute Type 136 Specification: RFC XXXX 137 Author/Change Controller: IESG 139 5. Author's Address 141 Kurt D. Zeilenga 142 Isode Limited 144 Email: Kurt.Zeilenga@Isode.COM 146 6. References 148 6.1. Normative References 150 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 151 Road Map", RFC 4510, June 2006. 153 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 154 Models", RFC 4512, June 2006. 156 [X.501] International Telecommunication Union - 157 Telecommunication Standardization Sector, "The Directory 158 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 160 6.2. Informative References 162 [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP) 163 and X.500 Component Matching Rules", RFC 3687, February 164 2004. 166 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 167 4511, June 2006. 169 [RFC4514] Zeilenga, K. (editor), "LDAP: String Representation of 170 Distinguished Names", RFC 4514, June 2006. 172 [RFC4515] Smith, M. (editor), "LDAP: String Representation of 173 Search Filters", RFC 4515, June 2006. 175 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 176 (IANA) Considerations for the Lightweight Directory 177 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 179 Intellectual Property 181 The IETF takes no position regarding the validity or scope of any 182 Intellectual Property Rights or other rights that might be claimed to 183 pertain to the implementation or use of the technology described in 184 this document or the extent to which any license under such rights 185 might or might not be available; nor does it represent that it has 186 made any independent effort to identify any such rights. Information 187 on the procedures with respect to rights in RFC documents can be found 188 in BCP 78 and BCP 79. 190 Copies of IPR disclosures made to the IETF Secretariat and any 191 assurances of licenses to be made available, or the result of an 192 attempt made to obtain a general license or permission for the use of 193 such proprietary rights by implementers or users of this specification 194 can be obtained from the IETF on-line IPR repository at 195 http://www.ietf.org/ipr. 197 The IETF invites any interested party to bring to its attention any 198 copyrights, patents or patent applications, or other proprietary 199 rights that may cover technology that may be required to implement 200 this standard. Please address the information to the IETF at 201 ietf-ipr@ietf.org. 203 Full Copyright 205 Copyright (C) The IETF Trust (2007). 207 This document is subject to the rights, licenses and restrictions 208 contained in BCP 78, and except as set forth therein, the authors 209 retain all their rights. 211 This document and the information contained herein are provided on an 212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 214 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 215 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 216 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.