8 draft-ietf-ldup-subentry-03.txt
16 1. Status of this Memo
18 This document is an Internet-Draft and is in full
19 conformance with all provisions of Section 10 of RFC2026.
21 Internet-Drafts are working documents of the Internet
22 Engineering Task Force (IETF), its areas, and its working
23 groups. Note that other groups may also distribute working
24 documents as Internet-Drafts.
26 Internet-Drafts are draft documents valid for a maximum of
27 six months and may be updated, replaced, or obsoleted by
28 other documents at any time. It is inappropriate to use
29 Internet-Drafts as reference material or to cite them other
30 than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be
36 accessed at http://www.ietf.org/shadow.html.
38 This Internet-Draft expires on January 13, 2001.
43 This document describes an object class called ldapSubEntry
44 which MAY be used to indicate operations and management
45 related entries in the directory, called LDAP Subentries.
46 This version of this document is updated with an assigned
47 OID for the ldapSubEntry object class.
49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
50 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
51 and "OPTIONAL" in this document are to be interpreted as
52 described in RFC 2119 [RFC2119]. The sections below
53 reiterate these definitions and include some additional
58 Expires January 13, 2001
\f
61 INTERNET-DRAFT 13 July 2000
67 3.1 ldapSubEntry Class
69 ( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry'
70 DESC 'LDAP Subentry class, version 1'
74 The class ldapSubEntry is intended to be used as a super-
75 class when defining other structural classes to be used
76 as LDAP Subentries, and as the structural class to which
77 Auxiliary classes may be added for application specific
78 subentry information. Where possible, the use of Auxiliary
79 classes to extend ldapSubEntries is strongly preferred.
81 The presence of ldapSubEntry in the list of super-classes
82 of an entry in the directory makes that entry an LDAP
83 Subentry. Object classes derived from ldapSubEntry are
84 themselves considered ldapSubEntry classes, for the purpose
87 LDAP Subentries MAY be named by their commonName attribute
88 [LDAPv3]. Other naming attributes are also permitted.
90 LDAP Subentries MAY be containers, unlike their [X.501]
93 LDAP Subentries MAY be contained by, and will usually be
94 located in the directory information tree immediately
95 subordinate to, administrative points and/or naming
96 contexts. Further (unlike X.500 subentries), LDAP
97 Subentries MAY be contained by other LDAP Subentries (the
98 way organizational units may be contained by other
99 organizational units). Deep nestings of LDAP Subentries
100 are discouraged, but not prohibited.
102 LDAP Subentries SHOULD be treated as "operational objects"
103 in much the same way that "operational attributes" are not
104 regularly provided in search results and read operations
105 when only user attributes are requested).
107 LDAP servers SHOULD implement the following special
108 handling of ldapSubEntry entries:
110 a) search operations which include a matching criteria
111 "objectclass=ldapSubEntry" MUST include entries derived
114 Expires January 13, 2001
118 INTERNET-DRAFT 13 July 2000
121 from the ldapSubEntry class in the scope of their
124 b) search operations which do not include a matching
125 criteria "objectclass=ldapSubEntry" MUST IGNORE entries
126 derived from the ldapSubEntry class, and exclude them from
127 the scope of their operations.
129 The combination of SHOULD and MUST in the special handling
130 instructions, above, are meant to convey this: Servers
131 SHOULD support this special handling, and if they do they
132 MUST do it as described, and not some other way.
136 4. Security Considerations
138 LDAP Subentries will frequently be used to hold data which
139 reflects either the actual or intended behavior of the
140 directory service. As such, permission to read such
141 entries MAY need to be restricted to authorized users.
142 More importantly, IF a directory service treats the
143 information in an LDAP Subentry as the authoritative source
144 of policy to be used to control the behavior of the
145 directory, then permission to create, modify, or delete
146 such entries MUST be carefully restricted to authorized
153 [LDAPv3] S. Kille, M. Wahl, and T. Howes, "Lightweight
154 Directory Access Protocol (v3)", RFC 2251, December 1997
156 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993
162 Copyright (C) The Internet Society (1999). All Rights
165 This document and translations of it may be copied and
166 furnished to others, and derivative works that comment on
167 or otherwise explain it or assist in its implementation may
168 be prepared, copied, published and distributed, in whole or
171 Expires January 13, 2001
175 INTERNET-DRAFT 13 July 2000
178 in part, without restriction of any kind, provided that the
179 above copyright notice and this paragraph are included on
180 all such copies and derivative works. However, this
181 document itself may not be modified in any way, such as by
182 removing the copyright notice or references to the Internet
183 Society or other Internet organizations, except as needed
184 for the purpose of developing Internet standards in which
185 case the procedures for copyrights defined in the Internet
186 Standards process must be followed, or as required to
187 translate it into languages other than English.
189 The limited permissions granted above are perpetual and
190 will not be revoked by the Internet Society or its
191 successors or assigns.
193 This document and the information contained herein is
194 provided on an "AS IS" basis and THE INTERNET SOCIETY AND
195 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
196 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
197 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
198 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
199 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
204 The use of subEntry object class to store Replica and
205 Replication Agreement information is due primarily to the
206 lucid explanation by Mark Wahl, Innosoft, of how they could
207 be used and extended.
209 The IETF takes no position regarding the validity or scope
210 of any intellectual property or other rights that might be
211 claimed to pertain to the implementation or use of the
212 technology described in this document or the extent to
213 which any license under such rights might or might not be
214 available; neither does it represent that it has made any
215 effort to identify any such rights. Information on the
216 IETF's procedures with respect to rights in standards-track
217 and standards-related documentation can be found in BCP-11.
218 Copies of claims of rights made available for publication
219 and any assurances of licenses to be made available, or the
220 result of an attempt made to obtain a general license or
221 permission for the use of such proprietary rights by
222 implementors or users of this specification can be obtained
223 from the IETF Secretariat.
228 Expires January 13, 2001
232 INTERNET-DRAFT 13 July 2000
235 The IETF invites any interested party to bring to its
236 attention any copyrights, patents or patent applications,
237 or other proprietary rights which may cover technology that
238 may be required to practice this standard. Please address
239 the information to the IETF Executive Director.
249 E-mail: eer@oncalldba.com
251 LDUP Mailing List: ietf-ldup@imc.org
252 LDAPEXT Mailing List: ietf-ldapext@netscape.com
285 Expires January 13, 2001