mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-03-31 14:50:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

Collective Attributes and Subentries are now RFCs.

Browse Source
This commit is contained in:
Kurt Zeilenga 2003-12-29 18:40:10 +00:00
parent 3994dc645a
commit 6776a17bee
5 changed files with 1240 additions and 1182 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

507
doc/drafts/draft-zeilenga-ldap-collective-xx.txt
View File

@ -1,507 +0,0 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 18 August 2002
Collective Attributes in LDAP
<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]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
Conventions
Schema definitions are provided using LDAPv3 description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Introduction
In X.500, a collective attribute is "a user attribute whose values are
the same for each member of an entry collection" [X.501]. This
document details their use in the Lightweight Directory Access
Protocol (LDAP) [LDAPTS].
1.1. Entry Collections
A collection of entries is a grouping of object and alias entries
based upon common properties or shared relationship between the
corresponding entries which share certain attributes. An entry
collection consists of all entries within scope of a collective
attributes subentry [SUBENTRY]. An entry can belong to several entry
collections.
1.2. Collective Attributes
Attributes shared by the entries comprising an entry collection are
called collective attributes. Values of collective attributes are
visible but not updateable to clients accessing entries within the
collection. Collective attributes are updated (i.e. modified) via
their associated collective attributes subentry.
When an entry belongs to multiple entry collections, the entry's
values of each collective attribute are combined such that independent
sources of these values are not manifested to clients.
Entries can specifically exclude a particular collective attribute by
listing the attribute as a value of the collectiveExclusions
attribute. Like other user attributes, collective attributes are
subject to a variety of controls including access, administrative, and
content controls.
Zeilenga draft-zeilenga-ldap-collective-08 [Page 2]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
2. System Schema for Collective Attributes
The following operational attributes are used to manage Collective
Attributes. LDAP servers [LDAPTS] MUST act in accordance with the
X.500 Directory Models [X.501] when providing this service.
2.1. collectiveAttributeSubentry
Subentries of this object class are used to administer collective
attributes and are referred to as collective attribute subentries.
( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
A collective attribute subentry SHOULD contain at least one collective
attribute. The collective attributes contained within a collective
attribute subentry are available for finding, searching, and
comparison at every entry within the scope of the subentry. The
collective attributes, however, are administered (e.g. modified) via
the subentry.
Implementations of this specification SHOULD support collective
attribute subentries in both collectiveAttributeSpecificArea
(2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative
areas [SUBENTRY][X.501].
2.2. collectiveAttributeSubentries
The collectiveAttributeSubentries operational attribute identifies all
collective attribute subentries that affect the entry.
( 2.5.18.12 NAME 'collectiveAttributeSubentries'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE directoryOperation NO-USER-MODIFICATION )
2.3. collectiveExclusions
The collectiveExclusions operational attribute allows particular
collective attributes to be excluded from an entry. It MAY appear in
any entry and MAY have multiple values.
( 2.5.18.7 NAME 'collectiveExclusions'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE directoryOperation )
Zeilenga draft-zeilenga-ldap-collective-08 [Page 3]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
The descriptor excludeAllCollectiveAttributes is associated with the
OID 2.5.18.0. When this descriptor or OID is present as a value of
the collectiveExclusions attribute, all collective attributes are
excluded from an entry.
3. Collective Attribute Types
A userApplications attribute type can be defined to be COLLECTIVE
[RFC2252]. This indicates that the same attribute values will appear
in the entries of an entry collection subject to the use of the
collectiveExclusions attribute and other administrative controls.
These administrative controls MAY include DIT Content Rules, if
implemented.
Collective attribute types are commonly defined as subtypes of non-
collective attribute types. By convention, collective attributes are
named by prefixing the name of their non-collective supertype with
"c-". For example, the collective telephone attribute is named
c-TelephoneNumber after its non-collective supertype telephoneNumber.
Non-collective attributes types SHALL NOT subtype collective
attributes.
Collective attributes SHALL NOT be SINGLE-VALUED. Collective
attribute types SHALL NOT appear in the attribute types of an object
class definition.
Operational attributes SHALL NOT be defined to be collective.
The remainder of section provides a summary of collective attributes
derived from those defined in [X.520]. The SUPerior attribute types
are described in [RFC 2256] for use with LDAP.
Implementations of this specification SHOULD support the following
collective attributes and MAY support additional collective
attributes.
3.1. Collective Locality Name
The c-l attribute type specifies a locality name for a collection of
entries.
( 2.5.4.7.1 NAME 'c-l'
SUP l COLLECTIVE )
Zeilenga draft-zeilenga-ldap-collective-08 [Page 4]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
3.2. Collective State or Province Name
The c-st attribute type specifies a state or province name for a
collection of entries.
( 2.5.4.8.1 NAME 'c-st'
SUP st COLLECTIVE )
3.3. Collective Street Address
The c-street attribute type specifies a street address for a
collection of entries.
( 2.5.4.9.1 NAME 'c-street'
SUP street COLLECTIVE )
3.4. Collective Organization Name
The c-o attribute type specifies an organization name for a collection
of entries.
( 2.5.4.10.1 NAME 'c-o'
SUP o COLLECTIVE )
3.5. Collective Organizational Unit Name
The c-ou attribute type specifies an organizational unit name for a
collection of entries.
( 2.5.4.11.1 NAME 'c-ou'
SUP ou COLLECTIVE )
3.6. Collective Postal Address
The c-PostalAddress attribute type specifies a postal address for a
collection of entries.
( 2.5.4.16.1 NAME 'c-PostalAddress'
SUP postalAddress COLLECTIVE )
3.7. Collective Postal Code
The c-PostalCode attribute type specifies a postal code for a
Zeilenga draft-zeilenga-ldap-collective-08 [Page 5]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
collection of entries.
( 2.5.4.17.1 NAME 'c-PostalCode'
SUP postalCode COLLECTIVE )
3.8. Collective Post Office Box
The c-PostOfficeBox attribute type specifies a post office box for a
collection of entries.
( 2.5.4.18.1 NAME 'c-PostOfficeBox'
SUP postOfficeBox COLLECTIVE )
3.9. Collective Physical Delivery Office Name
The c-PhysicalDeliveryOfficeName attribute type specifies a physical
delivery office name for a collection of entries.
( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
SUP physicalDeliveryOfficeName COLLECTIVE )
3.10. Collective Telephone Number
The c-TelephoneNumber attribute type specifies a telephone number for
a collection of entries.
( 2.5.4.20.1 NAME 'c-TelephoneNumber'
SUP telephoneNumber COLLECTIVE )
3.11. Collective Telex Number
The c-TelexNumber attribute type specifies a telex number for a
collection of entries.
( 2.5.4.21.1 NAME 'c-TelexNumber'
SUP telexNumber COLLECTIVE )
3.13. Collective Facsimile Telephone Number
The c-FacsimileTelephoneNumber attribute type specifies a facsimile
telephone number for a collection of entries.
( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
Zeilenga draft-zeilenga-ldap-collective-08 [Page 6]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
SUP facsimileTelephoneNumber COLLECTIVE )
3.14. Collective International ISDN Number
The c-InternationalISDNNumber attribute type specifies an
international ISDN number for a collection of entries.
( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
SUP internationalISDNNumber COLLECTIVE )
4. Security Considerations
Collective attributes, like other attributes, are subject to access
control restrictions and other administrative policy. Generally
speaking, collective attributes accessed via an entry in a collection
are governed by rules restricting access to attributes of that entry.
And collective attributes access via a subentry are governed by rules
restricting access to attributes of that subentry. However, as LDAP
does not have a standard access model, the particulars of each
server's access control system may differ.
General LDAP security considerations [LDAPTS] also apply.
5. IANA Considerations
It is requested that IANA register upon Standards Action the LDAP
descriptors [LDAPIANA] defined in this technical specification. The
following registration template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor see comments
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <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]
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]
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]

