]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3671.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc3671.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 3671                           OpenLDAP Foundation
9 Category: Standards Track                                  December 2003
10
11
12                         Collective Attributes in
13             the Lightweight Directory Access Protocol (LDAP)
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 Internet Society (2003).  All Rights Reserved.
26
27 Abstract
28
29    X.500 collective attributes allow common characteristics to be shared
30    between collections of entries.  This document summarizes the X.500
31    information model for collective attributes and describes use of
32    collective attributes in LDAP (Lightweight Directory Access
33    Protocol).  This document provides schema definitions for collective
34    attributes for use in LDAP.
35
36 1.  Introduction
37
38    In X.500 [X.500], a collective attribute is "a user attribute whose
39    values are the same for each member of an entry collection" [X.501].
40    This document details their use in the Lightweight Directory Access
41    Protocol (LDAP) [RFC3377].
42
43 1.1.  Entry Collections
44
45    A collection of entries is a grouping of object and alias entries
46    based upon common properties or shared relationship between the
47    corresponding entries which share certain attributes.  An entry
48    collection consists of all entries within scope of a collective
49    attributes subentry [RFC3672].  An entry can belong to several entry
50    collections.
51
52
53
54
55
56
57
58 Zeilenga                    Standards Track                     [Page 1]
59 \f
60 RFC 3671             Collective Attributes in LDAP         December 2003
61
62
63 1.2.  Collective Attributes
64
65    Attributes shared by the entries comprising an entry collection are
66    called collective attributes.  Values of collective attributes are
67    visible but not updateable to clients accessing entries within the
68    collection.  Collective attributes are updated (i.e., modified) via
69    their associated collective attributes subentry.
70
71    When an entry belongs to multiple entry collections, the entry's
72    values of each collective attribute are combined such that
73    independent sources of these values are not manifested to clients.
74
75    Entries can specifically exclude a particular collective attribute by
76    listing the attribute as a value of the collectiveExclusions
77    attribute.  Like other user attributes, collective attributes are
78    subject to a variety of controls including access, administrative,
79    and content controls.
80
81 1.3.  Conventions
82
83    Schema definitions are provided using LDAPv3 [RFC2251] description
84    formats [RFC2252].  Definitions provided here are formatted (line
85    wrapped) for readability.
86
87    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
88    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
89    document are to be interpreted as described in BCP 14 [RFC2119].
90
91 2.  System Schema for Collective Attributes
92
93    The following operational attributes are used to manage Collective
94    Attributes.  LDAP servers [RFC3377] MUST act in accordance with the
95    X.500 Directory Models [X.501] when providing this service.
96
97 2.1.  collectiveAttributeSubentry
98
99    Subentries of this object class are used to administer collective
100    attributes and are referred to as collective attribute subentries.
101
102       ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
103
104    A collective attribute subentry SHOULD contain at least one
105    collective attribute.  The collective attributes contained within a
106    collective attribute subentry are available for finding, searching,
107    and comparison at every entry within the scope of the subentry.  The
108    collective attributes, however, are administered (e.g., modified) via
109    the subentry.
110
111
112
113
114 Zeilenga                    Standards Track                     [Page 2]
115 \f
116 RFC 3671             Collective Attributes in LDAP         December 2003
117
118
119    Implementations of this specification SHOULD support collective
120    attribute subentries in both collectiveAttributeSpecificArea
121    (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative
122    areas [RFC3672][X.501].
123
124 2.2.  collectiveAttributeSubentries
125
126    The collectiveAttributeSubentries operational attribute identifies
127    all collective attribute subentries that affect the entry.
128
129       ( 2.5.18.12 NAME 'collectiveAttributeSubentries'
130         EQUALITY distinguishedNameMatch
131         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
132         USAGE directoryOperation NO-USER-MODIFICATION )
133
134 2.3.  collectiveExclusions
135
136    The collectiveExclusions operational attribute allows particular
137    collective attributes to be excluded from an entry.  It MAY appear in
138    any entry and MAY have multiple values.
139
140       ( 2.5.18.7 NAME 'collectiveExclusions'
141         EQUALITY objectIdentifierMatch
142         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
143         USAGE directoryOperation )
144
145    The descriptor excludeAllCollectiveAttributes is associated with the
146    OID 2.5.18.0.  When this descriptor or OID is present as a value of
147    the collectiveExclusions attribute, all collective attributes are
148    excluded from an entry.
149
150 3.  Collective Attribute Types
151
152    A userApplications attribute type can be defined to be COLLECTIVE
153    [RFC2252].  This indicates that the same attribute values will appear
154    in the entries of an entry collection subject to the use of the
155    collectiveExclusions attribute and other administrative controls.
156    These administrative controls MAY include DIT Content Rules, if
157    implemented.
158
159    Collective attribute types are commonly defined as subtypes of non-
160    collective attribute types.  By convention, collective attributes are
161    named by prefixing the name of their non-collective supertype with
162    "c-".  For example, the collective telephone attribute is named
163    c-TelephoneNumber after its non-collective supertype telephoneNumber.
164
165    Non-collective attributes types SHALL NOT subtype collective
166    attributes.
167
168
169
170 Zeilenga                    Standards Track                     [Page 3]
171 \f
172 RFC 3671             Collective Attributes in LDAP         December 2003
173
174
175    Collective attributes SHALL NOT be SINGLE-VALUED.  Collective
176    attribute types SHALL NOT appear in the attribute types of an object
177    class definition.
178
179    Operational attributes SHALL NOT be defined to be collective.
180
181    The remainder of section provides a summary of collective attributes
182    derived from those defined in [X.520].  The SUPerior attribute types
183    are described in [RFC 2256] for use with LDAP.
184
185    Implementations of this specification SHOULD support the following
186    collective attributes and MAY support additional collective
187    attributes.
188
189 3.1.  Collective Locality Name
190
191    The c-l attribute type specifies a locality name for a collection of
192    entries.
193
194       ( 2.5.4.7.1 NAME 'c-l'
195         SUP l COLLECTIVE )
196
197 3.2.  Collective State or Province Name
198
199    The c-st attribute type specifies a state or province name for a
200    collection of entries.
201
202       ( 2.5.4.8.1 NAME 'c-st'
203         SUP st COLLECTIVE )
204
205 3.3.  Collective Street Address
206
207    The c-street attribute type specifies a street address for a
208    collection of entries.
209
210       ( 2.5.4.9.1 NAME 'c-street'
211         SUP street COLLECTIVE )
212
213 3.4.  Collective Organization Name
214
215    The c-o attribute type specifies an organization name for a
216    collection of entries.
217
218       ( 2.5.4.10.1 NAME 'c-o'
219         SUP o COLLECTIVE )
220
221
222
223
224
225
226 Zeilenga                    Standards Track                     [Page 4]
227 \f
228 RFC 3671             Collective Attributes in LDAP         December 2003
229
230
231 3.5.  Collective Organizational Unit Name
232
233    The c-ou attribute type specifies an organizational unit name for a
234    collection of entries.
235
236       ( 2.5.4.11.1 NAME 'c-ou'
237         SUP ou COLLECTIVE )
238
239 3.6.  Collective Postal Address
240
241    The c-PostalAddress attribute type specifies a postal address for a
242    collection of entries.
243
244       ( 2.5.4.16.1 NAME 'c-PostalAddress'
245         SUP postalAddress COLLECTIVE )
246
247 3.7.  Collective Postal Code
248
249    The c-PostalCode attribute type specifies a postal code for a
250    collection of entries.
251
252       ( 2.5.4.17.1 NAME 'c-PostalCode'
253         SUP postalCode COLLECTIVE )
254
255 3.8.  Collective Post Office Box
256
257    The c-PostOfficeBox attribute type specifies a post office box for a
258    collection of entries.
259
260       ( 2.5.4.18.1 NAME 'c-PostOfficeBox'
261         SUP postOfficeBox COLLECTIVE )
262
263 3.9.  Collective Physical Delivery Office Name
264
265    The c-PhysicalDeliveryOfficeName attribute type specifies a physical
266    delivery office name for a collection of entries.
267
268       ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
269         SUP physicalDeliveryOfficeName COLLECTIVE )
270
271 3.10.  Collective Telephone Number
272
273    The c-TelephoneNumber attribute type specifies a telephone number for
274    a collection of entries.
275
276       ( 2.5.4.20.1 NAME 'c-TelephoneNumber'
277         SUP telephoneNumber COLLECTIVE )
278
279
280
281
282 Zeilenga                    Standards Track                     [Page 5]
283 \f
284 RFC 3671             Collective Attributes in LDAP         December 2003
285
286
287 3.11.  Collective Telex Number
288
289    The c-TelexNumber attribute type specifies a telex number for a
290    collection of entries.
291
292       ( 2.5.4.21.1 NAME 'c-TelexNumber'
293         SUP telexNumber COLLECTIVE )
294
295 3.13.  Collective Facsimile Telephone Number
296
297    The c-FacsimileTelephoneNumber attribute type specifies a facsimile
298    telephone number for a collection of entries.
299
300       ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
301
302    SUP facsimileTelephoneNumber COLLECTIVE )
303
304 3.14.  Collective International ISDN Number
305
306    The c-InternationalISDNNumber attribute type specifies an
307    international ISDN number for a collection of entries.
308
309       ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
310         SUP internationalISDNNumber COLLECTIVE )
311
312 4.  Security Considerations
313
314    Collective attributes, like other attributes, are subject to access
315    control restrictions and other administrative policy.  Generally
316    speaking, collective attributes accessed via an entry in a collection
317    are governed by rules restricting access to attributes of that entry.
318    And collective attributes access via a subentry are governed by rules
319    restricting access to attributes of that subentry.  However, as LDAP
320    does not have a standard access model, the particulars of each
321    server's access control system may differ.
322
323    General LDAP security considerations [RFC3377] also apply.
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Zeilenga                    Standards Track                     [Page 6]
339 \f
340 RFC 3671             Collective Attributes in LDAP         December 2003
341
342
343 5.  IANA Considerations
344
345    The IANA has registered the LDAP descriptors [RFC3383] defined in
346    this technical specification.  The following registration template is
347    suggested:
348
349       Subject: Request for LDAP Descriptor Registration
350       Descriptor see comments
351       Object Identifier: see comment
352       Person & email address to contact for further information:
353            Kurt Zeilenga <kurt@OpenLDAP.org>
354       Usage: see comment
355       Specification: RFC3671
356       Author/Change Controller: IESG
357       Comments:
358
359          NAME                           Type OID
360          ------------------------       ---- -----------------
361          c-FacsimileTelephoneNumber     A    2.5.4.23.1
362          c-InternationalISDNNumber      A    2.5.4.25.1
363          c-PhysicalDeliveryOffice       A    2.5.4.19.1
364          c-PostOfficeBox                A    2.5.4.18.1
365          c-PostalAddress                A    2.5.4.16.1
366          c-PostalCode                   A    2.5.4.17.1
367          c-TelephoneNumber              A    2.5.4.20.1
368          c-TelexNumber                  A    2.5.4.21.1
369          c-l                            A    2.5.4.7.1
370          c-o                            A    2.5.4.10.1
371          c-ou                           A    2.5.4.11.1
372          c-st                           A    2.5.4.8.1
373          c-street                       A    2.5.4.9.1
374          collectiveAttributeSubentries  A    2.5.18.12
375          collectiveAttributeSubentry    O    2.5.17.2
376          collectiveExclusions           A    2.5.18.7
377
378       where Type A is Attribute and Type O is ObjectClass.
379
380    The Object Identifiers used in this document were assigned by the
381    ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify
382    elements of X.500 schema [X.520].  This document make no OID
383    assignments, it only provides LDAP schema descriptions with existing
384    elements of X.500 schema.
385
386
387
388
389
390
391
392
393
394 Zeilenga                    Standards Track                     [Page 7]
395 \f
396 RFC 3671             Collective Attributes in LDAP         December 2003
397
398
399 6.  Intellectual Property Statement
400
401    The IETF takes no position regarding the validity or scope of any
402    intellectual property or other rights that might be claimed to
403    pertain to the implementation or use of the technology described in
404    this document or the extent to which any license under such rights
405    might or might not be available; neither does it represent that it
406    has made any effort to identify any such rights.  Information on the
407    IETF's procedures with respect to rights in standards-track and
408    standards-related documentation can be found in BCP-11.  Copies of
409    claims of rights made available for publication and any assurances of
410    licenses to be made available, or the result of an attempt made to
411    obtain a general license or permission for the use of such
412    proprietary rights by implementors or users of this specification can
413    be obtained from the IETF Secretariat.
414
415    The IETF invites any interested party to bring to its attention any
416    copyrights, patents or patent applications, or other proprietary
417    rights which may cover technology that may be required to practice
418    this standard.  Please address the information to the IETF Executive
419    Director.
420
421 7.  Acknowledgments
422
423    This document is based upon the ITU Recommendations for the Directory
424    [X.501][X.520].
425
426 8.  References
427
428 8.1.  Normative References
429
430    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
431               Requirement Levels", BCP 14, RFC 2119, March 1997.
432
433    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
434               Access Protocol (v3)", RFC 2251, December 1997.
435
436    [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
437               "Lightweight Directory Access Protocol (v3):  Attribute
438               Syntax Definitions", RFC 2252, December 1997.
439
440    [RFC2256]  Wahl, M., "A Summary of the X.500(96) User Schema for use
441               with LDAPv3", RFC 2256, December 1997.
442
443    [RFC3377]  Hodges, J. and R. L. Morgan, "Lightweight Directory Access
444               Protocol (v3): Technical Specification", RFC 3377,
445               September 2002.
446
447
448
449
450 Zeilenga                    Standards Track                     [Page 8]
451 \f
452 RFC 3671             Collective Attributes in LDAP         December 2003
453
454
455    [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
456               Considerations for the Lightweight Directory Access
457               Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
458
459    [RFC3672]  Zeilenga, K. and S. Legg, "Subentries in Lightweight
460               Directory Access Protocol (LDAP)", RFC 3672, December
461               2003.
462
463    [X.501]    "The Directory: Models", ITU-T Recommendation X.501, 1993.
464
465 8.2.  Informative References
466
467    [X.500]    "The Directory: Overview of Concepts, Models", ITU-T
468               Recommendation X.500, 1993.
469
470    [X.520]    "The Directory: Selected Attribute Types", ITU-T
471               Recommendation X.520, 1993.
472
473 9.  Author's Address
474
475    Kurt D. Zeilenga
476    OpenLDAP Foundation
477
478    EMail: Kurt@OpenLDAP.org
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506 Zeilenga                    Standards Track                     [Page 9]
507 \f
508 RFC 3671             Collective Attributes in LDAP         December 2003
509
510
511 10.  Full Copyright Statement
512
513    Copyright (C) The Internet Society (2003).  All Rights Reserved.
514
515    This document and translations of it may be copied and furnished to
516    others, and derivative works that comment on or otherwise explain it
517    or assist in its implementation may be prepared, copied, published
518    and distributed, in whole or in part, without restriction of any
519    kind, provided that the above copyright notice and this paragraph are
520    included on all such copies and derivative works.  However, this
521    document itself may not be modified in any way, such as by removing
522    the copyright notice or references to the Internet Society or other
523    Internet organizations, except as needed for the purpose of
524    developing Internet standards in which case the procedures for
525    copyrights defined in the Internet Standards process must be
526    followed, or as required to translate it into languages other than
527    English.
528
529    The limited permissions granted above are perpetual and will not be
530    revoked by the Internet Society or its successors or assignees.
531
532    This document and the information contained herein is provided on an
533    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
538
539 Acknowledgement
540
541    Funding for the RFC Editor function is currently provided by the
542    Internet Society.
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562 Zeilenga                    Standards Track                    [Page 10]
563 \f