]> git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldup-subentry-xx.txt
Merge in all devel changes since 2.0-alpha2.
[openldap] / doc / drafts / draft-ietf-ldup-subentry-xx.txt
1 INTERNET-DRAFT
2 draft-ietf-ldup-subentry-00.txt
3                                                                Ed Reed
4                                                           Novell, Inc.
5                                                        August 15, 1999
6
7                          LDAP Subentry Schema
8
9
10 1. Status of this Memo
11
12 This document is an Internet-Draft and is in full conformance with all
13 provisions of Section 10 of RFC2026.
14
15 Internet-Drafts are working documents of the Internet Engineering Task
16 Force (IETF), its areas, and its working groups. Note that other
17 groups may also distribute working documents as Internet-Drafts.
18
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference material
22 or to cite them other than as "work in progress."
23
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt.
26
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
29
30 This Internet-Draft expires on January 9, 1999.
31
32
33 2. Abstract
34
35 This document describes an object class called lDAPsubEntry which MAY
36 be used to indicate operations and management related entries in the
37 directory, called LDAP Subentries.
38
39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
41 document are to be interpreted as described in RFC 2119 [RFC2119]. The
42 sections below reiterate these definitions and include some additional
43 ones.
44
45
46
47
48
49
50
51 Reed                                                         [Page 1]
52                        Expires January 15, 2000\f
53
54
55 INTERNET-DRAFT                                         15 August 1999
56                          LDAP Subentry Schema
57
58 3. Definition
59
60
61 3.1 LDAPsubEntry Class
62
63 ( 1.3.6.1.4.1.1466.115.121.1.?? NAME 'LDAPsubEntry'
64    DESC 'LDAP Subentry class, named by cn'
65      SUP top STRUCTURAL
66      MUST ( cn ) )
67
68 The class lDAPsubEntry is intended to be used as a super class when
69 defining other structural classes to be used as LDAP Subentries.  The
70 presence of lDAPsubEntry in the list of super-classes of an entry in
71 the directory makes that entry an LDAP Subentry.  Object classes
72 derived from lDAPsubEntry are themselves considered lDAPsubEntry
73 classes, for the purpose of this discussion.
74
75 LDAP Subentries MAY be named by their commonName attribute [LDAPv3].
76 Other naming attributes are also permitted.
77
78 LDAP Subentries MAY be containers, unlike their [X.500] counterparts.
79
80 LDAP Subentries MAY be contained by, and will usually be located in
81 the directory information tree immediately subordinate to,
82 administrative points and/or naming contexts [LDUPINFO].  Further
83 (unlike X.500 subentries), LDAP Subentries MAY be contained by other
84 LDAP Subentries (the way organizational units may be contained by
85 other organizational units).  Deep nestings of LDAP Subentries are
86 discouraged, but not prohibited.
87
88 LDAP Subentries SHOULD be treated as "operational objects" in much the
89 same way that "operational attributes" are not regularly provided in
90 search results and read operations when only user attributes are
91 requested).
92
93 NOTE:  No special treatment of LDAP Subentries by applications is
94 required, but it might be worth considering creating an LDAPv3 control
95 to indicate when LDAP Subentries are desired to be returned (subject
96 to access controls and search filters, of course) for LDAP search
97 operations.
98
99
100
101 4. Security Considerations
102
103 LDAP Subentries will frequently be used to hold data which reflects
104 either the actual or intended behavior of the directory service.  As
105 such, permission to read such entries MAY need to be restricted to
106
107 Reed                                                         [Page 2]
108                        Expires January 15, 2000\f
109
110
111 INTERNET-DRAFT                                         15 August 1999
112                          LDAP Subentry Schema
113
114 authorized users.  More importantly, IF a directory service treats the
115 information in an LDAP Subentry as the authoritative source of policy
116 to be used to control the behavior of the directory, then permission
117 to create, modify, or delete such entries MUST be carefully restricted
118 to authorized administrators.
119
120
121
122 5. References
123
124 [LDUPINFO] _ E. Reed, "LDUP Replication Information Model", draft-
125 ietf-ldup-infomod-01.txt
126
127 [LDAPv3] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory
128 Access Protocol (v3)", RFC 2251, December 1997
129
130 [X.500] ITU-T Rec. X.501, "The Directory: Models", 1993
131
132
133
134 6. Copyright Notice
135
136 Copyright (C) The Internet Society (1999). All Rights Reserved.
137
138 This document and translations of it may be copied and furnished to
139 others, and derivative works that comment on or otherwise explain it
140 or assist in its implementation may be prepared, copied, published and
141 distributed, in whole or in part, without restriction of any kind,
142 provided that the above copyright notice and this paragraph are
143 included on all such copies and derivative works. However, this
144 document itself may not be modified in any way, such as by removing
145 the copyright notice or references to the Internet Society or other
146 Internet organizations, except as needed for the purpose of developing
147 Internet standards in which case the procedures for copyrights defined
148 in the Internet Standards process must be followed, or as required to
149 translate it into languages other than English.
150
151 The limited permissions granted above are perpetual and will not be
152 revoked by the Internet Society or its successors or assigns.
153
154 This document and the information contained herein is provided on an
155 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
156 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
157 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
158 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
159 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
160
161
162
163 Reed                                                         [Page 3]
164                        Expires January 15, 2000\f
165
166
167 INTERNET-DRAFT                                         15 August 1999
168                          LDAP Subentry Schema
169
170 7. Acknowledgements
171
172 The use of subEntry object class to store Replica and Replication
173 Agreement information is due primarily to the lucid explanation by
174 Mark Wahl, Innosoft, of how they could be used and extended.
175
176 The IETF takes no position regarding the validity or scope of any
177 intellectual property or other rights that might be claimed to pertain
178 to the implementation or use of the technology described in this
179 document or the extent to which any license under such rights might or
180 might not be available; neither does it represent that it has made any
181 effort to identify any such rights. Information on the IETF's
182 procedures with respect to rights in standards-track and standards-
183 related documentation can be found in BCP-11. Copies of claims of
184 rights made available for publication and any assurances of licenses
185 to be made available, or the result of an attempt made to obtain a
186 general license or permission for the use of such proprietary rights
187 by implementors or users of this specification can be obtained from
188 the IETF Secretariat.
189
190 The IETF invites any interested party to bring to its attention any
191 copyrights, patents or patent applications, or other proprietary
192 rights which may cover technology that may be required to practice
193 this standard. Please address the information to the IETF Executive
194 Director.
195
196
197 8. Author's Address
198
199      Edwards E. Reed
200      Novell, Inc.
201      122 E 1700 S
202      Provo, UT   84606
203      USA
204      E-mail: Ed_Reed@Novell.com
205
206      LDUP Mailing List: ietf-ldup@imc.org
207
208
209
210
211
212
213
214
215
216
217
218
219 Reed                                                         [Page 4]
220                        Expires January 15, 2000\f