idnits 2.17.1 draft-zeilenga-ldap-collective-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC2252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 388 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (18 August 2002) is 7884 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) == Missing Reference: 'RFC 2256' is mentioned on line 169, but not defined ** Obsolete undefined reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) == Missing Reference: 'LDAPIANA' is mentioned on line 295, but not defined == Unused Reference: 'RFC2251' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC2256' is defined on line 358, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- No information found for draft-ietf-ldapbis-ldapv3-ts-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPTS' -- No information found for draft-zeilenga-ldap-subentry-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SUBENTRY' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 18 August 2002 6 Collective Attributes in LDAP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as a Standard Track document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Extension Working Group 18 mailing list . Please send editorial comments 19 directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright 2002, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Abstract 41 X.500 collective attributes allow common characteristics to be shared 42 between collections of entries. This document summarizes the X.500 43 information model for collective attributes and describes use of 44 collective attributes in LDAP (Lightweight Directory Access Protocol). 45 This document provides schema definitions for collective attributes 46 for use in LDAP. 48 Conventions 50 Schema definitions are provided using LDAPv3 description formats 51 [RFC2252]. Definitions provided here are formatted (line wrapped) for 52 readability. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in BCP 14 [RFC2119]. 58 1. Introduction 60 In X.500, a collective attribute is "a user attribute whose values are 61 the same for each member of an entry collection" [X.501]. This 62 document details their use in the Lightweight Directory Access 63 Protocol (LDAP) [LDAPTS]. 65 1.1. Entry Collections 67 A collection of entries is a grouping of object and alias entries 68 based upon common properties or shared relationship between the 69 corresponding entries which share certain attributes. An entry 70 collection consists of all entries within scope of a collective 71 attributes subentry [SUBENTRY]. An entry can belong to several entry 72 collections. 74 1.2. Collective Attributes 76 Attributes shared by the entries comprising an entry collection are 77 called collective attributes. Values of collective attributes are 78 visible but not updateable to clients accessing entries within the 79 collection. Collective attributes are updated (i.e. modified) via 80 their associated collective attributes subentry. 82 When an entry belongs to multiple entry collections, the entry's 83 values of each collective attribute are combined such that independent 84 sources of these values are not manifested to clients. 86 Entries can specifically exclude a particular collective attribute by 87 listing the attribute as a value of the collectiveExclusions 88 attribute. Like other user attributes, collective attributes are 89 subject to a variety of controls including access, administrative, and 90 content controls. 92 2. System Schema for Collective Attributes 94 The following operational attributes are used to manage Collective 95 Attributes. LDAP servers [LDAPTS] MUST act in accordance with the 96 X.500 Directory Models [X.501] when providing this service. 98 2.1. collectiveAttributeSubentry 100 Subentries of this object class are used to administer collective 101 attributes and are referred to as collective attribute subentries. 103 ( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) 105 A collective attribute subentry SHOULD contain at least one collective 106 attribute. The collective attributes contained within a collective 107 attribute subentry are available for finding, searching, and 108 comparison at every entry within the scope of the subentry. The 109 collective attributes, however, are administered (e.g. modified) via 110 the subentry. 112 Implementations of this specification SHOULD support collective 113 attribute subentries in both collectiveAttributeSpecificArea 114 (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative 115 areas [SUBENTRY][X.501]. 117 2.2. collectiveAttributeSubentries 119 The collectiveAttributeSubentries operational attribute identifies all 120 collective attribute subentries that affect the entry. 122 ( 2.5.18.12 NAME 'collectiveAttributeSubentries' 123 EQUALITY distinguishedNameMatch 124 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 125 USAGE directoryOperation NO-USER-MODIFICATION ) 127 2.3. collectiveExclusions 129 The collectiveExclusions operational attribute allows particular 130 collective attributes to be excluded from an entry. It MAY appear in 131 any entry and MAY have multiple values. 133 ( 2.5.18.7 NAME 'collectiveExclusions' 134 EQUALITY objectIdentifierMatch 135 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 136 USAGE directoryOperation ) 138 The descriptor excludeAllCollectiveAttributes is associated with the 139 OID 2.5.18.0. When this descriptor or OID is present as a value of 140 the collectiveExclusions attribute, all collective attributes are 141 excluded from an entry. 143 3. Collective Attribute Types 145 A userApplications attribute type can be defined to be COLLECTIVE 146 [RFC2252]. This indicates that the same attribute values will appear 147 in the entries of an entry collection subject to the use of the 148 collectiveExclusions attribute and other administrative controls. 149 These administrative controls MAY include DIT Content Rules, if 150 implemented. 152 Collective attribute types are commonly defined as subtypes of non- 153 collective attribute types. By convention, collective attributes are 154 named by prefixing the name of their non-collective supertype with 155 "c-". For example, the collective telephone attribute is named 156 c-TelephoneNumber after its non-collective supertype telephoneNumber. 158 Non-collective attributes types SHALL NOT subtype collective 159 attributes. 161 Collective attributes SHALL NOT be SINGLE-VALUED. Collective 162 attribute types SHALL NOT appear in the attribute types of an object 163 class definition. 165 Operational attributes SHALL NOT be defined to be collective. 167 The remainder of section provides a summary of collective attributes 168 derived from those defined in [X.520]. The SUPerior attribute types 169 are described in [RFC 2256] for use with LDAP. 171 Implementations of this specification SHOULD support the following 172 collective attributes and MAY support additional collective 173 attributes. 175 3.1. Collective Locality Name 177 The c-l attribute type specifies a locality name for a collection of 178 entries. 180 ( 2.5.4.7.1 NAME 'c-l' 181 SUP l COLLECTIVE ) 183 3.2. Collective State or Province Name 185 The c-st attribute type specifies a state or province name for a 186 collection of entries. 188 ( 2.5.4.8.1 NAME 'c-st' 189 SUP st COLLECTIVE ) 191 3.3. Collective Street Address 193 The c-street attribute type specifies a street address for a 194 collection of entries. 196 ( 2.5.4.9.1 NAME 'c-street' 197 SUP street COLLECTIVE ) 199 3.4. Collective Organization Name 201 The c-o attribute type specifies an organization name for a collection 202 of entries. 204 ( 2.5.4.10.1 NAME 'c-o' 205 SUP o COLLECTIVE ) 207 3.5. Collective Organizational Unit Name 209 The c-ou attribute type specifies an organizational unit name for a 210 collection of entries. 212 ( 2.5.4.11.1 NAME 'c-ou' 213 SUP ou COLLECTIVE ) 215 3.6. Collective Postal Address 217 The c-PostalAddress attribute type specifies a postal address for a 218 collection of entries. 220 ( 2.5.4.16.1 NAME 'c-PostalAddress' 221 SUP postalAddress COLLECTIVE ) 223 3.7. Collective Postal Code 225 The c-PostalCode attribute type specifies a postal code for a 226 collection of entries. 228 ( 2.5.4.17.1 NAME 'c-PostalCode' 229 SUP postalCode COLLECTIVE ) 231 3.8. Collective Post Office Box 233 The c-PostOfficeBox attribute type specifies a post office box for a 234 collection of entries. 236 ( 2.5.4.18.1 NAME 'c-PostOfficeBox' 237 SUP postOfficeBox COLLECTIVE ) 239 3.9. Collective Physical Delivery Office Name 241 The c-PhysicalDeliveryOfficeName attribute type specifies a physical 242 delivery office name for a collection of entries. 244 ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' 245 SUP physicalDeliveryOfficeName COLLECTIVE ) 247 3.10. Collective Telephone Number 249 The c-TelephoneNumber attribute type specifies a telephone number for 250 a collection of entries. 252 ( 2.5.4.20.1 NAME 'c-TelephoneNumber' 253 SUP telephoneNumber COLLECTIVE ) 255 3.11. Collective Telex Number 257 The c-TelexNumber attribute type specifies a telex number for a 258 collection of entries. 260 ( 2.5.4.21.1 NAME 'c-TelexNumber' 261 SUP telexNumber COLLECTIVE ) 263 3.13. Collective Facsimile Telephone Number 265 The c-FacsimileTelephoneNumber attribute type specifies a facsimile 266 telephone number for a collection of entries. 268 ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' 269 SUP facsimileTelephoneNumber COLLECTIVE ) 271 3.14. Collective International ISDN Number 273 The c-InternationalISDNNumber attribute type specifies an 274 international ISDN number for a collection of entries. 276 ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' 277 SUP internationalISDNNumber COLLECTIVE ) 279 4. Security Considerations 281 Collective attributes, like other attributes, are subject to access 282 control restrictions and other administrative policy. Generally 283 speaking, collective attributes accessed via an entry in a collection 284 are governed by rules restricting access to attributes of that entry. 285 And collective attributes access via a subentry are governed by rules 286 restricting access to attributes of that subentry. However, as LDAP 287 does not have a standard access model, the particulars of each 288 server's access control system may differ. 290 General LDAP security considerations [LDAPTS] also apply. 292 5. IANA Considerations 294 It is requested that IANA register upon Standards Action the LDAP 295 descriptors [LDAPIANA] defined in this technical specification. The 296 following registration template is suggested: 298 Subject: Request for LDAP Descriptor Registration 299 Descriptor see comments 300 Object Identifier: see comment 301 Person & email address to contact for further information: 302 Kurt Zeilenga 303 Usage: see comment 304 Specification: RFCXXXX 305 Author/Change Controller: IESG 306 Comments: 308 NAME Type OID 309 ------------------------ ---- ----------------- 310 c-FacsimileTelephoneNumber A 2.5.4.23.1 311 c-InternationalISDNNumber A 2.5.4.25.1 312 c-PhysicalDeliveryOffice A 2.5.4.19.1 313 c-PostOfficeBox A 2.5.4.18.1 314 c-PostalAddress A 2.5.4.16.1 315 c-PostalCode A 2.5.4.17.1 316 c-TelephoneNumber A 2.5.4.20.1 317 c-TelexNumber A 2.5.4.21.1 318 c-l A 2.5.4.7.1 319 c-o A 2.5.4.10.1 320 c-ou A 2.5.4.11.1 321 c-st A 2.5.4.8.1 322 c-street A 2.5.4.9.1 323 collectiveAttributeSubentries A 2.5.18.12 324 collectiveAttributeSubentry O 2.5.20.2 325 collectiveExclusions A 2.5.18.7 327 where Type A is Attribute and Type O is ObjectClass. 329 The Object Identifiers used in this document were assigned by the 330 ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify 331 elements of X.500 schema [X.520]. This document make no OID 332 assignments, it only provides LDAP schema descriptions with existing 333 elements of X.500 schema. 335 6. Acknowledgments 337 This document is based upon the ITU Recommendations for the Directory 338 [X.501][X.520]. 340 7. Author's Address 342 Kurt D. Zeilenga 343 OpenLDAP Foundation 344 346 8. Normative References 348 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 351 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 352 Protocol (v3)", RFC 2251, December 1997. 354 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 355 Directory Access Protocol (v3): Attribute Syntax 356 Definitions", RFC 2252, December 1997. 358 [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use 359 with LDAPv3", RFC 2256, December 1997. 361 [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access 362 Protocol (v3): Technical Specification", 363 draft-ietf-ldapbis-ldapv3-ts-xx.txt. 365 [SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP", 366 draft-zeilenga-ldap-subentry-xx.txt, a work in progress. 368 [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993. 370 9. Informative References 372 [X.500] "The Directory: Overview of Concepts, Models", ITU-T 373 Recommendation X.500, 1993. 375 [X.520] "The Directory: Selected Attribute Types", ITU-T 376 Recommendation X.520, 1993. 378 Copyright 2002, The Internet Society. All Rights Reserved. 380 This document and translations of it may be copied and furnished to 381 others, and derivative works that comment on or otherwise explain it 382 or assist in its implementation may be prepared, copied, published and 383 distributed, in whole or in part, without restriction of any kind, 384 provided that the above copyright notice and this paragraph are 385 included on all such copies and derivative works. However, this 386 document itself may not be modified in any way, such as by removing 387 the copyright notice or references to the Internet Society or other 388 Internet organizations, except as needed for the purpose of 389 developing Internet standards in which case the procedures for 390 copyrights defined in the Internet Standards process must be followed, 391 or as required to translate it into languages other than English. 393 The limited permissions granted above are perpetual and will not be 394 revoked by the Internet Society or its successors or assigns. 396 This document and the information contained herein is provided on an 397 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 398 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 399 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 400 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 401 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.