From 6776a17beea52cc6194a6d91b5139bb109d53757 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Mon, 29 Dec 2003 18:40:10 +0000 Subject: [PATCH] Collective Attributes and Subentries are now RFCs. --- .../draft-zeilenga-ldap-collective-xx.txt | 507 ------------- .../draft-zeilenga-ldap-subentry-xx.txt | 675 ------------------ doc/rfc/INDEX | 2 + doc/rfc/rfc3671.txt | 563 +++++++++++++++ doc/rfc/rfc3672.txt | 675 ++++++++++++++++++ 5 files changed, 1240 insertions(+), 1182 deletions(-) delete mode 100644 doc/drafts/draft-zeilenga-ldap-collective-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-subentry-xx.txt create mode 100644 doc/rfc/rfc3671.txt create mode 100644 doc/rfc/rfc3672.txt diff --git a/doc/drafts/draft-zeilenga-ldap-collective-xx.txt b/doc/drafts/draft-zeilenga-ldap-collective-xx.txt deleted file mode 100644 index 4b20138d06..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-collective-xx.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -INTERNET-DRAFT Editor: Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 18 August 2002 - - - Collective Attributes in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - X.500 collective attributes allow common characteristics to be shared - between collections of entries. This document summarizes the X.500 - information model for collective attributes and describes use of - collective attributes in LDAP (Lightweight Directory Access Protocol). - This document provides schema definitions for collective attributes - for use in LDAP. - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 1] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - -Conventions - - Schema definitions are provided using LDAPv3 description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -1. Introduction - - In X.500, a collective attribute is "a user attribute whose values are - the same for each member of an entry collection" [X.501]. This - document details their use in the Lightweight Directory Access - Protocol (LDAP) [LDAPTS]. - - -1.1. Entry Collections - - A collection of entries is a grouping of object and alias entries - based upon common properties or shared relationship between the - corresponding entries which share certain attributes. An entry - collection consists of all entries within scope of a collective - attributes subentry [SUBENTRY]. An entry can belong to several entry - collections. - - -1.2. Collective Attributes - - Attributes shared by the entries comprising an entry collection are - called collective attributes. Values of collective attributes are - visible but not updateable to clients accessing entries within the - collection. Collective attributes are updated (i.e. modified) via - their associated collective attributes subentry. - - When an entry belongs to multiple entry collections, the entry's - values of each collective attribute are combined such that independent - sources of these values are not manifested to clients. - - Entries can specifically exclude a particular collective attribute by - listing the attribute as a value of the collectiveExclusions - attribute. Like other user attributes, collective attributes are - subject to a variety of controls including access, administrative, and - content controls. - - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 2] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - -2. System Schema for Collective Attributes - - The following operational attributes are used to manage Collective - Attributes. LDAP servers [LDAPTS] MUST act in accordance with the - X.500 Directory Models [X.501] when providing this service. - - -2.1. collectiveAttributeSubentry - - Subentries of this object class are used to administer collective - attributes and are referred to as collective attribute subentries. - - ( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) - - A collective attribute subentry SHOULD contain at least one collective - attribute. The collective attributes contained within a collective - attribute subentry are available for finding, searching, and - comparison at every entry within the scope of the subentry. The - collective attributes, however, are administered (e.g. modified) via - the subentry. - - Implementations of this specification SHOULD support collective - attribute subentries in both collectiveAttributeSpecificArea - (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative - areas [SUBENTRY][X.501]. - - -2.2. collectiveAttributeSubentries - - The collectiveAttributeSubentries operational attribute identifies all - collective attribute subentries that affect the entry. - - ( 2.5.18.12 NAME 'collectiveAttributeSubentries' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - USAGE directoryOperation NO-USER-MODIFICATION ) - - -2.3. collectiveExclusions - - The collectiveExclusions operational attribute allows particular - collective attributes to be excluded from an entry. It MAY appear in - any entry and MAY have multiple values. - - ( 2.5.18.7 NAME 'collectiveExclusions' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE directoryOperation ) - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 3] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - The descriptor excludeAllCollectiveAttributes is associated with the - OID 2.5.18.0. When this descriptor or OID is present as a value of - the collectiveExclusions attribute, all collective attributes are - excluded from an entry. - - -3. Collective Attribute Types - - A userApplications attribute type can be defined to be COLLECTIVE - [RFC2252]. This indicates that the same attribute values will appear - in the entries of an entry collection subject to the use of the - collectiveExclusions attribute and other administrative controls. - These administrative controls MAY include DIT Content Rules, if - implemented. - - Collective attribute types are commonly defined as subtypes of non- - collective attribute types. By convention, collective attributes are - named by prefixing the name of their non-collective supertype with - "c-". For example, the collective telephone attribute is named - c-TelephoneNumber after its non-collective supertype telephoneNumber. - - Non-collective attributes types SHALL NOT subtype collective - attributes. - - Collective attributes SHALL NOT be SINGLE-VALUED. Collective - attribute types SHALL NOT appear in the attribute types of an object - class definition. - - Operational attributes SHALL NOT be defined to be collective. - - The remainder of section provides a summary of collective attributes - derived from those defined in [X.520]. The SUPerior attribute types - are described in [RFC 2256] for use with LDAP. - - Implementations of this specification SHOULD support the following - collective attributes and MAY support additional collective - attributes. - - -3.1. Collective Locality Name - - The c-l attribute type specifies a locality name for a collection of - entries. - - ( 2.5.4.7.1 NAME 'c-l' - SUP l COLLECTIVE ) - - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 4] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - -3.2. Collective State or Province Name - - The c-st attribute type specifies a state or province name for a - collection of entries. - - ( 2.5.4.8.1 NAME 'c-st' - SUP st COLLECTIVE ) - - -3.3. Collective Street Address - - The c-street attribute type specifies a street address for a - collection of entries. - - ( 2.5.4.9.1 NAME 'c-street' - SUP street COLLECTIVE ) - - -3.4. Collective Organization Name - - The c-o attribute type specifies an organization name for a collection - of entries. - - ( 2.5.4.10.1 NAME 'c-o' - SUP o COLLECTIVE ) - - -3.5. Collective Organizational Unit Name - - The c-ou attribute type specifies an organizational unit name for a - collection of entries. - - ( 2.5.4.11.1 NAME 'c-ou' - SUP ou COLLECTIVE ) - - -3.6. Collective Postal Address - - The c-PostalAddress attribute type specifies a postal address for a - collection of entries. - - ( 2.5.4.16.1 NAME 'c-PostalAddress' - SUP postalAddress COLLECTIVE ) - - -3.7. Collective Postal Code - - The c-PostalCode attribute type specifies a postal code for a - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 5] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - collection of entries. - - ( 2.5.4.17.1 NAME 'c-PostalCode' - SUP postalCode COLLECTIVE ) - - -3.8. Collective Post Office Box - - The c-PostOfficeBox attribute type specifies a post office box for a - collection of entries. - - ( 2.5.4.18.1 NAME 'c-PostOfficeBox' - SUP postOfficeBox COLLECTIVE ) - - -3.9. Collective Physical Delivery Office Name - - The c-PhysicalDeliveryOfficeName attribute type specifies a physical - delivery office name for a collection of entries. - - ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' - SUP physicalDeliveryOfficeName COLLECTIVE ) - - -3.10. Collective Telephone Number - - The c-TelephoneNumber attribute type specifies a telephone number for - a collection of entries. - - ( 2.5.4.20.1 NAME 'c-TelephoneNumber' - SUP telephoneNumber COLLECTIVE ) - - -3.11. Collective Telex Number - - The c-TelexNumber attribute type specifies a telex number for a - collection of entries. - - ( 2.5.4.21.1 NAME 'c-TelexNumber' - SUP telexNumber COLLECTIVE ) - - -3.13. Collective Facsimile Telephone Number - - The c-FacsimileTelephoneNumber attribute type specifies a facsimile - telephone number for a collection of entries. - - ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 6] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - SUP facsimileTelephoneNumber COLLECTIVE ) - - -3.14. Collective International ISDN Number - - The c-InternationalISDNNumber attribute type specifies an - international ISDN number for a collection of entries. - - ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' - SUP internationalISDNNumber COLLECTIVE ) - - -4. Security Considerations - - Collective attributes, like other attributes, are subject to access - control restrictions and other administrative policy. Generally - speaking, collective attributes accessed via an entry in a collection - are governed by rules restricting access to attributes of that entry. - And collective attributes access via a subentry are governed by rules - restricting access to attributes of that subentry. However, as LDAP - does not have a standard access model, the particulars of each - server's access control system may differ. - - General LDAP security considerations [LDAPTS] also apply. - - -5. IANA Considerations - - It is requested that IANA register upon Standards Action the LDAP - descriptors [LDAPIANA] defined in this technical specification. The - following registration template is suggested: - - Subject: Request for LDAP Descriptor Registration - Descriptor see comments - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga - Usage: see comment - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - - NAME Type OID - ------------------------ ---- ----------------- - c-FacsimileTelephoneNumber A 2.5.4.23.1 - c-InternationalISDNNumber A 2.5.4.25.1 - c-PhysicalDeliveryOffice A 2.5.4.19.1 - c-PostOfficeBox A 2.5.4.18.1 - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 7] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - c-PostalAddress A 2.5.4.16.1 - c-PostalCode A 2.5.4.17.1 - c-TelephoneNumber A 2.5.4.20.1 - c-TelexNumber A 2.5.4.21.1 - c-l A 2.5.4.7.1 - c-o A 2.5.4.10.1 - c-ou A 2.5.4.11.1 - c-st A 2.5.4.8.1 - c-street A 2.5.4.9.1 - collectiveAttributeSubentries A 2.5.18.12 - collectiveAttributeSubentry O 2.5.20.2 - collectiveExclusions A 2.5.18.7 - - where Type A is Attribute and Type O is ObjectClass. - - - The Object Identifiers used in this document were assigned by the - ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify - elements of X.500 schema [X.520]. This document make no OID - assignments, it only provides LDAP schema descriptions with existing - elements of X.500 schema. - - -6. Acknowledgments - - This document is based upon the ITU Recommendations for the Directory - [X.501][X.520]. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 8] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use - with LDAPv3", RFC 2256, December 1997. - - [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", - draft-ietf-ldapbis-ldapv3-ts-xx.txt. - - [SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP", - draft-zeilenga-ldap-subentry-xx.txt, a work in progress. - - [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993. - - -9. Informative References - - [X.500] "The Directory: Overview of Concepts, Models", ITU-T - Recommendation X.500, 1993. - - [X.520] "The Directory: Selected Attribute Types", ITU-T - Recommendation X.520, 1993. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 9] - diff --git a/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt b/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt deleted file mode 100644 index deca7fd207..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Date: 18 August 2002 Steven Legg -Expires in six months Adacel Technologies - - - Subentries in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - In X.500 directories, subentries are special entries used to hold - information associated with a subtree or subtree refinement. This - document adapts X.500 subentries mechanisms for use with Lightweight - Directory Access Protocol (LDAP). - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 1] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - -Conventions - - Schema definitions are provided using LDAP description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - Protocol elements are described using ASN.1 [X.680]. The term - "BER-encoded" means the element is to be encoded using the Basic - Encoding Rules [X.690] under the restrictions detailed in Section 5.1 - of [RFC2251]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -1. Overview - - From [X.501]: - A subentry is a special kind of entry immediately subordinate to - an administrative point. It contains attributes that pertain to a - subtree (or subtree refinement) associated with its administrative - point. The subentries and their administrative point are part of - the same naming context. - - A single subentry may serve all or several aspects of - administrative authority. Alternatively, a specific aspect of - administrative authority may be handled through one or more of its - own subentries. - - Subentries in Lightweight Directory Access Protocol (LDAP) [LDAPTS] - SHALL behave in accordance with X.501 unless noted otherwise in this - specification. - - In absence of the subentries control (detailed in Section 3), - subentries SHALL NOT be considered in one-level and subtree scope - search operations. For all other operations, including base scope - search operations, subentries SHALL be considered. - - -2. Subentry Schema - -2.1. Subtree Specification Syntax - - The Subtree Specification syntax provides a general purpose mechanism - for the specification of a subset of entries in a subtree of the - Directory Information Tree (DIT). A subtree begins at some base entry - and includes the subordinates of that entry down to some identified - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 2] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - lower boundary, possibly extending to the leaf entries. A subtree - specification is always used within a context or scope which - implicitly determines the bounds of the subtree. For example, the - scope of a subtree specification for a subschema administrative area - does not include the subtrees of any subordinate administrative point - entries for subschema administration. Where a subtree specification - does not identify a contiguous subset of the entries within a single - subtree the collection is termed a subtree refinement. - - This syntax corresponds to the SubtreeSpecification ASN.1 type - described in [X.501], Section 11.3. This ASN.1 data type definition - is reproduced here for completeness. - - SubtreeSpecification ::= SEQUENCE { - base [0] LocalName DEFAULT { }, - COMPONENTS OF ChopSpecification, - specificationFilter [4] Refinement OPTIONAL } - - - LocalName ::= RDNSequence - - ChopSpecification ::= SEQUENCE { - specificExclusions [1] SET OF CHOICE { - chopBefore [0] LocalName, - chopAfter [1] LocalName } OPTIONAL, - minimum [2] BaseDistance DEFAULT 0, - maximum [3] BaseDistance OPTIONAL} - - BaseDistance ::= INTEGER (0 .. MAX) - - Refinement ::= CHOICE { - item [0] OBJECT-CLASS.&id, - and [1] SET OF Refinement, - or [2] SET OF Refinement, - not [3] Refinement } - - The components of SubtreeSpecification are: base, which identifies the - base entry of the subtree or subtree refinement, and - specificExclusions, minimum, maximum and specificationFilter, which - then reduce the set of subordinate entries of the base entry. The - subtree or subtree refinement contains all the entries within scope - that are not excluded by any of the components of the subtree - specification. When all of the components of SubtreeSpecification are - absent (i.e. when a value of the Subtree Specification syntax is the - empty sequence, {}), the subtree so specified implicitly includes all - the entries within scope. - - Any particular use of this mechanism MAY impose limitations or - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 3] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - constraints on the components of SubtreeSpecification. - - The LDAP syntax specification is: - - ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) - - The native LDAP encoding of values of this syntax is defined by the - Generic String Encoding Rules [GSER]. Appendix A provides an - equivalent ABNF for this syntax. - - -2.1.1. Base - - The base component of SubtreeSpecification nominates the base entry of - the subtree or subtree refinement. The base entry may be an entry - which is subordinate to the root entry of the scope in which the - subtree specification is used, in which case the base component - contains a sequence of RDNs relative to the root entry of the scope, - or may be the root entry of the scope itself (the default), in which - case the base component is absent or contains an empty sequence of - RDNs. - - Entries that are not subordinates of the base entry are excluded from - the subtree or subtree refinement. - - -2.1.2. Specific Exclusions - - The specificExclusions component of a ChopSpecification is a list of - exclusions that specify entries and their subordinates to be excluded - from the the subtree or subtree refinement. The entry is specified by - a sequence of RDNs relative to the base entry (i.e. a LocalName). - Each exclusion is of either the chopBefore or chopAfter form. If the - chopBefore form is used then the specified entry and its subordinates - are excluded from the subtree or subtree refinement. If the chopAfter - form is used then only the subordinates of the specified entry are - excluded from the subtree or subtree refinement. - - -2.1.3. Minimum and Maximum - - The minimum and maximum components of a ChopSpecification allow the - exclusion of entries based on their depth in the DIT. - - Entries that are less than the minimum number of RDN arcs below the - base entry are excluded from the subtree or subtree refinement. A - minimum value of zero (the default) corresponds to the base entry. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 4] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - Entries that are more than the maximum number of RDN arcs below the - base entry are excluded from the subtree or subtree refinement. An - absent maximum component indicates that there is no upper limit on the - number of RDN arcs below the base entry for entries in the subtree or - subtree refinement. - -2.1.4. Specification Filter - - The specificationFilter component is a boolean expression of - assertions about the values of the objectClass attribute of the base - entry and its subordinates. A Refinement assertion item evaluates to - true for an entry if that entry's objectClass attribute contains the - OID nominated in the assertion. Entries for which the overall filter - evaluates to false are excluded from the subtree refinement. If the - specificationFilter is absent then no entries are excluded from the - subtree or subtree refinement because of their objectClass attribute - values. - - -2.2. Administrative Role Attribute Type - - The Administrative Model defined in [X.501], clause 10 requires that - administrative entries contain an administrativeRole attribute to - indicate that the associated administrative area is concerned with one - or more administrative roles. - - The administrativeRole operational attribute is specified as follows: - - ( 2.5.18.5 NAME 'administrativeRole' - EQUALITY objectIdentifierMatch - USAGE directoryOperation - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - The possible values of this attribute defined in X.501 are: - - OID NAME - -------- ------------------------------- - 2.5.23.1 autonomousArea - 2.5.23.2 accessControlSpecificArea - 2.5.23.3 accessControlInnerArea - 2.5.23.4 subschemaAdminSpecificArea - 2.5.23.5 collectiveAttributeSpecificArea - 2.5.23.6 collectiveAttributeInnerArea - - Other values may be defined in other specifications. Names associated - with each administrative role are Object Identifier Descriptors - [LDAPIANA]. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 5] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - The administrativeRole operational attribute is also used to regulate - the subentries permitted to be subordinate to an administrative entry. - A subentry not of a class permitted by the administrativeRole - attribute cannot be subordinate to the administrative entry. - - -2.3. Subtree Specification Attribute Type - - The subtreeSpecification operational attribute is defined as follows: - - ( 2.5.18.6 NAME 'subtreeSpecification' - SINGLE-VALUE - USAGE directoryOperation - SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 ) - - This attribute is present in all subentries. See [X.501], clause 10. - Values of the subtreeSpecification attribute nominate collections of - entries within the DIT for one or more aspects of administrative - authority. - - -2.4. Subentry Object Class - - The subentry object class is a structural object class. - - ( 2.5.20.0 NAME 'subentry' - SUP top STRUCTURAL - MUST ( cn $ subtreeSpecification ) ) - - -3. Subentries Control - - The subentries control MAY be sent with a searchRequest to control the - visibility of entries and subentries which are within scope. - Non-visible entries or subentries are not returned in response to the - request. - - The subentries control is an LDAP Control whose controlType is - 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), - and controlValue contains a BER-encoded BOOLEAN indicating visibility. - A controlValue containing the value TRUE indicates that subentries are - visible and normal entries are not. A controlValue containing the - value FALSE indicates that normal entries are visible and subentries - are not. - - Note that TRUE visibility has the three octet encoding { 01 01 FF } - and FALSE visibility has the three octet encoding { 01 01 00 }. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 6] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - The controlValue SHALL NOT be absent. - - In absence of this control, subentries are not visible to singleLevel - and wholeSubtree scope Search requests but are visible to baseObject - scope Search requests. - - There is no corresponding response control. - - This control is not appropriate for non-Search operations. - - -4. Security Considerations - - Subentries often hold administrative information or other sensitive - information and should be protected from unauthorized access and - disclosure as described in [RFC2829][RFC2830]. - - General LDAP [LDAPTS] security considerations also apply. - - -5. IANA Considerations - -5.1 Descriptors - - It is requested that IANA register upon Standards Action the LDAP - descriptors detailed in this technical specification. The following - registration template is suggested: - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): see comment - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga - Usage: see comment - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - - NAME Type OID - ------------------------ ---- -------- - accessControlInnerArea R 2.5.23.3 - accessControlSpecificArea R 2.5.23.2 - administrativeRole A 2.5.18.5 - autonomousArea R 2.5.23.1 - collectiveAttributeInnerArea R 2.5.23.6 - collectiveAttributeSpecificArea R 2.5.23.5 - subentry O 2.5.20.0 - subschemaAdminSpecificArea R 2.5.23.4 - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 7] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - subtreeSpecification A 2.5.18.6 - - where Type A is Attribute, Type O is ObjectClass, and Type R is - Administrative Role. - - -5.2 Object Identifiers - - This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP - protocol element defined herein. This OID was assigned [ASSIGN] by - OpenLDAP Foundation, under its IANA-assigned private enterprise - allocation [PRIVATE], for use in this specification. - - Other OIDs which appear in this document were either assigned by the - ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify - elements of X.500 schema or assigned in RFC 2252 for the use described - here. - - -5.3 Protocol Mechanisms - - Registration of the protocol mechanisms defined in this document is - requested [LDAPIANA]. - - Subject: Request for LDAP Protocol Mechansism Registration - - Object Identifier: 1.3.6.1.4.1.4203.1.10.1 - - Description: Subentries - - Person & email address to contact for further information: - Kurt Zeilenga - - Usage: Control - - Specification: RFCxxxx - - Author/Change Controller: IESG - - Comments: none - - -6. Acknowledgment - - This document is based on engineering done by IETF LDUP and LDAPext - Working Groups including "LDAP Subentry Schema" by Ed Reed. This - document also borrows from a number of ITU documents including X.501. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 8] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - -7. Authors' Addresses - - Kurt D. Zeilenga - OpenLDAP Foundation - - Email: Kurt@OpenLDAP.org - - Steven Legg - Adacel Technologies Ltd. - 405-409 Ferntree Gully Road - Mount Waverley, Victoria 3149 - AUSTRALIA - - Phone: +61 3 9451 2107 - Fax: +61 3 9541 2121 - EMail: steven.legg@adacel.com.au - - -8. Normative References - - [X.501] ITU-T, "The Directory -- Models," X.501, 1993. - - [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - - Specification of Basic Notation", X.680, 1994. - - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (was RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, - "Authentication Methods for LDAP", RFC 2829, May 2000 - - [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer - Security", RFC 2830, May 2000. - - [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", - draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress. - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 9] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - [GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types", - draft-legg-ldapext-gser--xx.txt, a work in progress. - - [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf- - ldapbis-iana-xx.txt, a work in progress. - - -9. Informative References - - [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [GCE] S. Legg, "Common Elements of GSER Encodings", - draft-legg-ldap-gser-abnf-xx.txt, a work in progress. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - -A. Subtree Specification ABNF - - This appendix is non-normative. - - The LDAP-specific native string encoding for the Subtree Specification - syntax is specified by the Generic String Encoding Rules [GSER]. The - ABNF [RFC2234] in this appendix for this syntax is provided only as a - convenience and is equivalent to the encoding specified by the - application of [GSER]. Since the SubtreeSpecification ASN.1 type may - be extended in future editions of [X.501], the provided ABNF should be - regarded as a snapshot in time. The native LDAP encoding for any - extension to the SubtreeSpecification ASN.1 type can be determined - from [GSER]. - - In the event that there is a discrepancy between this ABNF and the - encoding determined by [GSER], [GSER] is to be taken as definitive. - - SubtreeSpecification = "{" [ sp ss-base ] - [ sep sp ss-specificExclusions ] - [ sep sp ss-minimum ] - [ sep sp ss-maximum ] - [ sep sp ss-specificationFilter ] - sp "}" - - ss-base = id-base msp LocalName - ss-specificExclusions = id-specificExclusions msp SpecificExclusions - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 10] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - ss-minimum = id-minimum msp BaseDistance - ss-maximum = id-maximum msp BaseDistance - ss-specificationFilter = id-specificationFilter msp Refinement - - id-base = %x62.61.73.65 ; "base" - id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73 - %x69.6F.6E.73 ; "specificExclusions" - id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum" - id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum" - id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46 - %x69.6C.74.65.72 ; "specificationFilter" - - SpecificExclusions = "{" sp SpecificExclusion - *( "," sp SpecificExclusion ) sp "}" - SpecificExclusion = chopBefore / chopAfter - chopBefore = id-chopBefore ":" LocalName - chopAfter = id-chopAfter ":" LocalName - id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore" - id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter" - - Refinement = item / and / or / not - item = id-item ":" OBJECT-IDENTIFIER - and = id-and ":" Refinements - or = id-or ":" Refinements - not = id-not ":" Refinement - Refinements = "{" [ sp Refinement - *( "," sp Refinement ) ] sp "}" - id-item = %x69.74.65.6D ; "item" - id-and = %x61.6E.64 ; "and" - id-or = %x6F.72 ; "or" - id-not = %x6E.6F.74 ; "not" - - BaseDistance = INTEGER-0-MAX - - The , , , , and - rules are defined in [GCE]. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 11] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 12] - diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index 3a627623aa..074e295be4 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -33,6 +33,8 @@ rfc3296.txt Named Subordinate References in LDAP (PS) rfc3377.txt LDAP(v3): Technical Specification (PS) rfc3383.txt IANA Considerations for LDAP (BCP) rfc3663.txt Domain Administrative Data in LDAP (E) +rfc3671.txt Collective Attributes in LDAP (PS) +rfc3672.txt Subentries in the LDAP (PS) rfc3673.txt LDAPv3: All Operational Attributes (PS) rfc3674.txt Feature Discovery in LDAP (PS) diff --git a/doc/rfc/rfc3671.txt b/doc/rfc/rfc3671.txt new file mode 100644 index 0000000000..7157acc8f1 --- /dev/null +++ b/doc/rfc/rfc3671.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3671 OpenLDAP Foundation +Category: Standards Track December 2003 + + + Collective Attributes in + the Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + X.500 collective attributes allow common characteristics to be shared + between collections of entries. This document summarizes the X.500 + information model for collective attributes and describes use of + collective attributes in LDAP (Lightweight Directory Access + Protocol). This document provides schema definitions for collective + attributes for use in LDAP. + +1. Introduction + + In X.500 [X.500], a collective attribute is "a user attribute whose + values are the same for each member of an entry collection" [X.501]. + This document details their use in the Lightweight Directory Access + Protocol (LDAP) [RFC3377]. + +1.1. Entry Collections + + A collection of entries is a grouping of object and alias entries + based upon common properties or shared relationship between the + corresponding entries which share certain attributes. An entry + collection consists of all entries within scope of a collective + attributes subentry [RFC3672]. An entry can belong to several entry + collections. + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +1.2. Collective Attributes + + Attributes shared by the entries comprising an entry collection are + called collective attributes. Values of collective attributes are + visible but not updateable to clients accessing entries within the + collection. Collective attributes are updated (i.e., modified) via + their associated collective attributes subentry. + + When an entry belongs to multiple entry collections, the entry's + values of each collective attribute are combined such that + independent sources of these values are not manifested to clients. + + Entries can specifically exclude a particular collective attribute by + listing the attribute as a value of the collectiveExclusions + attribute. Like other user attributes, collective attributes are + subject to a variety of controls including access, administrative, + and content controls. + +1.3. Conventions + + Schema definitions are provided using LDAPv3 [RFC2251] description + formats [RFC2252]. Definitions provided here are formatted (line + wrapped) for readability. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. System Schema for Collective Attributes + + The following operational attributes are used to manage Collective + Attributes. LDAP servers [RFC3377] MUST act in accordance with the + X.500 Directory Models [X.501] when providing this service. + +2.1. collectiveAttributeSubentry + + Subentries of this object class are used to administer collective + attributes and are referred to as collective attribute subentries. + + ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) + + A collective attribute subentry SHOULD contain at least one + collective attribute. The collective attributes contained within a + collective attribute subentry are available for finding, searching, + and comparison at every entry within the scope of the subentry. The + collective attributes, however, are administered (e.g., modified) via + the subentry. + + + + +Zeilenga Standards Track [Page 2] + +RFC 3671 Collective Attributes in LDAP December 2003 + + + Implementations of this specification SHOULD support collective + attribute subentries in both collectiveAttributeSpecificArea + (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative + areas [RFC3672][X.501]. + +2.2. collectiveAttributeSubentries + + The collectiveAttributeSubentries operational attribute identifies + all collective attribute subentries that affect the entry. + + ( 2.5.18.12 NAME 'collectiveAttributeSubentries' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + USAGE directoryOperation NO-USER-MODIFICATION ) + +2.3. collectiveExclusions + + The collectiveExclusions operational attribute allows particular + collective attributes to be excluded from an entry. It MAY appear in + any entry and MAY have multiple values. + + ( 2.5.18.7 NAME 'collectiveExclusions' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE directoryOperation ) + + The descriptor excludeAllCollectiveAttributes is associated with the + OID 2.5.18.0. When this descriptor or OID is present as a value of + the collectiveExclusions attribute, all collective attributes are + excluded from an entry. + +3. Collective Attribute Types + + A userApplications attribute type can be defined to be COLLECTIVE + [RFC2252]. This indicates that the same attribute values will appear + in the entries of an entry collection subject to the use of the + collectiveExclusions attribute and other administrative controls. + These administrative controls MAY include DIT Content Rules, if + implemented. + + Collective attribute types are commonly defined as subtypes of non- + collective attribute types. By convention, collective attributes are + named by prefixing the name of their non-collective supertype with + "c-". For example, the collective telephone attribute is named + c-TelephoneNumber after its non-collective supertype telephoneNumber. + + Non-collective attributes types SHALL NOT subtype collective + attributes. + + + +Zeilenga Standards Track [Page 3] + +RFC 3671 Collective Attributes in LDAP December 2003 + + + Collective attributes SHALL NOT be SINGLE-VALUED. Collective + attribute types SHALL NOT appear in the attribute types of an object + class definition. + + Operational attributes SHALL NOT be defined to be collective. + + The remainder of section provides a summary of collective attributes + derived from those defined in [X.520]. The SUPerior attribute types + are described in [RFC 2256] for use with LDAP. + + Implementations of this specification SHOULD support the following + collective attributes and MAY support additional collective + attributes. + +3.1. Collective Locality Name + + The c-l attribute type specifies a locality name for a collection of + entries. + + ( 2.5.4.7.1 NAME 'c-l' + SUP l COLLECTIVE ) + +3.2. Collective State or Province Name + + The c-st attribute type specifies a state or province name for a + collection of entries. + + ( 2.5.4.8.1 NAME 'c-st' + SUP st COLLECTIVE ) + +3.3. Collective Street Address + + The c-street attribute type specifies a street address for a + collection of entries. + + ( 2.5.4.9.1 NAME 'c-street' + SUP street COLLECTIVE ) + +3.4. Collective Organization Name + + The c-o attribute type specifies an organization name for a + collection of entries. + + ( 2.5.4.10.1 NAME 'c-o' + SUP o COLLECTIVE ) + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +3.5. Collective Organizational Unit Name + + The c-ou attribute type specifies an organizational unit name for a + collection of entries. + + ( 2.5.4.11.1 NAME 'c-ou' + SUP ou COLLECTIVE ) + +3.6. Collective Postal Address + + The c-PostalAddress attribute type specifies a postal address for a + collection of entries. + + ( 2.5.4.16.1 NAME 'c-PostalAddress' + SUP postalAddress COLLECTIVE ) + +3.7. Collective Postal Code + + The c-PostalCode attribute type specifies a postal code for a + collection of entries. + + ( 2.5.4.17.1 NAME 'c-PostalCode' + SUP postalCode COLLECTIVE ) + +3.8. Collective Post Office Box + + The c-PostOfficeBox attribute type specifies a post office box for a + collection of entries. + + ( 2.5.4.18.1 NAME 'c-PostOfficeBox' + SUP postOfficeBox COLLECTIVE ) + +3.9. Collective Physical Delivery Office Name + + The c-PhysicalDeliveryOfficeName attribute type specifies a physical + delivery office name for a collection of entries. + + ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' + SUP physicalDeliveryOfficeName COLLECTIVE ) + +3.10. Collective Telephone Number + + The c-TelephoneNumber attribute type specifies a telephone number for + a collection of entries. + + ( 2.5.4.20.1 NAME 'c-TelephoneNumber' + SUP telephoneNumber COLLECTIVE ) + + + + +Zeilenga Standards Track [Page 5] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +3.11. Collective Telex Number + + The c-TelexNumber attribute type specifies a telex number for a + collection of entries. + + ( 2.5.4.21.1 NAME 'c-TelexNumber' + SUP telexNumber COLLECTIVE ) + +3.13. Collective Facsimile Telephone Number + + The c-FacsimileTelephoneNumber attribute type specifies a facsimile + telephone number for a collection of entries. + + ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' + + SUP facsimileTelephoneNumber COLLECTIVE ) + +3.14. Collective International ISDN Number + + The c-InternationalISDNNumber attribute type specifies an + international ISDN number for a collection of entries. + + ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' + SUP internationalISDNNumber COLLECTIVE ) + +4. Security Considerations + + Collective attributes, like other attributes, are subject to access + control restrictions and other administrative policy. Generally + speaking, collective attributes accessed via an entry in a collection + are governed by rules restricting access to attributes of that entry. + And collective attributes access via a subentry are governed by rules + restricting access to attributes of that subentry. However, as LDAP + does not have a standard access model, the particulars of each + server's access control system may differ. + + General LDAP security considerations [RFC3377] also apply. + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +5. IANA Considerations + + The IANA has registered the LDAP descriptors [RFC3383] defined in + this technical specification. The following registration template is + suggested: + + Subject: Request for LDAP Descriptor Registration + Descriptor see comments + Object Identifier: see comment + Person & email address to contact for further information: + Kurt Zeilenga + Usage: see comment + Specification: RFC3671 + Author/Change Controller: IESG + Comments: + + NAME Type OID + ------------------------ ---- ----------------- + c-FacsimileTelephoneNumber A 2.5.4.23.1 + c-InternationalISDNNumber A 2.5.4.25.1 + c-PhysicalDeliveryOffice A 2.5.4.19.1 + c-PostOfficeBox A 2.5.4.18.1 + c-PostalAddress A 2.5.4.16.1 + c-PostalCode A 2.5.4.17.1 + c-TelephoneNumber A 2.5.4.20.1 + c-TelexNumber A 2.5.4.21.1 + c-l A 2.5.4.7.1 + c-o A 2.5.4.10.1 + c-ou A 2.5.4.11.1 + c-st A 2.5.4.8.1 + c-street A 2.5.4.9.1 + collectiveAttributeSubentries A 2.5.18.12 + collectiveAttributeSubentry O 2.5.17.2 + collectiveExclusions A 2.5.18.7 + + where Type A is Attribute and Type O is ObjectClass. + + The Object Identifiers used in this document were assigned by the + ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify + elements of X.500 schema [X.520]. This document make no OID + assignments, it only provides LDAP schema descriptions with existing + elements of X.500 schema. + + + + + + + + + +Zeilenga Standards Track [Page 7] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +7. Acknowledgments + + This document is based upon the ITU Recommendations for the Directory + [X.501][X.520]. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use + with LDAPv3", RFC 2256, December 1997. + + [RFC3377] Hodges, J. and R. L. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + + + +Zeilenga Standards Track [Page 8] + +RFC 3671 Collective Attributes in LDAP December 2003 + + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + + [RFC3672] Zeilenga, K. and S. Legg, "Subentries in Lightweight + Directory Access Protocol (LDAP)", RFC 3672, December + 2003. + + [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993. + +8.2. Informative References + + [X.500] "The Directory: Overview of Concepts, Models", ITU-T + Recommendation X.500, 1993. + + [X.520] "The Directory: Selected Attribute Types", ITU-T + Recommendation X.520, 1993. + +9. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 9] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 10] + diff --git a/doc/rfc/rfc3672.txt b/doc/rfc/rfc3672.txt new file mode 100644 index 0000000000..62097db7fa --- /dev/null +++ b/doc/rfc/rfc3672.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3672 OpenLDAP Foundation +Category: Standards Track S. Legg + Adacel Technologies + December 2003 + + + Subentries in the Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + In X.500 directories, subentries are special entries used to hold + information associated with a subtree or subtree refinement. This + document adapts X.500 subentries mechanisms for use with the + Lightweight Directory Access Protocol (LDAP). + +1. Overview + + From [X.501]: + + A subentry is a special kind of entry immediately subordinate to + an administrative point. It contains attributes that pertain to + a subtree (or subtree refinement) associated with its + administrative point. The subentries and their administrative + point are part of the same naming context. + + A single subentry may serve all or several aspects of + administrative authority. Alternatively, a specific aspect of + administrative authority may be handled through one or more of + its own subentries. + + Subentries in the Lightweight Directory Access Protocol (LDAP) + [RFC3377] SHALL behave in accordance with X.501 unless noted + otherwise in this specification. + + + + + +Zeilenga & Legg Standards Track [Page 1] + +RFC 3672 Subentries in LDAP December 2003 + + + In absence of the subentries control (detailed in Section 3), + subentries SHALL NOT be considered in one-level and subtree scope + search operations. For all other operations, including base scope + search operations, subentries SHALL be considered. + +1.1. Conventions + + Schema definitions are provided using LDAP description formats + [RFC2252]. Definitions provided here are formatted (line wrapped) + for readability. + + Protocol elements are described using ASN.1 [X.680]. The term "BER- + encoded" means the element is to be encoded using the Basic Encoding + Rules [X.690] under the restrictions detailed in Section 5.1 of + [RFC2251]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. Subentry Schema + +2.1. Subtree Specification Syntax + + The Subtree Specification syntax provides a general purpose mechanism + for the specification of a subset of entries in a subtree of the + Directory Information Tree (DIT). A subtree begins at some base + entry and includes the subordinates of that entry down to some + identified lower boundary, possibly extending to the leaf entries. A + subtree specification is always used within a context or scope which + implicitly determines the bounds of the subtree. For example, the + scope of a subtree specification for a subschema administrative area + does not include the subtrees of any subordinate administrative point + entries for subschema administration. Where a subtree specification + does not identify a contiguous subset of the entries within a single + subtree the collection is termed a subtree refinement. + + This syntax corresponds to the SubtreeSpecification ASN.1 type + described in [X.501], Section 11.3. This ASN.1 data type definition + is reproduced here for completeness. + + SubtreeSpecification ::= SEQUENCE { + base [0] LocalName DEFAULT { }, + COMPONENTS OF ChopSpecification, + specificationFilter [4] Refinement OPTIONAL } + + LocalName ::= RDNSequence + + + + +Zeilenga & Legg Standards Track [Page 2] + +RFC 3672 Subentries in LDAP December 2003 + + + ChopSpecification ::= SEQUENCE { + specificExclusions [1] SET OF CHOICE { + chopBefore [0] LocalName, + chopAfter [1] LocalName } OPTIONAL, + minimum [2] BaseDistance DEFAULT 0, + maximum [3] BaseDistance OPTIONAL } + + BaseDistance ::= INTEGER (0 .. MAX) + + Refinement ::= CHOICE { + item [0] OBJECT-CLASS.&id, + and [1] SET OF Refinement, + or [2] SET OF Refinement, + not [3] Refinement } + + The components of SubtreeSpecification are: base, which identifies + the base entry of the subtree or subtree refinement, and + specificExclusions, minimum, maximum and specificationFilter, which + then reduce the set of subordinate entries of the base entry. The + subtree or subtree refinement contains all the entries within scope + that are not excluded by any of the components of the subtree + specification. When all of the components of SubtreeSpecification + are absent (i.e., when a value of the Subtree Specification syntax is + the empty sequence, {}), the specified subtree implicitly includes + all the entries within scope. + + Any particular use of this mechanism MAY impose limitations or + constraints on the components of SubtreeSpecification. + + The LDAP syntax specification is: + + ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) + + The LDAP-specific encoding of values of this syntax is defined by the + Generic String Encoding Rules [RFC3641]. Appendix A provides an + equivalent Augmented Backus-Naur Form (ABNF) [RFC2234] for this + syntax. + +2.1.1. Base + + The base component of SubtreeSpecification nominates the base entry + of the subtree or subtree refinement. The base entry may be an entry + which is subordinate to the root entry of the scope in which the + subtree specification is used, in which case the base component + contains a sequence of Relative Distinguished Names (RDNs) relative + to the root entry of the scope, or may be the root entry of the scope + itself (the default), in which case the base component is absent or + contains an empty sequence of RDNs. + + + +Zeilenga & Legg Standards Track [Page 3] + +RFC 3672 Subentries in LDAP December 2003 + + + Entries that are not subordinates of the base entry are excluded from + the subtree or subtree refinement. + +2.1.2. Specific Exclusions + + The specificExclusions component of a ChopSpecification is a list of + exclusions that specify entries and their subordinates to be excluded + from the subtree or subtree refinement. The entry is specified by a + sequence of RDNs relative to the base entry (i.e., a LocalName). + Each exclusion is of either the chopBefore or chopAfter form. If the + chopBefore form is used then the specified entry and its subordinates + are excluded from the subtree or subtree refinement. If the + chopAfter form is used then only the subordinates of the specified + entry are excluded from the subtree or subtree refinement. + +2.1.3. Minimum and Maximum + + The minimum and maximum components of a ChopSpecification allow the + exclusion of entries based on their depth in the DIT. + + Entries that are less than the minimum number of RDN arcs below the + base entry are excluded from the subtree or subtree refinement. A + minimum value of zero (the default) corresponds to the base entry. + + Entries that are more than the maximum number of RDN arcs below the + base entry are excluded from the subtree or subtree refinement. An + absent maximum component indicates that there is no upper limit on + the number of RDN arcs below the base entry for entries in the + subtree or subtree refinement. + +2.1.4. Specification Filter + + The specificationFilter component is a boolean expression of + assertions about the values of the objectClass attribute of the base + entry and its subordinates. A Refinement assertion item evaluates to + true for an entry if that entry's objectClass attribute contains the + OID nominated in the assertion. Entries for which the overall filter + evaluates to false are excluded from the subtree refinement. If the + specificationFilter is absent then no entries are excluded from the + subtree or subtree refinement because of their objectClass attribute + values. + + + + + + + + + + +Zeilenga & Legg Standards Track [Page 4] + +RFC 3672 Subentries in LDAP December 2003 + + +2.2. Administrative Role Attribute Type + + The Administrative Model defined in [X.501], clause 10 requires that + administrative entries contain an administrativeRole attribute to + indicate that the associated administrative area is concerned with + one or more administrative roles. + + The administrativeRole operational attribute is specified as follows: + + ( 2.5.18.5 NAME 'administrativeRole' + EQUALITY objectIdentifierMatch + USAGE directoryOperation + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The possible values of this attribute defined in X.501 are: + + OID NAME + -------- ------------------------------- + 2.5.23.1 autonomousArea + 2.5.23.2 accessControlSpecificArea + 2.5.23.3 accessControlInnerArea + 2.5.23.4 subschemaAdminSpecificArea + 2.5.23.5 collectiveAttributeSpecificArea + 2.5.23.6 collectiveAttributeInnerArea + + Other values may be defined in other specifications. Names + associated with each administrative role are Object Identifier + Descriptors [RFC3383]. + + The administrativeRole operational attribute is also used to regulate + the subentries permitted to be subordinate to an administrative + entry. A subentry not of a class permitted by the administrativeRole + attribute cannot be subordinate to the administrative entry. + +2.3. Subtree Specification Attribute Type + + The subtreeSpecification operational attribute is defined as follows: + + ( 2.5.18.6 NAME 'subtreeSpecification' + SINGLE-VALUE + USAGE directoryOperation + SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 ) + + This attribute is present in all subentries. See [X.501], clause 10. + Values of the subtreeSpecification attribute nominate collections of + entries within the DIT for one or more aspects of administrative + authority. + + + + +Zeilenga & Legg Standards Track [Page 5] + +RFC 3672 Subentries in LDAP December 2003 + + +2.4. Subentry Object Class + + The subentry object class is a structural object class. + + ( 2.5.17.0 NAME 'subentry' + SUP top STRUCTURAL + MUST ( cn $ subtreeSpecification ) ) + +3. Subentries Control + + The subentries control MAY be sent with a searchRequest to control + the visibility of entries and subentries which are within scope. + Non-visible entries or subentries are not returned in response to the + request. + + The subentries control is an LDAP Control whose controlType is + 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), + and controlValue contains a BER-encoded BOOLEAN indicating + visibility. A controlValue containing the value TRUE indicates that + subentries are visible and normal entries are not. A controlValue + containing the value FALSE indicates that normal entries are visible + and subentries are not. + + Note that TRUE visibility has the three octet encoding { 01 01 FF } + and FALSE visibility has the three octet encoding { 01 01 00 }. + + The controlValue SHALL NOT be absent. + + In absence of this control, subentries are not visible to singleLevel + and wholeSubtree scope Search requests but are visible to baseObject + scope Search requests. + + There is no corresponding response control. + + This control is not appropriate for non-Search operations. + +4. Security Considerations + + Subentries often hold administrative information or other sensitive + information and should be protected from unauthorized access and + disclosure as described in [RFC2829][RFC2830]. + + General LDAP [RFC3377] security considerations also apply. + + + + + + + + +Zeilenga & Legg Standards Track [Page 6] + +RFC 3672 Subentries in LDAP December 2003 + + +5. IANA Considerations + +5.1. Descriptors + + The IANA has registered the LDAP descriptors detailed in this + technical specification. The following registration template is + suggested: + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): see comment + Object Identifier: see comment + Person & email address to contact for further information: + Kurt Zeilenga + Usage: see comment + Specification: RFC3672 + Author/Change Controller: IESG + Comments: + + NAME Type OID + ------------------------ ---- -------- + accessControlInnerArea R 2.5.23.3 + accessControlSpecificArea R 2.5.23.2 + administrativeRole A 2.5.18.5 + autonomousArea R 2.5.23.1 + collectiveAttributeInnerArea R 2.5.23.6 + collectiveAttributeSpecificArea R 2.5.23.5 + subentry O 2.5.17.0 + subschemaAdminSpecificArea R 2.5.23.4 + subtreeSpecification A 2.5.18.6 + + where Type A is Attribute, Type O is ObjectClass, and Type R is + Administrative Role. + +5.2. Object Identifiers + + This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an + LDAP protocol element defined herein. This OID was assigned [ASSIGN] + by OpenLDAP Foundation, under its IANA-assigned private enterprise + allocation [PRIVATE], for use in this specification. + + Other OIDs which appear in this document were either assigned by the + ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify + elements of X.500 schema or assigned in RFC 2252 for the use + described here. + + + + + + + +Zeilenga & Legg Standards Track [Page 7] + +RFC 3672 Subentries in LDAP December 2003 + + +5.3. Protocol Mechanisms + + The IANA has registered the LDAP protocol mechanisms [RFC3383] + detailed in this specification. + + Subject: Request for LDAP Protocol Mechanism Registration + + Description: Subentries + + Person & email address to contact for further information: + Kurt Zeilenga + + Usage: Control + + Specification: RFC3672 + + Author/Change Controller: IESG + + Comments: none + +6. Acknowledgment + + This document is based on engineering done by IETF LDUP and LDAPext + Working Groups including "LDAP Subentry Schema" by Ed Reed. This + document also borrows from a number of ITU documents including X.501. + +7. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + +Zeilenga & Legg Standards Track [Page 8] + +RFC 3672 Subentries in LDAP December 2003 + + +A. Subtree Specification ABNF + + This appendix is non-normative. + + The LDAP-specific string encoding for the Subtree Specification + syntax is specified by the Generic String Encoding Rules [RFC3641]. + The ABNF [RFC2234] in this appendix for this syntax is provided only + as a convenience and is equivalent to the encoding specified by the + application of [RFC3641]. Since the SubtreeSpecification ASN.1 type + may be extended in future editions of [X.501], the provided ABNF + should be regarded as a snapshot in time. The LDAP-specific encoding + for any extension to the SubtreeSpecification ASN.1 type can be + determined from [RFC3641]. + + In the event that there is a discrepancy between this ABNF and the + encoding determined by [RFC3641], [RFC3641] is to be taken as + definitive. + + SubtreeSpecification = "{" [ sp ss-base ] + [ sep sp ss-specificExclusions ] + [ sep sp ss-minimum ] + [ sep sp ss-maximum ] + [ sep sp ss-specificationFilter ] + sp "}" + + ss-base = id-base msp LocalName + ss-specificExclusions = id-specificExclusions msp + SpecificExclusions + ss-minimum = id-minimum msp BaseDistance + ss-maximum = id-maximum msp BaseDistance + ss-specificationFilter = id-specificationFilter msp Refinement + + id-base = %x62.61.73.65 ; "base" + id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73 + %x69.6F.6E.73 ; "specificExclusions" + id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum" + id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum" + id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46 + %x69.6C.74.65.72 ; "specificationFilter" + + SpecificExclusions = "{" [ sp SpecificExclusion + *( "," sp SpecificExclusion ) ] sp "}" + SpecificExclusion = chopBefore / chopAfter + chopBefore = id-chopBefore ":" LocalName + chopAfter = id-chopAfter ":" LocalName + id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore" + id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter" + + + + +Zeilenga & Legg Standards Track [Page 9] + +RFC 3672 Subentries in LDAP December 2003 + + + Refinement = item / and / or / not + item = id-item ":" OBJECT-IDENTIFIER + and = id-and ":" Refinements + or = id-or ":" Refinements + not = id-not ":" Refinement + Refinements = "{" [ sp Refinement + *( "," sp Refinement ) ] sp "}" + id-item = %x69.74.65.6D ; "item" + id-and = %x61.6E.64 ; "and" + id-or = %x6F.72 ; "or" + id-not = %x6E.6F.74 ; "not" + + BaseDistance = INTEGER-0-MAX + + The , , , , , and rules are defined in [RFC3642]. + +Normative References + + [X.501] ITU-T, "The Directory -- Models," X.501, 1993. + + [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - + Specification of Basic Notation", X.680, 1994. + + [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, + Canonical, and Distinguished Encoding Rules", X.690, + 1994. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + + [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight + Directory Access Protocol (v3): Extension for Transport + Layer Security", RFC 2830, May 2000. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + + +Zeilenga & Legg Standards Track [Page 10] + +RFC 3672 Subentries in LDAP December 2003 + + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", RFC 3383, September 2002. + + [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 + Types", RFC 3641, October 2003. + +Informative References + + [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC3642] Legg, S., "Common Elements of Generic String Encoding + Rules (GSER) Encodings", RFC 3642, October 2003. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers + +Authors' Addresses + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + Steven Legg + Adacel Technologies Ltd. + 250 Bay Street + Brighton, Victoria 3186 + AUSTRALIA + + Phone: +61 3 8530 7710 + Fax: +61 3 8530 7888 + EMail: steven.legg@adacel.com.au + + + + + + + + + + + + + +Zeilenga & Legg Standards Track [Page 11] + +RFC 3672 Subentries in LDAP December 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga & Legg Standards Track [Page 12] + -- 2.39.5