1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 3671 OpenLDAP Foundation 9Category: Standards Track December 2003 10 11 12 Collective Attributes in 13 the Lightweight Directory Access Protocol (LDAP) 14 15Status 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 23Copyright Notice 24 25 Copyright (C) The Internet Society (2003). All Rights Reserved. 26 27Abstract 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 361. 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 431.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 58Zeilenga Standards Track [Page 1] 59 60RFC 3671 Collective Attributes in LDAP December 2003 61 62 631.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 811.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 912. 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 972.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 114Zeilenga Standards Track [Page 2] 115 116RFC 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 1242.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 1342.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 1503. 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 170Zeilenga Standards Track [Page 3] 171 172RFC 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 1893.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 1973.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 2053.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 2133.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 226Zeilenga Standards Track [Page 4] 227 228RFC 3671 Collective Attributes in LDAP December 2003 229 230 2313.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 2393.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 2473.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 2553.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 2633.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 2713.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 282Zeilenga Standards Track [Page 5] 283 284RFC 3671 Collective Attributes in LDAP December 2003 285 286 2873.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 2953.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 3043.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 3124. 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 338Zeilenga Standards Track [Page 6] 339 340RFC 3671 Collective Attributes in LDAP December 2003 341 342 3435. 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 394Zeilenga Standards Track [Page 7] 395 396RFC 3671 Collective Attributes in LDAP December 2003 397 398 3996. 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 4217. Acknowledgments 422 423 This document is based upon the ITU Recommendations for the Directory 424 [X.501][X.520]. 425 4268. References 427 4288.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 450Zeilenga Standards Track [Page 8] 451 452RFC 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 4658.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 4739. 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 506Zeilenga Standards Track [Page 9] 507 508RFC 3671 Collective Attributes in LDAP December 2003 509 510 51110. 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 539Acknowledgement 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 562Zeilenga Standards Track [Page 10] 563 564