+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 18 August 2002
-
-
- Collective Attributes in LDAP
- <draft-zeilenga-ldap-collective-08.txt>
-
-
-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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <kurt@OpenLDAP.org>
- 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]
-\f
-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
- <Kurt@OpenLDAP.org>
-
-
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 26 May 2003
-
-
- Feature Discovery in LDAP
- <draft-zeilenga-ldap-features-05.txt>
-
-
-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 an 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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an extensible
- protocol with numerous elective features. This document introduces a
- general mechanism for discovery of elective features and extensions
- which cannot be discovered using existing mechanisms.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-features-05 [Page 1]
-\f
-INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
-
-
-1. Background and Intended Use
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
- extensible protocol with numerous elective features. LDAP provides
- mechanisms for a client to discover supported protocol versions,
- controls, extended operations, Simple Authentication and Security
- Layer (SASL) mechanisms, and subschema information. However, these
- mechanisms are not designed to support general feature discovery.
-
- This document describes a simple, general-purpose mechanism which
- clients may use to discover the set of elective features supported by
- a server. For example, this mechanism could be used by a client to
- discover whether or not the server supports requests for all
- operational attributes, e.g. "+" [OPATTRS]. As another example, this
- mechanism could be used to discover absolute true, e.g. "(&)" and
- false, e.g. "(|)", search filters [T-F] support.
-
- This document extends the LDAP Protocol Mechanism registry [RFC3383]
- to support registration of values of the supportedFeatures attribute.
- This registry is managed by the Internet Assigned Numbers Authority
- (IANA).
-
- Schema definitions are provided using LDAP 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. Discovery of supported features
-
- Each elective feature whose support may be discovered SHALL be
- identified by an Object Identifier (OID). A server advertises its
- support for a given feature by providing the OID associated with the
- feature as a value of the 'supportedFeatures' attribute held in the
- root DSE. A client may examine the values of this attribute to
- determine if a particular feature is supported by the server. A
- client MUST ignore values it doesn't recognize as they refer to
- elective features it doesn't implement.
-
- Features associated with Standard Track protocol mechanisms MUST be
- registered. Features associated with other protocol mechanisms SHOULD
- be registered. Procedures for registering protocol mechanisms are are
- described in [RFC3383]. "Feature" should be placed in the usage field
- of the submitted LDAP Protocol Mechanism template.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-features-05 [Page 2]
-\f
-INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
-
-
- The 'supportedFeatures' attribute type is described as follows:
-
- ( 1.3.6.1.4.1.4203.1.3.5
- NAME 'supportedFeatures'
- DESC 'features supported by the server'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- Servers MUST be capable of recognizing this attribute type by the name
- 'supportedFeatures'. Servers MAY recognize the attribute type by
- other names.
-
-
-4. Security Considerations
-
- As rogue clients can discover features of a server by other means
- (such as by trial and error), this feature discovery mechanism is not
- believed to introduce any new security risk to LDAP.
-
-
-5. IANA Considerations
-
-5.1. Registration of Features as Protocol Mechanisms
-
- Future specifications detailing LDAP features are to register each
- feature as a LDAP Protocol Mechanism per guidance given in BCP 64
- [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
- template indicates that the value to be registered is associated with
- an LDAP feature.
-
-
-5.2. Registration of the supportedFeatures descriptor
-
- It is requested that IANA register upon Standards Action the LDAP
- 'supportedFeatures' descriptor. The following registration template
- is suggested:
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): supportedFeatures
- Object Identifier: 1.3.6.1.4.1.4203.1.3.5
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
-
-
-
-Zeilenga draft-zeilenga-ldap-features-05 [Page 3]
-\f
-INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
-
-
- assigned private enterprise allocation [PRIVATE] for use in this
- specification.
-
-
-6. Acknowledgment
-
- This document is based upon input from the IETF LDAPEXT working group.
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-8. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
-
-
-9. Informative References
-
- [OPATTRS] Zeilenga, K., "LDAPv3: All Operational Attributes",
- draft-zeilenga-ldap-opattrs-xx.txt, a work in progress.
-
- [T-F] Zeilenga, K., "LDAP True/False Filters",
- draft-zeilenga-ldap-t-f-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.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-features-05 [Page 4]
-\f
-INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
-
-
-Intellectual Property Rights
-
- 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.
-
-
-
-Full Copyright
-
- 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 implmentation 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.
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-features-05 [Page 5]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 1 November 2002
-
-
-
- LDAPv3: All Operational Attributes
- <draft-zeilenga-ldap-opattrs-05.txt>
-
-
-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 Extensions Working Group
- mailing list <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright 2002, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) supports a mechanism
- for requesting the return of all user attributes but not all
- operational attributes. This document describes an LDAP extension
- which clients may use to request the return of all operational
- attributes.
-
-
-
-Zeilenga LDAP All Op Attrs [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
-
-
-1. Overview
-
- X.500 [X.500] provides a mechanism for clients to request all
- operational attributes be returned with entries provided in response
- to a search operation. This mechanism is often used by clients to
- discover which operational attributes are present in an entry.
-
- This documents extends the Lightweight Directory Access Protocol
- (LDAP) [RFC3377] to provide a simple mechanism which clients may use
- to request the return of all operational attributes. The mechanism is
- designed for use with existing general purpose LDAP clients (including
- web browsers which support LDAP URLs) and existing LDAP APIs.
-
- 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. All Operational Attributes
-
- The presence of the attribute description "+" (ASCII 43) in the list
- of attributes in a Search Request [RFC2251] SHALL signify a request
- for the return of all operational attributes.
-
- As with all search requests, client implementors should note that
- results may not include all requested attributes due to access
- controls or other restrictions. Client implementors should also note
- that certain operational attributes may be returned only if requested
- by name even when "+" is present. This is because some operational
- attributes are very expensive to return.
-
- Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
- [FEATURES] attribute in the root DSE.
-
-
-3. Interoperability Considerations
-
- This mechanism is specifically designed to allow users to request all
- operational attributes using existing LDAP clients. In particular,
- the mechanism is designed to be compatible with existing general
- purpose LDAP clients including those supporting LDAP URLs [RFC2255].
-
- The addition of this mechanism to LDAP is not believed to cause any
- significant interoperability issues (this has been confirmed through
- testing). Servers which have yet to implement this specification
- should ignore the "+" as an unrecognized attribute description per
- [RFC2251, Section 4.5.1]. From the client's perspective, a server
-
-
-
-Zeilenga LDAP All Op Attrs [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
-
-
- which does not return all operational attributes when "+" is requested
- should be viewed as having other restrictions.
-
- It is also noted that this mechanism is believed to require no
- modification of existing LDAP APIs.
-
-
-4. Security Considerations
-
- This document provides a general mechanism which clients may use to
- discover operational attributes. Prior to the introduction of this
- mechanism, operational attributes where only returned when requested
- by name. Some might have viewed this as obscurity" feature. However,
- this sense of security as the attributes were still transferable.
-
- Implementations SHOULD implement appropriate access controls
- mechanisms to restricts access to operational attributes.
-
-
-5. IANA Considerations
-
- This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
- feature described above. This OID was assigned [ASSIGN] by OpenLDAP
- Foundation, under its IANA-assigned private enterprise allocation
- [PRIVATE], for use in this specification.
-
- Registration of this feature is requested [FEATURES][RFC3383].
-
- Subject: Request for LDAP Protocol Mechanism Registration
-
- Object Identifier: 1.3.6.1.4.1.4203.1.5.1
-
- Description: All Op Attrs
-
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
-
- Usage: Feature
-
- Specification: RFCxxxx
-
- Author/Change Controller: IESG
-
- Comments: none
-
-
-6. Acknowledgment
-
-
-
-
-Zeilenga LDAP All Op Attrs [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
-
-
- The "+" mechanism is believed to have been first suggested by Bruce
- Greenblatt in a November 1998 post to the IETF LDAPext Working Group
- mailing list.
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-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.
-
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
- (v3): Technical Specification", RFC 3377, September 2002.
-
- [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
- ldap-features-xx.txt (a work in progress).
-
-
-9. Informative References
-
- [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
- December 1997.
-
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
-
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
- [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.
-
-
-Copyright 2002, The Internet Society. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
-
-
-
-Zeilenga LDAP All Op Attrs [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
-
-
- 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 LDAP All Op Attrs [Page 5]
-\f
+++ /dev/null
-
-
-
-
-
-
-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
- <draft-zeilenga-ldap-subentry-07.txt>
-
-
-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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <kurt@OpenLDAP.org>
- 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]
-\f
-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 <kurt@openldap.org>
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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 <sp>, <msp>, <sep>, <INTEGER>, <OBJECT-IDENTIFIER> and <LocalName>
- 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]
-\f
-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]
-\f
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)
Legend:
STD Standard
FYI For Your Information
BCP Best Common Practice
+Please see http://www.rfc-editor.org/ for up-to-date status information.
+
$OpenLDAP$
--- /dev/null
+
+
+
+
+
+
+Network Working Group A. Newton
+Request for Comments: 3663 VeriSign, Inc.
+Category: Experimental December 2003
+
+
+ Domain Administrative Data
+ in Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ Domain registration data has typically been exposed to the general
+ public via Nicname/Whois for administrative purposes. This document
+ describes the Referral Lightweight Directory Access Protocol (LDAP)
+ Service, an experimental service using LDAP and well-known LDAP types
+ to make domain administrative data available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 1]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Historical Directory Services for Domain Registration
+ Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Motivations. . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.3. Abbreviations Used . . . . . . . . . . . . . . . . . . . 4
+ 2. Service Description. . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 6
+ 3.1.2. Allowed Searches . . . . . . . . . . . . . . . . 7
+ 3.1.3. Access Control . . . . . . . . . . . . . . . . . 7
+ 3.2. Name Server DIT. . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 8
+ 3.2.2. Allowed Searches . . . . . . . . . . . . . . . . 8
+ 3.3. Registrar Referral DIT . . . . . . . . . . . . . . . . . 9
+ 3.3.1. DIT Structure. . . . . . . . . . . . . . . . . . 9
+ 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . 10
+ 4.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 10
+ 4.1.2. Allowed Searches . . . . . . . . . . . . . . . . 11
+ 4.1.3. Access Control . . . . . . . . . . . . . . . . . 11
+ 4.2. Name Server and Contact DIT. . . . . . . . . . . . . . . 12
+ 4.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 12
+ 4.2.2. Allowed Searches . . . . . . . . . . . . . . . . 13
+ 5. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.1. Intra-Server Referrals . . . . . . . . . . . . . . . . . 14
+ 6.2. Inter-Server Referrals . . . . . . . . . . . . . . . . . 15
+ 6.3. Common DIT . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.4. Universal Client . . . . . . . . . . . . . . . . . . . . 16
+ 6.5. Targeting Searches by Tier . . . . . . . . . . . . . . . 16
+ 6.6. Data Mining. . . . . . . . . . . . . . . . . . . . . . . 16
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
+ 8. Internationalization Considerations. . . . . . . . . . . . . . 16
+ 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
+ 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 17
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
+ Appendix A. Other Work. . . . . . . . . . . . . . . . . . . . . . 19
+ Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+Newton Experimental [Page 2]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+1. Introduction
+
+ This document describes the Referral Lightweight Directory Access
+ Protocol (LDAP) Service, an experimental project launched by
+ VeriSign, Inc., to explore the use of LDAP and LDAP-related
+ technologies for use as a directory service of administrative domain
+ registration information.
+
+1.1. Historical Directory Services for Domain Registration Data
+
+ The original National Science Foundation contract for the InterNIC
+ called for the creation of an X.500 directory service for the
+ administrative needs of the domain registration data and information.
+ Due to problems with implementations of X.500 server software, a
+ server based on the Nicname/Whois [1] protocol was temporarily
+ erected.
+
+ In 1994, the Rwhois [3] protocol was introduced to enhance the
+ Nicname/Whois protocol. This directory service never gained wide
+ acceptance for use with domain data.
+
+ Presently, ICANN requires the operation of Nicname/Whois servers by
+ registries and registrars of generic Top-Level Domains (TLD's).
+
+1.2. Motivations
+
+ With the recent split in functional responsibilities between
+ registries and registrars, the constant misuse and data-mining of
+ domain registration data, and the difficulties with machine-
+ readability of Nicname/Whois output, the creation of the Referral
+ LDAP Service had the following motivations:
+
+ o Use a mechanism native to the directory protocol to refer clients
+ from inquiries about specific domains made at a registry to the
+ appropriate domain within the appropriate directory service at a
+ registrar.
+
+ o Limit access to domain data based on authentication of the client.
+
+ o Provide structured queries and well-known and structured results.
+
+ o Use a directory service technology already in general use.
+
+ Given these general criteria, LDAP [5] was selected as the protocol
+ for this directory service. The decision was also made to restrict
+ the use of LDAP to features most readily available in common
+ implementations. Therefore, a goal was set to not define any new
+ object classes, syntaxes, or matching rules.
+
+
+
+Newton Experimental [Page 3]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ The experiment was successful in exploring how LDAP might be used in
+ this context and demonstrating the level of customization required
+ for an operational service. Conclusions and observations about this
+ experiment are outlined in Section 6.
+
+1.3. Abbreviations Used
+
+ The following abbreviations are used to describe the nature of this
+ experiment:
+
+ TLD: Top-Level Domain. Refers to the domain names just beneath
+ the root in the Domain Name System. This experiment used the
+ TLD's .com, .net, .org, and .edu.
+
+ SLD: Second-Level Domain. Refers to the domain names just beneath
+ a TLD in the Domain Name System. An example of such a domain name
+ would be "example.com".
+
+ DIT: Directory Information Tree. One of many hierarchies of data
+ entries in an LDAP server.
+
+ DN: Distinguished Name. The unique name of an entry in a DIT.
+
+ cn: common name. See RFC 2256 [7].
+
+ dc: domain component. See RFC 2247 [4].
+
+ uid: user id. See RFC 2798 [9].
+
+2. Service Description
+
+ The service is composed of three distinct server types: a registry
+ LDAP server, registrar LDAP servers, and registrant LDAP servers.
+
+ The registry LDAP server contains three Directory Information Trees
+ (DIT's).
+
+ o The Top-Level Domain DIT's follow the DNS hierarchy for domains
+ (e.g., dc=foo,dc=com).
+
+ o The name server DIT allows a view of the name servers, many of
+ which serve multiple domains.
+
+ o The registrar-referral DIT provides referrals from the registry
+ into the respective TLD DIT of the registrars (on a TLD basis).
+
+
+
+
+
+
+Newton Experimental [Page 4]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ The registrar LDAP server contains two types of DIT's.
+
+ o The TLD DIT follows the DNS hierarchy for domains (e.g.,
+ dc=foo,dc=com) and parallels the TLD DIT of the registry.
+
+ o The name server and contact DIT allow a view of the name servers
+ and contacts, many of which are associated and serve multiple
+ domains.
+
+ There is no specification on the DIT or schema for the registrant
+ LDAP server. Referrals from the registrar server to the registrant
+ server are provided solely for the purpose of allowing the registrant
+ direct control over extra administrative information as it relates to
+ a particular domain.
+
+ Access control for this service is merely a demonstration of using a
+ Distinguished Name (DN) and password. Should registries and
+ registrars uniformly adopt LDAP as a means to disseminate domain
+ registration data, standardization of these DN's would need to be
+ undertaken based on each type of user base.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 5]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+3. Registry LDAP Service
+
+3.1. TLD DIT
+
+3.1.1. DIT Structure
+
+ The registry TLD DIT has the following structural hierarchy:
+
+ TLD (e.g., dc=net)
+ |
+ |
+ -------------------------------------
+ | |
+ SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net)
+ | |
+ --------------------- ---------------------
+ | | | | | |
+ name server | | name server | |
+ (e.g., | | (e.g., | |
+ cn=nameserver1, | | cn=nameserver1, | |
+ dc=foo,dc=net ) | | dc=bar,dc=net ) | |
+ | | | |
+ name server | name server |
+ (e.g., | (e.g., |
+ cn=nameserver2, | cn=nameserver2, |
+ dc=foo,dc=net ) | dc=bar,dc=net ) |
+ | |
+ registrar referral registrar referral
+ (e.g., (e.g.,
+ cn=registrar, cn=registrar,
+ dc=foo,dc=net ) dc=bar,dc=net )
+
+
+ Figure 1: Registry DIT Overview
+
+ The root of a TLD DIT is an entry of objectclass domain as specified
+ by RFC 2247 [4] and represents a top-level domain.
+
+ The second tier of the DIT represents second-level domains. Each of
+ these entries is of objectclass domain as specified by RFC 2247 [4].
+ The description attribute on these entries often contains descriptive
+ text giving the name of the registrar through which these domains
+ have been registered.
+
+ The third tier contains entries specific to each second-level domain.
+ Name server entries are of objectclass ipHost as specified by RFC
+ 2307 [8]. The distinguished names of these name server entries are
+ algorithmically calculated, where the first component is the word
+
+
+
+Newton Experimental [Page 6]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ "nameserver" concatenated with an index number of the name server
+ entry and the remaining components are the appropriate domain names.
+ There is no specification relating the value of the name server entry
+ to the index it may be assigned other than it is unique and
+ consistent with respect to the client session. This tier also
+ contains the referral from the registry to the registrar. This
+ referral is a direct referral to the entry in the appropriate
+ registrar LDAP server corresponding to the domain name that the
+ referral falls beneath in this DIT.
+
+3.1.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to expensive searches that would be
+ far too costly for a publicly available service. The searches
+ allowed are as follows:
+
+ o One-level scoped searches based at the root of the DIT. Substring
+ matching is allowed on dc attributes, but the substring must be at
+ least be 3 characters in length.
+
+ o Base search based at the root of the DIT.
+
+ o Base, one-level, and sub-tree searches based at any second level
+ domain name (the second tier) and below.
+
+3.1.3. Access Control
+
+ The registry TLD DIT only has one access control type. When a client
+ binds with a DN of "cn=trademark" and password of "attorney", the
+ second-level domain entries also take on an objectclass of
+ extensibleObject with the added attributes of "createddate" and
+ "registrationexpirationdate", which are of type Generalized Time, as
+ specified by RFC 2252 [6].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 7]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+3.2. Name Server DIT
+
+3.2.1. DIT Structure
+
+ The registry name server DIT has the following structural hierarchy:
+
+ (o=nsiregistry.com)
+ |
+ |
+ -------------------------------------
+ | | |
+ name server name server name server
+ (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
+
+
+ Figure 2: Registry DIT Overview
+
+ The root of a name server DIT is an entry of objectclass organization
+ as specified by RFC 1617 [2]. It has no significance other than to
+ serve as the root of the DIT.
+
+ The second tier of this DIT represents name servers. Each of these
+ entries is of objectclass ipHost, as specified by RFC 2307 [8].
+
+3.2.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to searches far too costly for a
+ publicly available service. The searches allowed are as follows:
+
+ o One-level and sub-tree scoped searches based at the root of the
+ DIT if a filter on the cn attribute is provided.
+
+ o Base search based at the root of the DIT.
+
+ o Base, one-level, and sub-tree searches based at any name server
+ entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 8]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+3.3. Registrar Referral DIT
+
+3.3.1. DIT Structure
+
+ The registry registrar-referral DIT has the following structural
+ hierarchy:
+
+ (o=tlds)
+ |
+ |
+ -------------------------------
+ | | | |
+ tld tld tld tld
+ (dc=net) (dc=com) (dc=org) (dc=edu)
+ | | | |
+ : : | :
+ : : | :
+ |
+ ---------------------------
+ | | |
+ referral to referral to referral to
+ registrar 1 registrar 2 registrar n
+ dc=org DIT dc=org DIT dc=org DIT
+
+
+ Figure 3: Registry Referral DIT Overview
+
+ The root of the registrar referral DIT is an entry of objectclass
+ organization, as specified by RFC 1617 [2]. It has no significance
+ other than to serve as the root of this DIT.
+
+ The second tier of this DIT represents top-level domains. Each of
+ these entries is of objectclass domain, as specified by RFC 2247 [4].
+
+ Underneath each TLD entry, the third tier contains referrals to the
+ appropriate TLD DIT of each registrar.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 9]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+4. Registrar LDAP Service
+
+4.1. TLD DIT
+
+4.1.1. DIT Structure
+
+ The registrar TLD DIT, which is similar to the registry TLD DIT, has
+ the following structural hierarchy:
+
+ TLD (e.g., dc=net)
+ |
+ |
+ ------------------------------------------------
+ | | |
+ SLD (e.g., dc=foo,dc=net) : :
+ | : :
+ ---------------------------------------------
+ | | |
+ | | |
+ name server contact referral to
+ (e.g., cn=nameserver1, (e.g., cn=contact1, registrant
+ dc=foo,dc=net ) dc=foo,dc=net )
+ |
+ |
+ name server contact
+ (e.g., cn=contact,
+ cn=nameserver1,
+ dc=foo,dc=net )
+
+ Figure 4: Registrar DIT Overview
+
+ The root of a TLD DIT is an entry of objectclass domain, as specified
+ by RFC 2247 [4] and represents a top-level domain.
+
+ The second tier of the DIT represents second-level domains. Each of
+ these entries is of objectclass domain, as specified by RFC 2247 [4].
+
+ The third tier contains entries specific to each second-level domain.
+ The entries at this level are as follows:
+
+ o Name server entries are of objectclass ipHost, as specified by RFC
+ 2307 [8]. The distinguished names of these name server entries
+ are algorithmically calculated where the first component is the
+ word "nameserver" concatenated with an index number of the name
+ server entry and the remaining components are the appropriate
+ domain names. There is no specification relating the value of the
+ name server entry to the index it may be assigned other than it is
+ unique and consistent with respect to the client session.
+
+
+
+Newton Experimental [Page 10]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ o Contact entries are of objectclass inetOrgPerson, as specified by
+ RFC 2798 [9]. The distinguished names of these contact entries
+ are algorithmically calculated, where the first component is the
+ word "contact" concatenated with an index number of the contact
+ and the remaining components are the appropriate domain names.
+ There is no specification relating the value of the contact entry
+ to the index it may be assigned other than it is unique and
+ consistent with respect to the client session. The description
+ attribute of the entry contains the role for which a contact is
+ related to a domain. These roles are identified as "Admin
+ Contact", "Technical Contact", and "Billing Contact", and may
+ appear in any order.
+
+ o Finally, this third tier contains the referral from the registrar
+ to the registrant.
+
+ The fourth tier only contains name server contact entries. These
+ entries are of objectclass inetOrgPerson, as specified by RFC 2798
+ [9].
+
+4.1.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to searches far too costly for a
+ publicly available service. The searches allowed are as follows:
+
+ o One-level scoped searches based at the root of the DIT. Substring
+ matching is allowed on dc and o attributes, but the substring must
+ be at least 3 characters in length.
+
+ o Base search based at the root of the DIT.
+
+ o Base, one-level, and sub-tree searches based at any second level
+ domain name (the second tier) and below.
+
+4.1.3. Access Control
+
+ The registrar TLD DIT has two access control types. When binding
+ anonymously, a client only sees dc, o, and c attributes of the
+ second-level domain entries. When a client binds with a DN of
+ "cn=trademark" and password of "attorney", all of the other
+ attributes normally available on entries of objectclass domain are
+ visible if they have values. In addition, if a client binds with the
+ DN of a contact and password of "password", all attributes for
+ second-level domain entries for which the bind DN has a relation are
+ visible.
+
+
+
+
+Newton Experimental [Page 11]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+4.2. Name Server and Contact DIT
+
+4.2.1. DIT Structure
+
+ The registrar name server and contact DIT has the following
+ structural hierarchy:
+
+ (o=nsi.com)
+ |
+ |
+ --------------------------------------
+ | |
+ Contacts Name Servers
+ (ou=contacts) (ou=name servers)
+ | |
+ ----------------- ------------------------
+ | | | | | |
+ Contact : : Name Server : :
+ (uid=handle) : : (cn=handle) : :
+ |
+ Name Server
+ Contact
+ (cn=contact1)
+
+ Figure 5: Registrar DIT Overview
+
+ The first tier of the name server and contact DIT is an entry of
+ objectclass organization, as specified by RFC 1617 [2].
+
+ The second tier of the DIT contains two entries, each of which is of
+ objectclass organizationalUnit, as specified by RFC 2256 [7]. One
+ entry represents the part of the DIT containing contacts and the
+ other entry represents the part of the DIT containing name servers.
+
+ Entries underneath the contacts organizationalUnit entry are of
+ objectclass inetOrgPerson and represent contacts registered with the
+ registrar. Their RDN is composed of the uid attribute. The uid
+ attribute's value is a unique identifier or handle that is registrar
+ assigned.
+
+ Entries underneath the name server organizationalUnit entry are of
+ objectclass ipHost and represent name servers registered with the
+ registrar. Their RDN is composed of the cn attribute. The cn
+ attribute's value is a unique identifier or handle that is registrar
+ assigned. Each name server entry may optionally have children
+ entries of objectclass inetOrgPerson. These entries represent the
+ contacts of the name server they fall beneath.
+
+
+
+
+Newton Experimental [Page 12]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+4.2.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to searches far too costly for a
+ publicly available service. The searches allowed are as follows:
+
+ o One-level and base searches at the root of the DIT.
+
+ o Sub-tree searches at the root of the DIT using cn and uid
+ attributes as a filter.
+
+ o Base searches at either entry of the second tier.
+
+ o One-level and sub-tree searches at either entry of the second
+ tier, using cn or uid attributes as a filter.
+
+ o Base, one-level, and sub-tree searches based at any contact or
+ name server entry and below.
+
+5. Clients
+
+ Early scoping and analysis of this project were based on the use of
+ output from command line clients, specifically the "ldapsearch"
+ command present with many implementations of LDAP servers. Our
+ survey of this tool, available from many vendors, showed that
+ referral chasing was difficult to control or predict, and the
+ behavior between these implementations with respect to referral
+ chasing was inconsistent.
+
+ Based on the limited nature of the expressive capabilities present
+ with just command line tools, searches involving nested queries or
+ advanced referral chasing were deemed the domain of clients making
+ direct use of LDAP client libraries. Three of these types of clients
+ were produced: a web-based client, a cross-platform C-based client,
+ and a Java client. No significant deficiencies or problems were
+ found with the LDAP client libraries in the construction of these
+ clients, and the level of control provided by their programming
+ interfaces was adequate to create the necessary searches. Instead,
+ most of the problems encountered with these clients were based on
+ usability concerns.
+
+ It was found that the web-based client caused a great amount of
+ confusion for users not familiar with LDAP or Nicname/Whois with
+ respect to the underlying technology and the network model. Thus,
+ many users believed the web-based client to be the only interface to
+ the data and were unaware or confused by the intermediate LDAP
+ protocol. In addition, it was difficult to express to users the
+
+
+
+Newton Experimental [Page 13]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ registry-registrar-registrant service model in adequate terms from
+ search results where the results could be rendered properly among the
+ various common web browsers.
+
+ Both the C and Java based clients were built to be both graphical and
+ cross-platform (in the case of the C-based client, the Linux and
+ Windows platforms were chosen as targets). The LDAP client libraries
+ chosen for both clients proved to be quite capable and offered the
+ necessary levels of control for conducting nested queries and
+ advanced referral chasing. Expectations at the outset for
+ construction of both clients, based on past experience, were that the
+ C-based client would not only perform better than the Java client but
+ also have a better appearance. In reality, these assumptions were
+ incorrect as there was no perceivable difference in performance and
+ the look of the Java client was often considered to be far superior
+ to its counter-part. In addition, the Java client required much less
+ time to create. Both clients are available under the terms of an
+ open source license. Though it is impossible to have accurate
+ measurements of their popularity, through monitoring and feedback it
+ was perceived that the web-based client had far greater use.
+
+6. Lessons Learned
+
+ Based on the experience of piloting this experimental service,
+ feedback from users of the service, and general comments and
+ observations of current and common opinions, the following items have
+ been noted.
+
+6.1. Intra-Server Referrals
+
+ Original analysis of the data set to be used revealed a high degree
+ of relationships between name servers, contacts, and domains.
+ Storing the data in non-normalized form according to the DIT outlined
+ in this document would make an original relational dataset of roughly
+ 20 million objects explode to over 115 million objects.
+
+ To combat this problem, the first pass at defining the DIT's made
+ heavy use of referrals between the TLD DIT's and the name server and
+ contact DIT's. The use of the 'alias' objectclass was considered but
+ ruled out in hopes of using referrals for load balancing across
+ servers (i.e., placing each TLD DIT on a separate server, and
+ separate servers for the name server and contact DIT's). However,
+ initial testing with the 'ldapsearch' command found inconsistencies
+ with the interpretation of the referrals and how they were managed.
+ Not only were the results inconsistent between implementations, but
+ many of these clients would easily get caught in referral loops.
+
+
+
+
+
+Newton Experimental [Page 14]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ The final solution to the problem was to create a customized back-end
+ data store containing the data in a normalized form. This gave the
+ client the appearance of having a non-normalized data set which
+ required no intra-server referrals. Aliases may have been a better
+ solution, however our interpretation of their output with
+ implementations of the 'ldapsearch' tool was not satisfactory. It
+ was also later learned that some LDAP server implementations place
+ certain restrictions on aliases that would have conflicted with our
+ overall DIT structure. In the end, it was felt that a customized
+ back-end would be required by any server with a large data-set, but
+ smaller data-sets for less populated domains could easily use off-
+ the-shelf implementations.
+
+6.2. Inter-Server Referrals
+
+ The modeling of the overall service to provide the split in
+ operational responsibility between registry and registrar required
+ the use of referrals (i.e., the two servers would not be operated by
+ the same organization, therefore would most likely not co-exist on
+ the same physical machine or network). The chief problem with LDAP
+ referrals returned for this purpose grew out of the need to limit
+ data returned to the client and the priority given to referrals. It
+ was quite easy to cause a sub-tree query at certain levels, for
+ instance a TLD level, to return nothing but referrals. This was true
+ because referrals would be returned out of the scope of the supplied
+ search filter and therefore would fill the result set to its limit,
+ normally set to 50 entries.
+
+ In certain use cases, a result set with nothing but referrals was
+ desired (e.g., o=tlds). However, even in these cases it was possible
+ for some referrals to not be returned due to the size limit. In this
+ case, it was felt that a result set of 50 referrals, the default for
+ the size limit in most cases, was too large for any practical use by
+ a client and was a failing of query distribution in general rather
+ than a limitation of LDAP.
+
+6.3. Common DIT
+
+ Because of the nature of software development, the graphical and web
+ clients were developed after the development of the server software.
+ The 'ldapsearch' client was used for testing and development during
+ server software creation. It was not until the creation of more
+ advanced clients that it was discovered that the design decision of
+ uniform DIT naming should have been made. Technically, this would
+ have allowed for slightly better software modularization and re-use.
+ In addition, the use of a company name in the DIT structure did not
+ allow the easy integration of another domain registry, as in the
+ registry-registrar model. Not only would clients have to be
+
+
+
+Newton Experimental [Page 15]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ reconfigured for each new registry operator, but this would most
+ likely have social implications as well.
+
+6.4. Universal Client
+
+ The construction of the clients revealed yet another misconception.
+ Though this project used a generic directory service technology, the
+ clients required a high-degree of algorithmic knowledge about the DIT
+ structure and schemas being used. The graphical clients could not be
+ used against an LDAP service with another DIT or schema. Therefore,
+ a generic or universal client, one that could be used for all LDAP
+ applications, would either not be able to make full use of the data
+ provided by the service or would be far too complex for operation by
+ the average user.
+
+6.5. Targeting Searches by Tier
+
+ The network model for this service was divided into three tiers:
+ registry, registrar, and registrant. Despite this, all searches
+ needed to start at the registry level causing overhead for searches
+ that could be targeted at a select tier. This service did not
+ implement a solution to this problem, such as using SRV and/or NAPTR
+ records in DNS to allow a client to find a responsible LDAP server.
+
+6.6. Data Mining
+
+ Section 3.1.2 and Section 4.1.2 describe the searches allowed by this
+ service. However, the most common question asked by users of the
+ service revolved around getting around these restrictions. Because
+ browsing at the TLD level was not permitted, many users asked about
+ the feasibility of using recursive dictionary queries to circumvent
+ the search restrictions.
+
+ It should be noted that many operators of Nicname/Whois server
+ consider this practice to be data mining and often refer to it
+ specifically as a dictionary attack.
+
+7. IANA Considerations
+
+ There are no applicable IANA considerations presented in this
+ document.
+
+8. Internationalization Considerations
+
+ The domain administrative data in this service did not cover
+ Internationalized Domain Names (IDN's).
+
+
+
+
+
+Newton Experimental [Page 16]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+9. Security Considerations
+
+ This experiment did not endeavor to use security mechanisms beyond
+ those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3
+ describe the various access controls used within the scope of the
+ defined security mechanisms. While these mechanisms were adequate
+ for this experimental deployment, they would not be adequate for a
+ production environment, and they should not be taken as a model for
+ those contemplating deployment on the Internet.
+
+10. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 17]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+11. Normative References
+
+ [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
+ 954, October 1985.
+
+ [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and
+ Structuring Guidelines for X.500 Directory Pilots", RFC 1617,
+ May 1994.
+
+ [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
+ Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
+ June 1997.
+
+ [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
+ "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+ January 1998.
+
+ [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [8] Howard, L., "An Approach for Using LDAP as a Network Information
+ Service", RFC 2307, March 1998.
+
+ [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
+ RFC 2798, April 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 18]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Appendix A. Other Work
+
+ In addition to the deployment of servers and development of clients,
+ VeriSign conducted two sub-projects related to this experiment.
+
+ The first project was a Nicname/Whois-to-LDAP gateway. The goal of
+ the project was to create an LDAP server for use by registrars to
+ deploy in front of their Nicname/Whois servers. This gateway would
+ take LDAP requests, translate them to Nicname/Whois requests, issue
+ the request to a specific Nicname/Whois server deployed on port 43,
+ interpret the response, and return LDAP result sets. Because of the
+ unspecified nature of Nicname/Whois result sets, the gateway was
+ programmed to specifically recognize only the output of three
+ distinct registrars. While this gateway proved valuable enough to
+ allow domain lookups and limited searches, it was unable to provide
+ consistent contact lookups, nameserver lookups, or registrant
+ referrals. This software was also made publicly available under the
+ terms of an open source license.
+
+ The second project was an informal survey of registrants with
+ deployed LDAP servers. This was conducted by using the com, net,
+ org, and edu zone files and testing for the existence of an LDAP
+ server on port 389 using the name of the domain, a host named "ldap"
+ in the domain, and a host named "dir" in the domain (e.g., "foo.com",
+ "ldap.foo.com", and "dir.foo.com"). This survey did not attempt to
+ resolve LDAP services using SRV records in DNS.
+
+ The result of this survey found that roughly 0.5% of active domains
+ had an LDAP server. By profiling a server's root DSA-specific Entry
+ (DSE), the survey found that about 90% of the servers were
+ implementations provided by vendor A, 9% of the servers were
+ implementations provided by vendor B, and 1% of the servers were
+ implementations provided by other vendors. Of the servers queried
+ that were determined to be implementations provided by vendor A, it
+ appeared that about only 10% contained public data (this also led to
+ the assumption that the other 90% were not intended to be publicly
+ queried). Of the servers queried that were determined to be
+ implementations provided by vendor B, it appears that nearly all
+ contained public data.
+
+Appendix B. Acknowledgments
+
+ Significant analysis, design, and implementation for this project
+ were conducted by Brad McMillen, David Blacka, Anna Zhang, and
+ Michael Schiraldi. Mark Kosters and Leslie Daigle provided guidance
+ by reviewing this project, the project's goals, and this document.
+
+
+
+
+
+Newton Experimental [Page 19]
+\f
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Author's Address
+
+ Andrew Newton
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Sterling, VA 20166
+ USA
+
+ Phone: +1 703 948 3382
+ EMail: anewton@verisignlabs.com; anewton@ecotroph.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 20]
+\f
+RFC 3663 Domain Administrative Data 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 21]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <kurt@OpenLDAP.org>
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <kurt@OpenLDAP.org>
+ 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]
+\f
+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 <kurt@openldap.org>
+
+ 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]
+\f
+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]
+\f
+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 <sp>, <msp>, <sep>, <INTEGER>, <INTEGER-0-MAX>, <OBJECT-
+ IDENTIFIER> and <LocalName> 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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3673 OpenLDAP Foundation
+Category: Standards Track December 2003
+
+
+ Lightweight Directory Access Protocol version 3 (LDAPv3):
+ All Operational Attributes
+
+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
+
+ The Lightweight Directory Access Protocol (LDAP) supports a mechanism
+ for requesting the return of all user attributes but not all
+ operational attributes. This document describes an LDAP extension
+ which clients may use to request the return of all operational
+ attributes.
+
+1. Overview
+
+ X.500 [X.500] provides a mechanism for clients to request all
+ operational attributes be returned with entries provided in response
+ to a search operation. This mechanism is often used by clients to
+ discover which operational attributes are present in an entry.
+
+ This documents extends the Lightweight Directory Access Protocol
+ (LDAP) [RFC3377] to provide a simple mechanism which clients may use
+ to request the return of all operational attributes. The mechanism
+ is designed for use with existing general purpose LDAP clients
+ (including web browsers which support LDAP URLs) and existing LDAP
+ APIs.
+
+ 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].
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+2. All Operational Attributes
+
+ The presence of the attribute description "+" (ASCII 43) in the list
+ of attributes in a Search Request [RFC2251] SHALL signify a request
+ for the return of all operational attributes.
+
+ As with all search requests, client implementors should note that
+ results may not include all requested attributes due to access
+ controls or other restrictions. Client implementors should also note
+ that certain operational attributes may be returned only if requested
+ by name even when "+" is present. This is because some operational
+ attributes are very expensive to return.
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
+ [RFC3674] attribute in the root DSE.
+
+3. Interoperability Considerations
+
+ This mechanism is specifically designed to allow users to request all
+ operational attributes using existing LDAP clients. In particular,
+ the mechanism is designed to be compatible with existing general
+ purpose LDAP clients including those supporting LDAP URLs [RFC2255].
+
+ The addition of this mechanism to LDAP is not believed to cause any
+ significant interoperability issues (this has been confirmed through
+ testing). Servers which have yet to implement this specification
+ should ignore the "+" as an unrecognized attribute description per
+ [RFC2251, Section 4.5.1]. From the client's perspective, a server
+ which does not return all operational attributes when "+" is
+ requested should be viewed as having other restrictions.
+
+ It is also noted that this mechanism is believed to require no
+ modification of existing LDAP APIs.
+
+4. Security Considerations
+
+ This document provides a general mechanism which clients may use to
+ discover operational attributes. Prior to the introduction of this
+ mechanism, operational attributes were only returned when requested
+ by name. Some might have viewed this as obscurity feature. However,
+ this feature offers a false sense of security as the attributes were
+ still transferable.
+
+ Implementations SHOULD implement appropriate access controls
+ mechanisms to restricts access to operational attributes.
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+5. IANA Considerations
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
+ feature described above. This OID was assigned [ASSIGN] by OpenLDAP
+ Foundation, under its IANA-assigned private enterprise allocation
+ [PRIVATE], for use in this specification.
+
+ Registration of this feature has been completed by IANA [RFC3674],
+ [RFC3383].
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.1
+
+ Description: All Op Attrs
+
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+
+ Usage: Feature
+
+ Specification: RFC3673
+
+ Author/Change Controller: IESG
+
+ Comments: none
+
+6. Acknowledgment
+
+ The "+" mechanism is believed to have been first suggested by Bruce
+ Greenblatt in a November 1998 post to the IETF LDAPext Working Group
+ mailing list.
+
+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.
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+ 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.
+
+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.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory
+ Access Protocol (LDAP)", RFC 3674, December 2003.
+
+8.2. Informative References
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [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.
+
+9. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 3673 LDAPv3: All Operational Attributes 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 5]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3674 OpenLDAP Foundation
+Category: Standards Track December 2003
+
+
+ Feature Discovery in 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
+
+ The Lightweight Directory Access Protocol (LDAP) is an extensible
+ protocol with numerous elective features. This document introduces a
+ general mechanism for discovery of elective features and extensions
+ which cannot be discovered using existing mechanisms.
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
+ extensible protocol with numerous elective features. LDAP provides
+ mechanisms for a client to discover supported protocol versions,
+ controls, extended operations, Simple Authentication and Security
+ Layer (SASL) mechanisms, and subschema information. However, these
+ mechanisms are not designed to support general feature discovery.
+
+ This document describes a simple, general-purpose mechanism which
+ clients may use to discover the set of elective features supported by
+ a server. For example, this mechanism could be used by a client to
+ discover whether or not the server supports requests for all
+ operational attributes, e.g., "+" [RFC3673]. As another example,
+ this mechanism could be used to discover absolute true, e.g., "(&)"
+ and false, e.g., "(|)", search filters [T-F] support.
+
+ This document extends the LDAP Protocol Mechanism registry [RFC3383]
+ to support registration of values of the supportedFeatures attribute.
+ This registry is managed by the Internet Assigned Numbers Authority
+ (IANA).
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+ Schema definitions are provided using LDAP 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. Discovery of supported features
+
+ Each elective feature whose support may be discovered SHALL be
+ identified by an Object Identifier (OID). A server advertises its
+ support for a given feature by providing the OID associated with the
+ feature as a value of the 'supportedFeatures' attribute held in the
+ root DSE. A client may examine the values of this attribute to
+ determine if a particular feature is supported by the server. A
+ client MUST ignore values it doesn't recognize as they refer to
+ elective features it doesn't implement.
+
+ Features associated with Standard Track protocol mechanisms MUST be
+ registered. Features associated with other protocol mechanisms
+ SHOULD be registered. Procedures for registering protocol mechanisms
+ are described in BCP 64 [RFC3383]. The word "Feature" should be
+ placed in the usage field of the submitted LDAP Protocol Mechanism
+ template.
+
+ The 'supportedFeatures' attribute type is described as follows:
+
+ ( 1.3.6.1.4.1.4203.1.3.5
+ NAME 'supportedFeatures'
+ DESC 'features supported by the server'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Servers MUST be capable of recognizing this attribute type by the
+ name 'supportedFeatures'. Servers MAY recognize the attribute type
+ by other names.
+
+3. Security Considerations
+
+ As rogue clients can discover features of a server by other means
+ (such as by trial and error), this feature discovery mechanism is not
+ believed to introduce any new security risk to LDAP.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+4. IANA Considerations
+
+4.1. Registration of Features as Protocol Mechanisms
+
+ Future specifications detailing LDAP features are to register each
+ feature as a LDAP Protocol Mechanism per guidance given in BCP 64
+ [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
+ template indicates that the value to be registered is associated with
+ an LDAP feature.
+
+4.2. Registration of the supportedFeatures descriptor
+
+ The IANA has registered the LDAP 'supportedFeatures' descriptor. The
+ following registration template is suggested:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): supportedFeatures
+ Object Identifier: 1.3.6.1.4.1.4203.1.3.5
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFC 3674
+ Author/Change Controller: IESG
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
+ assigned private enterprise allocation [PRIVATE] for use in this
+ specification.
+
+5. Acknowledgment
+
+ This document is based upon input from the IETF LDAPEXT working
+ group.
+
+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.
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+ 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. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+7.2. Informative References
+
+ [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 3 (LDAPv3): All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [T-F] Zeilenga, K., "LDAP True/False Filters", 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.
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+9. 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 5]
+\f
projects / openldap / commitdiff