675
doc/drafts/draft-zeilenga-ldap-subentry-xx.txt
View File

@ -1,675 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Date: 18 August 2002 Steven Legg
Expires in six months Adacel Technologies
Subentries in LDAP
<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]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
Conventions
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
Protocol elements are described using ASN.1 [X.680]. The term
"BER-encoded" means the element is to be encoded using the Basic
Encoding Rules [X.690] under the restrictions detailed in Section 5.1
of [RFC2251].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Overview
From [X.501]:
A subentry is a special kind of entry immediately subordinate to
an administrative point. It contains attributes that pertain to a
subtree (or subtree refinement) associated with its administrative
point. The subentries and their administrative point are part of
the same naming context.
A single subentry may serve all or several aspects of
administrative authority. Alternatively, a specific aspect of
administrative authority may be handled through one or more of its
own subentries.
Subentries in Lightweight Directory Access Protocol (LDAP) [LDAPTS]
SHALL behave in accordance with X.501 unless noted otherwise in this
specification.
In absence of the subentries control (detailed in Section 3),
subentries SHALL NOT be considered in one-level and subtree scope
search operations. For all other operations, including base scope
search operations, subentries SHALL be considered.
2. Subentry Schema
2.1. Subtree Specification Syntax
The Subtree Specification syntax provides a general purpose mechanism
for the specification of a subset of entries in a subtree of the
Directory Information Tree (DIT). A subtree begins at some base entry
and includes the subordinates of that entry down to some identified
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 2]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
lower boundary, possibly extending to the leaf entries. A subtree
specification is always used within a context or scope which
implicitly determines the bounds of the subtree. For example, the
scope of a subtree specification for a subschema administrative area
does not include the subtrees of any subordinate administrative point
entries for subschema administration. Where a subtree specification
does not identify a contiguous subset of the entries within a single
subtree the collection is termed a subtree refinement.
This syntax corresponds to the SubtreeSpecification ASN.1 type
described in [X.501], Section 11.3. This ASN.1 data type definition
is reproduced here for completeness.
SubtreeSpecification ::= SEQUENCE {
base [0] LocalName DEFAULT { },
COMPONENTS OF ChopSpecification,
specificationFilter [4] Refinement OPTIONAL }
LocalName ::= RDNSequence
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL}
BaseDistance ::= INTEGER (0 .. MAX)
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }
The components of SubtreeSpecification are: base, which identifies the
base entry of the subtree or subtree refinement, and
specificExclusions, minimum, maximum and specificationFilter, which
then reduce the set of subordinate entries of the base entry. The
subtree or subtree refinement contains all the entries within scope
that are not excluded by any of the components of the subtree
specification. When all of the components of SubtreeSpecification are
absent (i.e. when a value of the Subtree Specification syntax is the
empty sequence, {}), the subtree so specified implicitly includes all
the entries within scope.
Any particular use of this mechanism MAY impose limitations or
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 3]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
constraints on the components of SubtreeSpecification.
The LDAP syntax specification is:
( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
The native LDAP encoding of values of this syntax is defined by the
Generic String Encoding Rules [GSER]. Appendix A provides an
equivalent ABNF for this syntax.
2.1.1. Base
The base component of SubtreeSpecification nominates the base entry of
the subtree or subtree refinement. The base entry may be an entry
which is subordinate to the root entry of the scope in which the
subtree specification is used, in which case the base component
contains a sequence of RDNs relative to the root entry of the scope,
or may be the root entry of the scope itself (the default), in which
case the base component is absent or contains an empty sequence of
RDNs.
Entries that are not subordinates of the base entry are excluded from
the subtree or subtree refinement.
2.1.2. Specific Exclusions
The specificExclusions component of a ChopSpecification is a list of
exclusions that specify entries and their subordinates to be excluded
from the the subtree or subtree refinement. The entry is specified by
a sequence of RDNs relative to the base entry (i.e. a LocalName).
Each exclusion is of either the chopBefore or chopAfter form. If the
chopBefore form is used then the specified entry and its subordinates
are excluded from the subtree or subtree refinement. If the chopAfter
form is used then only the subordinates of the specified entry are
excluded from the subtree or subtree refinement.
2.1.3. Minimum and Maximum
The minimum and maximum components of a ChopSpecification allow the
exclusion of entries based on their depth in the DIT.
Entries that are less than the minimum number of RDN arcs below the
base entry are excluded from the subtree or subtree refinement. A
minimum value of zero (the default) corresponds to the base entry.
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 4]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
Entries that are more than the maximum number of RDN arcs below the
base entry are excluded from the subtree or subtree refinement. An
absent maximum component indicates that there is no upper limit on the
number of RDN arcs below the base entry for entries in the subtree or
subtree refinement.
2.1.4. Specification Filter
The specificationFilter component is a boolean expression of
assertions about the values of the objectClass attribute of the base
entry and its subordinates. A Refinement assertion item evaluates to
true for an entry if that entry's objectClass attribute contains the
OID nominated in the assertion. Entries for which the overall filter
evaluates to false are excluded from the subtree refinement. If the
specificationFilter is absent then no entries are excluded from the
subtree or subtree refinement because of their objectClass attribute
values.
2.2. Administrative Role Attribute Type
The Administrative Model defined in [X.501], clause 10 requires that
administrative entries contain an administrativeRole attribute to
indicate that the associated administrative area is concerned with one
or more administrative roles.
The administrativeRole operational attribute is specified as follows:
( 2.5.18.5 NAME 'administrativeRole'
EQUALITY objectIdentifierMatch
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The possible values of this attribute defined in X.501 are:
OID NAME
-------- -------------------------------
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea
Other values may be defined in other specifications. Names associated
with each administrative role are Object Identifier Descriptors
[LDAPIANA].
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 5]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
The administrativeRole operational attribute is also used to regulate
the subentries permitted to be subordinate to an administrative entry.
A subentry not of a class permitted by the administrativeRole
attribute cannot be subordinate to the administrative entry.
2.3. Subtree Specification Attribute Type
The subtreeSpecification operational attribute is defined as follows:
( 2.5.18.6 NAME 'subtreeSpecification'
SINGLE-VALUE
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
This attribute is present in all subentries. See [X.501], clause 10.
Values of the subtreeSpecification attribute nominate collections of
entries within the DIT for one or more aspects of administrative
authority.
2.4. Subentry Object Class
The subentry object class is a structural object class.
( 2.5.20.0 NAME 'subentry'
SUP top STRUCTURAL
MUST ( cn $ subtreeSpecification ) )
3. Subentries Control
The subentries control MAY be sent with a searchRequest to control the
visibility of entries and subentries which are within scope.
Non-visible entries or subentries are not returned in response to the
request.
The subentries control is an LDAP Control whose controlType is
1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent),
and controlValue contains a BER-encoded BOOLEAN indicating visibility.
A controlValue containing the value TRUE indicates that subentries are
visible and normal entries are not. A controlValue containing the
value FALSE indicates that normal entries are visible and subentries
are not.
Note that TRUE visibility has the three octet encoding { 01 01 FF }
and FALSE visibility has the three octet encoding { 01 01 00 }.
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 6]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
The controlValue SHALL NOT be absent.
In absence of this control, subentries are not visible to singleLevel
and wholeSubtree scope Search requests but are visible to baseObject
scope Search requests.
There is no corresponding response control.
This control is not appropriate for non-Search operations.
4. Security Considerations
Subentries often hold administrative information or other sensitive
information and should be protected from unauthorized access and
disclosure as described in [RFC2829][RFC2830].
General LDAP [LDAPTS] security considerations also apply.
5. IANA Considerations
5.1 Descriptors
It is requested that IANA register upon Standards Action the LDAP
descriptors detailed in this technical specification. The following
registration template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <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]
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]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
7. Authors' Addresses
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au
8. Normative References
[X.501] ITU-T, "The Directory -- Models," X.501, 1993.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690, 1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (was RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000
[RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress.
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 9]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
[GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldapext-gser--xx.txt, a work in progress.
[LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf-
ldapbis-iana-xx.txt, a work in progress.
9. Informative References
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[GCE] S. Legg, "Common Elements of GSER Encodings",
draft-legg-ldap-gser-abnf-xx.txt, a work in progress.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
A. Subtree Specification ABNF
This appendix is non-normative.
The LDAP-specific native string encoding for the Subtree Specification
syntax is specified by the Generic String Encoding Rules [GSER]. The
ABNF [RFC2234] in this appendix for this syntax is provided only as a
convenience and is equivalent to the encoding specified by the
application of [GSER]. Since the SubtreeSpecification ASN.1 type may
be extended in future editions of [X.501], the provided ABNF should be
regarded as a snapshot in time. The native LDAP encoding for any
extension to the SubtreeSpecification ASN.1 type can be determined
from [GSER].
In the event that there is a discrepancy between this ABNF and the
encoding determined by [GSER], [GSER] is to be taken as definitive.
SubtreeSpecification = "{" [ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
sp "}"
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp SpecificExclusions
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 10]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
SpecificExclusions = "{" sp SpecificExclusion
*( "," sp SpecificExclusion ) sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore ":" LocalName
chopAfter = id-chopAfter ":" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
BaseDistance = INTEGER-0-MAX
The <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]
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]

2
doc/rfc/INDEX
View File

@ -33,6 +33,8 @@ rfc3296.txt Named Subordinate References in LDAP (PS)
rfc3377.txt LDAP(v3): Technical Specification (PS)
rfc3383.txt IANA Considerations for LDAP (BCP)
rfc3663.txt Domain Administrative Data in LDAP (E)
rfc3671.txt Collective Attributes in LDAP (PS)
rfc3672.txt Subentries in the LDAP (PS)
rfc3673.txt LDAPv3: All Operational Attributes (PS)
rfc3674.txt Feature Discovery in LDAP (PS)

563
doc/rfc/rfc3671.txt Normal file
View File

@ -0,0 +1,563 @@
Network Working Group K. Zeilenga
Request for Comments: 3671 OpenLDAP Foundation
Category: Standards Track December 2003
Collective Attributes in
the Lightweight Directory Access Protocol (LDAP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
X.500 collective attributes allow common characteristics to be shared
between collections of entries. This document summarizes the X.500
information model for collective attributes and describes use of
collective attributes in LDAP (Lightweight Directory Access
Protocol). This document provides schema definitions for collective
attributes for use in LDAP.
1. Introduction
In X.500 [X.500], a collective attribute is "a user attribute whose
values are the same for each member of an entry collection" [X.501].
This document details their use in the Lightweight Directory Access
Protocol (LDAP) [RFC3377].
1.1. Entry Collections
A collection of entries is a grouping of object and alias entries
based upon common properties or shared relationship between the
corresponding entries which share certain attributes. An entry
collection consists of all entries within scope of a collective
attributes subentry [RFC3672]. An entry can belong to several entry
collections.
Zeilenga Standards Track [Page 1]
RFC 3671 Collective Attributes in LDAP December 2003
1.2. Collective Attributes
Attributes shared by the entries comprising an entry collection are
called collective attributes. Values of collective attributes are
visible but not updateable to clients accessing entries within the
collection. Collective attributes are updated (i.e., modified) via
their associated collective attributes subentry.
When an entry belongs to multiple entry collections, the entry's
values of each collective attribute are combined such that
independent sources of these values are not manifested to clients.
Entries can specifically exclude a particular collective attribute by
listing the attribute as a value of the collectiveExclusions
attribute. Like other user attributes, collective attributes are
subject to a variety of controls including access, administrative,
and content controls.
1.3. Conventions
Schema definitions are provided using LDAPv3 [RFC2251] description
formats [RFC2252]. Definitions provided here are formatted (line
wrapped) for readability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
2. System Schema for Collective Attributes
The following operational attributes are used to manage Collective
Attributes. LDAP servers [RFC3377] MUST act in accordance with the
X.500 Directory Models [X.501] when providing this service.
2.1. collectiveAttributeSubentry
Subentries of this object class are used to administer collective
attributes and are referred to as collective attribute subentries.
( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
A collective attribute subentry SHOULD contain at least one
collective attribute. The collective attributes contained within a
collective attribute subentry are available for finding, searching,
and comparison at every entry within the scope of the subentry. The
collective attributes, however, are administered (e.g., modified) via
the subentry.
Zeilenga Standards Track [Page 2]
RFC 3671 Collective Attributes in LDAP December 2003
Implementations of this specification SHOULD support collective
attribute subentries in both collectiveAttributeSpecificArea
(2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative
areas [RFC3672][X.501].
2.2. collectiveAttributeSubentries
The collectiveAttributeSubentries operational attribute identifies
all collective attribute subentries that affect the entry.
( 2.5.18.12 NAME 'collectiveAttributeSubentries'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE directoryOperation NO-USER-MODIFICATION )
2.3. collectiveExclusions
The collectiveExclusions operational attribute allows particular
collective attributes to be excluded from an entry. It MAY appear in
any entry and MAY have multiple values.
( 2.5.18.7 NAME 'collectiveExclusions'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE directoryOperation )
The descriptor excludeAllCollectiveAttributes is associated with the
OID 2.5.18.0. When this descriptor or OID is present as a value of
the collectiveExclusions attribute, all collective attributes are
excluded from an entry.
3. Collective Attribute Types
A userApplications attribute type can be defined to be COLLECTIVE
[RFC2252]. This indicates that the same attribute values will appear
in the entries of an entry collection subject to the use of the
collectiveExclusions attribute and other administrative controls.
These administrative controls MAY include DIT Content Rules, if
implemented.
Collective attribute types are commonly defined as subtypes of non-
collective attribute types. By convention, collective attributes are
named by prefixing the name of their non-collective supertype with
"c-". For example, the collective telephone attribute is named
c-TelephoneNumber after its non-collective supertype telephoneNumber.
Non-collective attributes types SHALL NOT subtype collective
attributes.
Zeilenga Standards Track [Page 3]
RFC 3671 Collective Attributes in LDAP December 2003
Collective attributes SHALL NOT be SINGLE-VALUED. Collective
attribute types SHALL NOT appear in the attribute types of an object
class definition.
Operational attributes SHALL NOT be defined to be collective.
The remainder of section provides a summary of collective attributes
derived from those defined in [X.520]. The SUPerior attribute types
are described in [RFC 2256] for use with LDAP.
Implementations of this specification SHOULD support the following
collective attributes and MAY support additional collective
attributes.
3.1. Collective Locality Name
The c-l attribute type specifies a locality name for a collection of
entries.
( 2.5.4.7.1 NAME 'c-l'
SUP l COLLECTIVE )
3.2. Collective State or Province Name
The c-st attribute type specifies a state or province name for a
collection of entries.
( 2.5.4.8.1 NAME 'c-st'
SUP st COLLECTIVE )
3.3. Collective Street Address
The c-street attribute type specifies a street address for a
collection of entries.
( 2.5.4.9.1 NAME 'c-street'
SUP street COLLECTIVE )
3.4. Collective Organization Name
The c-o attribute type specifies an organization name for a
collection of entries.
( 2.5.4.10.1 NAME 'c-o'
SUP o COLLECTIVE )
Zeilenga Standards Track [Page 4]
RFC 3671 Collective Attributes in LDAP December 2003
3.5. Collective Organizational Unit Name
The c-ou attribute type specifies an organizational unit name for a
collection of entries.
( 2.5.4.11.1 NAME 'c-ou'
SUP ou COLLECTIVE )
3.6. Collective Postal Address
The c-PostalAddress attribute type specifies a postal address for a
collection of entries.
( 2.5.4.16.1 NAME 'c-PostalAddress'
SUP postalAddress COLLECTIVE )
3.7. Collective Postal Code
The c-PostalCode attribute type specifies a postal code for a
collection of entries.
( 2.5.4.17.1 NAME 'c-PostalCode'
SUP postalCode COLLECTIVE )
3.8. Collective Post Office Box
The c-PostOfficeBox attribute type specifies a post office box for a
collection of entries.
( 2.5.4.18.1 NAME 'c-PostOfficeBox'
SUP postOfficeBox COLLECTIVE )
3.9. Collective Physical Delivery Office Name
The c-PhysicalDeliveryOfficeName attribute type specifies a physical
delivery office name for a collection of entries.
( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
SUP physicalDeliveryOfficeName COLLECTIVE )
3.10. Collective Telephone Number
The c-TelephoneNumber attribute type specifies a telephone number for
a collection of entries.
( 2.5.4.20.1 NAME 'c-TelephoneNumber'
SUP telephoneNumber COLLECTIVE )
Zeilenga Standards Track [Page 5]
RFC 3671 Collective Attributes in LDAP December 2003
3.11. Collective Telex Number
The c-TelexNumber attribute type specifies a telex number for a
collection of entries.
( 2.5.4.21.1 NAME 'c-TelexNumber'
SUP telexNumber COLLECTIVE )
3.13. Collective Facsimile Telephone Number
The c-FacsimileTelephoneNumber attribute type specifies a facsimile
telephone number for a collection of entries.
( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
SUP facsimileTelephoneNumber COLLECTIVE )
3.14. Collective International ISDN Number
The c-InternationalISDNNumber attribute type specifies an
international ISDN number for a collection of entries.
( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
SUP internationalISDNNumber COLLECTIVE )
4. Security Considerations
Collective attributes, like other attributes, are subject to access
control restrictions and other administrative policy. Generally
speaking, collective attributes accessed via an entry in a collection
are governed by rules restricting access to attributes of that entry.
And collective attributes access via a subentry are governed by rules
restricting access to attributes of that subentry. However, as LDAP
does not have a standard access model, the particulars of each
server's access control system may differ.
General LDAP security considerations [RFC3377] also apply.
Zeilenga Standards Track [Page 6]
RFC 3671 Collective Attributes in LDAP December 2003
5. IANA Considerations
The IANA has registered the LDAP descriptors [RFC3383] defined in
this technical specification. The following registration template is
suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor see comments
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <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]
RFC 3671 Collective Attributes in LDAP December 2003
6. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
7. Acknowledgments
This document is based upon the ITU Recommendations for the Directory
[X.501][X.520].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[RFC3377] Hodges, J. and R. L. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
Zeilenga Standards Track [Page 8]
RFC 3671 Collective Attributes in LDAP December 2003
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in Lightweight
Directory Access Protocol (LDAP)", RFC 3672, December
2003.
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993.
8.2. Informative References
[X.500] "The Directory: Overview of Concepts, Models", ITU-T
Recommendation X.500, 1993.
[X.520] "The Directory: Selected Attribute Types", ITU-T
Recommendation X.520, 1993.
9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Zeilenga Standards Track [Page 9]
RFC 3671 Collective Attributes in LDAP December 2003
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zeilenga Standards Track [Page 10]

675
doc/rfc/rfc3672.txt Normal file
View File

@ -0,0 +1,675 @@
Network Working Group K. Zeilenga
Request for Comments: 3672 OpenLDAP Foundation
Category: Standards Track S. Legg
Adacel Technologies
December 2003
Subentries in the Lightweight Directory Access Protocol (LDAP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
In X.500 directories, subentries are special entries used to hold
information associated with a subtree or subtree refinement. This
document adapts X.500 subentries mechanisms for use with the
Lightweight Directory Access Protocol (LDAP).
1. Overview
From [X.501]:
A subentry is a special kind of entry immediately subordinate to
an administrative point. It contains attributes that pertain to
a subtree (or subtree refinement) associated with its
administrative point. The subentries and their administrative
point are part of the same naming context.
A single subentry may serve all or several aspects of
administrative authority. Alternatively, a specific aspect of
administrative authority may be handled through one or more of
its own subentries.
Subentries in the Lightweight Directory Access Protocol (LDAP)
[RFC3377] SHALL behave in accordance with X.501 unless noted
otherwise in this specification.
Zeilenga & Legg Standards Track [Page 1]
RFC 3672 Subentries in LDAP December 2003
In absence of the subentries control (detailed in Section 3),
subentries SHALL NOT be considered in one-level and subtree scope
search operations. For all other operations, including base scope
search operations, subentries SHALL be considered.
1.1. Conventions
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped)
for readability.
Protocol elements are described using ASN.1 [X.680]. The term "BER-
encoded" means the element is to be encoded using the Basic Encoding
Rules [X.690] under the restrictions detailed in Section 5.1 of
[RFC2251].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
2. Subentry Schema
2.1. Subtree Specification Syntax
The Subtree Specification syntax provides a general purpose mechanism
for the specification of a subset of entries in a subtree of the
Directory Information Tree (DIT). A subtree begins at some base
entry and includes the subordinates of that entry down to some
identified lower boundary, possibly extending to the leaf entries. A
subtree specification is always used within a context or scope which
implicitly determines the bounds of the subtree. For example, the
scope of a subtree specification for a subschema administrative area
does not include the subtrees of any subordinate administrative point
entries for subschema administration. Where a subtree specification
does not identify a contiguous subset of the entries within a single
subtree the collection is termed a subtree refinement.
This syntax corresponds to the SubtreeSpecification ASN.1 type
described in [X.501], Section 11.3. This ASN.1 data type definition
is reproduced here for completeness.
SubtreeSpecification ::= SEQUENCE {
base [0] LocalName DEFAULT { },
COMPONENTS OF ChopSpecification,
specificationFilter [4] Refinement OPTIONAL }
LocalName ::= RDNSequence
Zeilenga & Legg Standards Track [Page 2]
RFC 3672 Subentries in LDAP December 2003
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0 .. MAX)
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }
The components of SubtreeSpecification are: base, which identifies
the base entry of the subtree or subtree refinement, and
specificExclusions, minimum, maximum and specificationFilter, which
then reduce the set of subordinate entries of the base entry. The
subtree or subtree refinement contains all the entries within scope
that are not excluded by any of the components of the subtree
specification. When all of the components of SubtreeSpecification
are absent (i.e., when a value of the Subtree Specification syntax is
the empty sequence, {}), the specified subtree implicitly includes
all the entries within scope.
Any particular use of this mechanism MAY impose limitations or
constraints on the components of SubtreeSpecification.
The LDAP syntax specification is:
( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
The LDAP-specific encoding of values of this syntax is defined by the
Generic String Encoding Rules [RFC3641]. Appendix A provides an
equivalent Augmented Backus-Naur Form (ABNF) [RFC2234] for this
syntax.
2.1.1. Base
The base component of SubtreeSpecification nominates the base entry
of the subtree or subtree refinement. The base entry may be an entry
which is subordinate to the root entry of the scope in which the
subtree specification is used, in which case the base component
contains a sequence of Relative Distinguished Names (RDNs) relative
to the root entry of the scope, or may be the root entry of the scope
itself (the default), in which case the base component is absent or
contains an empty sequence of RDNs.
Zeilenga & Legg Standards Track [Page 3]
RFC 3672 Subentries in LDAP December 2003
Entries that are not subordinates of the base entry are excluded from
the subtree or subtree refinement.
2.1.2. Specific Exclusions
The specificExclusions component of a ChopSpecification is a list of
exclusions that specify entries and their subordinates to be excluded
from the subtree or subtree refinement. The entry is specified by a
sequence of RDNs relative to the base entry (i.e., a LocalName).
Each exclusion is of either the chopBefore or chopAfter form. If the
chopBefore form is used then the specified entry and its subordinates
are excluded from the subtree or subtree refinement. If the
chopAfter form is used then only the subordinates of the specified
entry are excluded from the subtree or subtree refinement.
2.1.3. Minimum and Maximum
The minimum and maximum components of a ChopSpecification allow the
exclusion of entries based on their depth in the DIT.
Entries that are less than the minimum number of RDN arcs below the
base entry are excluded from the subtree or subtree refinement. A
minimum value of zero (the default) corresponds to the base entry.
Entries that are more than the maximum number of RDN arcs below the
base entry are excluded from the subtree or subtree refinement. An
absent maximum component indicates that there is no upper limit on
the number of RDN arcs below the base entry for entries in the
subtree or subtree refinement.
2.1.4. Specification Filter
The specificationFilter component is a boolean expression of
assertions about the values of the objectClass attribute of the base
entry and its subordinates. A Refinement assertion item evaluates to
true for an entry if that entry's objectClass attribute contains the
OID nominated in the assertion. Entries for which the overall filter
evaluates to false are excluded from the subtree refinement. If the
specificationFilter is absent then no entries are excluded from the
subtree or subtree refinement because of their objectClass attribute
values.
Zeilenga & Legg Standards Track [Page 4]
RFC 3672 Subentries in LDAP December 2003
2.2. Administrative Role Attribute Type
The Administrative Model defined in [X.501], clause 10 requires that
administrative entries contain an administrativeRole attribute to
indicate that the associated administrative area is concerned with
one or more administrative roles.
The administrativeRole operational attribute is specified as follows:
( 2.5.18.5 NAME 'administrativeRole'
EQUALITY objectIdentifierMatch
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The possible values of this attribute defined in X.501 are:
OID NAME
-------- -------------------------------
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea
Other values may be defined in other specifications. Names
associated with each administrative role are Object Identifier
Descriptors [RFC3383].
The administrativeRole operational attribute is also used to regulate
the subentries permitted to be subordinate to an administrative
entry. A subentry not of a class permitted by the administrativeRole
attribute cannot be subordinate to the administrative entry.
2.3. Subtree Specification Attribute Type
The subtreeSpecification operational attribute is defined as follows:
( 2.5.18.6 NAME 'subtreeSpecification'
SINGLE-VALUE
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
This attribute is present in all subentries. See [X.501], clause 10.
Values of the subtreeSpecification attribute nominate collections of
entries within the DIT for one or more aspects of administrative
authority.
Zeilenga & Legg Standards Track [Page 5]
RFC 3672 Subentries in LDAP December 2003
2.4. Subentry Object Class
The subentry object class is a structural object class.
( 2.5.17.0 NAME 'subentry'
SUP top STRUCTURAL
MUST ( cn $ subtreeSpecification ) )
3. Subentries Control
The subentries control MAY be sent with a searchRequest to control
the visibility of entries and subentries which are within scope.
Non-visible entries or subentries are not returned in response to the
request.
The subentries control is an LDAP Control whose controlType is
1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent),
and controlValue contains a BER-encoded BOOLEAN indicating
visibility. A controlValue containing the value TRUE indicates that
subentries are visible and normal entries are not. A controlValue
containing the value FALSE indicates that normal entries are visible
and subentries are not.
Note that TRUE visibility has the three octet encoding { 01 01 FF }
and FALSE visibility has the three octet encoding { 01 01 00 }.
The controlValue SHALL NOT be absent.
In absence of this control, subentries are not visible to singleLevel
and wholeSubtree scope Search requests but are visible to baseObject
scope Search requests.
There is no corresponding response control.
This control is not appropriate for non-Search operations.
4. Security Considerations
Subentries often hold administrative information or other sensitive
information and should be protected from unauthorized access and
disclosure as described in [RFC2829][RFC2830].
General LDAP [RFC3377] security considerations also apply.
Zeilenga & Legg Standards Track [Page 6]
RFC 3672 Subentries in LDAP December 2003
5. IANA Considerations
5.1. Descriptors
The IANA has registered the LDAP descriptors detailed in this
technical specification. The following registration template is
suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <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]
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]
RFC 3672 Subentries in LDAP December 2003
A. Subtree Specification ABNF
This appendix is non-normative.
The LDAP-specific string encoding for the Subtree Specification
syntax is specified by the Generic String Encoding Rules [RFC3641].
The ABNF [RFC2234] in this appendix for this syntax is provided only
as a convenience and is equivalent to the encoding specified by the
application of [RFC3641]. Since the SubtreeSpecification ASN.1 type
may be extended in future editions of [X.501], the provided ABNF
should be regarded as a snapshot in time. The LDAP-specific encoding
for any extension to the SubtreeSpecification ASN.1 type can be
determined from [RFC3641].
In the event that there is a discrepancy between this ABNF and the
encoding determined by [RFC3641], [RFC3641] is to be taken as
definitive.
SubtreeSpecification = "{" [ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
sp "}"
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp
SpecificExclusions
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore ":" LocalName
chopAfter = id-chopAfter ":" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Zeilenga & Legg Standards Track [Page 9]
RFC 3672 Subentries in LDAP December 2003
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
BaseDistance = INTEGER-0-MAX
The <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]
RFC 3672 Subentries in LDAP December 2003
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", RFC 3383, September 2002.
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", RFC 3641, October 2003.
Informative References
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3642] Legg, S., "Common Elements of Generic String Encoding
Rules (GSER) Encodings", RFC 3642, October 2003.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers
Authors' Addresses
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Zeilenga & Legg Standards Track [Page 11]
RFC 3672 Subentries in LDAP December 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zeilenga & Legg Standards Track [Page 12]