upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-12-24 00:29:35 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

More I-D.

Browse source
This commit is contained in:
Kurt Zeilenga 2002-06-07 01:58:40 +00:00
parent 536fafdb39
commit 018ace0c50
12 changed files with 4336 additions and 783 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1298
doc/drafts/draft-ietf-ldup-lcup-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

283
doc/drafts/draft-zeilenga-ldap-adlist-xx.txt Normal file
View file

@ -0,0 +1,283 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 17 May 2002
LDAPv3: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-01.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 Informational document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ietf-ldapext@netscape.com>. 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) search operation
provides mechanisms for clients to request all user application
attributes, all operational attributes, or attributes selected by
their description. This document extends LDAP to provide a mechanism
for LDAP clients to request the return of all attributes of an object
class.
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
1. Overview
LDAP [RFC2251] search operations support mechanisms for requesting
sets of attributes. This set is determined by a list of attribute
descriptions. Two special descriptors are defined to request all user
attributes ("*") and all operational attributes ("+"). However, there
is no convenient mechanism for requesting pre-defined sets of
attributes. This document extends LDAP to allow an object class
identifier to be specified in search request attributes list to
request the return all attributes allowed by object class.
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. Return of all Attributes of an Object Class
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [RFC2251]. For each
object class identified in the attributes field, the request is to be
treated as if each attribute allowed by that class (by "MUST" or
"MAY", directly or by SUPerior) was itself listed. For example, a
request for "country" [RFC2256] is treated as if "c", "searchGuide",
"description", and "objectClass" were requested.
As a special case, requesting extensibleObject [RFC2252] is treated as
if "objectClass,*,+" was requested [RFC2251][OPATTRS].
If the object class identifier is unrecognized, it is be treated an an
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
be a DescriptionList described by the following [ASN.1]:
DescriptionList ::= SEQUENCE OF Description
Description ::= LDAPString
The Description is string conforming to the [ABNF]:
Description ::= AttributeDescription | ObjectClassDescription.
ObjectDescription ::= ObjectClass *( ";" options )
where AttributeDescription and options productions are as defined in
Section 4.1.5 of [RFC2251] and an ObjectClass is an objectIdentifier,
in either numericoid or descr form [RFC 2252], of an object class.
ObjectDescription options are provided for extensibility. This
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
document only defines semantics of ObjectDescriptions with zero
options in the attributes field of a SearchRequest. Other uses may be
defined in future specifications.
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.2 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
3. Security Considerations
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
individually, this short hand is not believed to raises additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP general security considerations [LDAPTS].
4. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.5.2 to identify the LDAP
feature it details. This OID was assigned [ASSIGN] by OpenLDAP
Foundation under its IANA assigned private enterprise allocation
[PRIVATE] for use in this specification.
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
6. 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 Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
[LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
[OPATTRS] K. Zeilenga, "LDAPv3: All Operational Attributes",
draft-zeilenga-ldap-opattrs-xx.txt (a work in progress).
7. Informative References
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 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
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.
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
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 Requesting Attributes by Object Class [Page 5]

339
doc/drafts/draft-zeilenga-ldap-authzid-xx.txt Normal file
View file

@ -0,0 +1,339 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
LDAP "Who am I?" Operation
<draft-zeilenga-ldap-authzid-06.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 <ietf-ldapext@netscape.com>. 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
This specification provides a mechanism for Lightweight Directory
Access Protocol (LDAP) clients to obtain the authorization identity
which the server has associated with the user or application entity.
This mechanism is specified as an LDAP extended operation called the
LDAP "Who am I?" operation.
Zeilenga LDAP "Who am I?" [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Conventions
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. Background and Intent of Use
This specification describes a Lightweight Directory Access Protocol
(LDAP) [RFC2251] extended operation which clients can use to obtain
the primary authorization identity in its primary form which the
server has associated with the user or application entity.
Servers often associate multiple authorization identities with the
client and each authorization identity may be represented by multiple
authzId [RFC2829] strings. This operation requests and returns the
authzId the server considers to be primary. In the specification, the
term "the authorization identity" and "the authzid" are to generally
read as "the primary authorization identity" and the "the primary
authzid", respectively.
This specification is intended to replace the existing [AUTHCTL]
mechanism which uses Bind request and response controls to request and
return the authorization identity. Bind controls are not protected by
the security layers established by the Bind operation which they are
transferred as part of. While it is possible to establish security
layers prior to the Bind operation, it is often desirable to only use
security layers established by the Bind operation. An extended
operation sent after a Bind operation is protected by the security
layers established by the Bind operation.
There are other cases where it is desirable to request the
authorization identity which the server associated with the client
separately from the Bind operation. For example, the "Who am I?"
operation can be augmented with a Proxied Authorization Control
[PROXYCTL] to determine the authorization identity which the server
associates with the identity asserted in the Proxied Authorization
Control. The "Who am I?" operation can also be used prior to the Bind
operation.
The LDAP "Who am I?" operation is named after the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
2. The "Who am I?" Operation
The "Who am I?" operation is defined as an LDAP Extended Operation
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
[RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
(OID). This section details the syntax of the operation's whoami
request and response messages.
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
2.1. The whoami Request
The whoami request is an ExtendedRequest with the requestName field
containing the whoamiOID OID and an absent requestValue field. For
example, a whoami request could be encoded as the sequence of octets
(in hex):
2.2. The whoami Response
The whoami response is an ExtendedResponse where the responseName
field is absent and, if present, the response field is empty or an
authzId [RFC2829]. For example, a whoami response returning the
authzid "u:kurt@OPENLDAP.ORG" (in response to the example request)
would be encoded as the sequence of octets (in hex):
3. Operational Semantics
The function of the "Who am I?" operation is to request that the
server returns the authorization identity it currently associates with
the client. The client requests this authorization identity by
issuing a whoami Request. The server responds to this request with a
whoami Response.
If the server is willing and able to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with a success resultCode. If the server is treating
the client as an anonymous entity, the response field is empty.
Otherwise the server is to provide the authzId [RFC2829] representing
the authorization identity it currently associates with the client in
the response field.
If the server is unwilling or unable to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with an appropriate non-success resultCode (such as
operationsError, protocolError, confidentialityRequired,
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
other) and an absent response field.
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
As described in [RFC2251] and [RFC2829], an LDAP session has an
"anonymous" association until the client has been successfully
authenticated using the Bind operation. Clients MUST NOT invoke the
"Who Am I?" operation while any Bind operation is in progress,
including between two Bind requests made as part of a multi-stage Bind
operation.
4. Extending the "Who am I?" operation with controls
Future specifications may extend the "Who am I?" operation using the
control mechanism. When extended by controls, the "Who am I?"
operation requests and returns the authorization identity the server
associates with the client in a particular context indicated by the
controls.
4.1. Proxied Authorization Control
The Proxied Authorization Control [PROXYCTL] is used by clients to
request that the operation it is attached to operates under the
authorization of an assumed identity. The client provides the
identity to assume in the Proxied Authorization request control. If
the client is authorized to assume the requested identity, the server
executes the operation as if the requested identity had issued the
operation.
As servers often map the asserted authzId to another identity
[RFC2829], it is desirable to request the server provide the authzId
it associates with the assumed identity.
When a Proxied Authorization Control is be attached to the "Who Am I?"
operation, the operation requests the return of the authzid the server
associates with the identity asserted in the Proxied Authorization
Control. The TBD result code is used to indicate that the server does
not allow the client to assume the asserted identity. [[Note to RFC
Editor: TBD is to be replaced with the name/code assigned by IANA for
[PROXYCTL] use.]]
5. Security Considerations
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] should be established to
protect this information. This mechanism is specifically designed to
allow security layers established by a Bind operation to protect the
integrity and/or confidentiality of the authorization identity.
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Servers may place access control or other restrictions upon the use of
this operation.
As with any other extended operations, general LDAP considerations
apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
6. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.11.3 to identify the
LDAP "Who Am I? extended operation. This OID was assigned [ASSIGN] by
OpenLDAP Foundation under its IANA assigned private enterprise
allocation [PRIVATE] for use in this specification.
7. Acknowledgment
This document borrows from prior work in this area including
"Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
and Mark Wahl.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
9. 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.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
"Authentication Methods for LDAP", RFC 2829, June 2000.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt (a work in progress).
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
10. Informative References
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
Response Control", draft-weltman-ldapv3-auth-response-
xx.txt (a work in progress).
[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
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 "Who am I?" [Page 6]

294
doc/drafts/draft-zeilenga-ldap-cancel-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 1 October 2001 1 April 2001
Expires in six months 17 May 2002
LDAP Cancel Extended Operation
<draft-zeilenga-ldap-cancel-03.txt>
<draft-zeilenga-ldap-cancel-05.txt>
1. Status of this Memo
@ -34,103 +34,112 @@ Expires: 1 October 2001 1 April 2001
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.
<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 2001, The Internet Society. All Rights Reserved.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
2. Abstract
Abstract
This specification describes an extended operation to cancel (or
abandon) an outstanding operation. Unlike the LDAP Abandon operation
[RFC2251] but like the DAP Abandon operation [X.511], this operation
has a response which provides an indication of its outcome.
This specification describes an LDAP (Lightweight Directory Access
Protocol) extended operation to cancel (or abandon) an outstanding
operation. Unlike the LDAP Abandon operation but like the X.511 DAP
Abandon operation, this operation has a response which provides an
indication of its outcome.
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
Zeilenga LDAP Cancel [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
this document are to be interpreted as described in RFC 2119
[RFC2119].
Conventions
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].
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].
3. Background and Intent of Use
1. Background and Intent of Use
LDAP provides an Abandon operation which clients may use to cancel
other operations. The Abandon operation does not have a response and
also calls for there to be no response of the abandoned operation.
These semantics provide the client with no clear indication of the
outcome of the Abandon operation.
LDAP [RFC2251] provides an Abandon operation which clients may use to
cancel other operations. The Abandon operation does not have a
response and also calls for there to be no response of the abandoned
operation. These semantics provide the client with no clear
indication of the outcome of the Abandon operation.
DAP provides an Abandon operation which does have a response and also
requires the abandoned operation to return a response with indicating
it was canceled. The Cancel operation is modeled after the DAP
Abandon operation.
X.511 DAP [X.511] provides an Abandon operation which does have a
response and also requires the abandoned operation to return a
response with indicating it was canceled. The Cancel operation is
modeled after the DAP Abandon operation.
The Cancel operation is intended to be used instead of the LDAP
Abandon operation. This operation may be used to cancel both
interrogation and update operations.
The Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operation may be used to cancel both interrogation and update
operations.
4. Cancel Operation
4. Cancel Operation
The Cancel operation is defined as a LDAPv3 Extended Operation
[RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
This section details the syntax of the Cancel request and response
messages and defines additional LDAP resultCodes.
cancelOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.2
cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
}
4.1. Cancel Request
4.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
Zeilenga LDAP Cancel [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
containing cancelOID OID and a requestValue field which contains a
cancelRequestValue value encoded per [RFC2251, Section 5.1]. The
cancelID field contains the message id associated with the operation
to be canceled.
4.2. Cancel Response
4.2. Cancel Response
A Cancel response is an ExtendedResponse where the responseName and
Zeilenga LDAP Cancel [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
response fields are absent.
4.3. Additional Result Codes
4.3. Additional Result Codes
Implementations of this specification SHALL recognize the following
additional resultCode values:
canceled (72)
noSuchOperation (73)
tooLate (74)
cannotCancel (75)
canceled (IANA-ASSIGNED-1)
noSuchOperation (IANA-ASSIGNED-2)
tooLate (IANA-ASSIGNED-3)
cannotCancel (IANA-ASSIGNED-4)
5. Operational Semantics
5. Operational Semantics
The function of the Cancel Operation is to request that the server
cancel an outstanding operation issued within the same session.
@ -155,6 +164,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
operation requested to be canceled.
The server SHALL return cannotCancel if the identified operation does
Zeilenga LDAP Cancel [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
@ -165,13 +182,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
- operations which establish or tear-down security services, and
Zeilenga LDAP Cancel [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
- operations which abandon or cancel other operations.
Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
@ -191,7 +201,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
contains a value of cancelOID.
6. Security Considerations
6. Security Considerations
This operation is intended to allow a user to cancel operations they
previously issued. No user should be allowed to cancel an operation
@ -208,9 +218,100 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
cancelation when appropriate.
7. Copyright
7. IANA Considerations
Copyright 2001, The Internet Society. All Rights Reserved.
Zeilenga LDAP Cancel [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
7.1. Object Identifiers
It is requested that IANA register a Directory Number OID for use in
this document upon Standards Action by the IESG. This OID will be
used to identify the LDAP Cancel extended operation as indicated
above. The following registration template is suggested:
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFCXXX
Author/Change Controller: IESG
7.2. LDAP Result Codes
It is requested that IANA register the LDAP result codes:
canceled (IANA-ASSIGNED-1)
noSuchOperation (IANA-ASSIGNED-2)
tooLate (IANA-ASSIGNED-3)
cannotCancel (IANA-ASSIGNED-4)
upon Standards Action by the IESG. The following registration
template is suggested:
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: canceled
Result Code Name: noSuchOperation
Result Code Name: tooLate
Result Code Name: cannotCancel
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: request four consecutive result codes be assigned
8. Acknowledgment
This document is based upon input from the IETF LDAPext working group.
9. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
Zeilenga LDAP Cancel [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[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.
9. Informative References
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
11. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
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
@ -220,14 +321,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
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 LDAP Cancel [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
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,
@ -239,37 +332,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
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,
Zeilenga LDAP Cancel [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
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.
8. Bibliography
[RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993. (not normative)
9. Acknowledgment
This document is based upon input from the IETF LDAPext working group.
10. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
@ -279,5 +354,42 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
Zeilenga LDAP Cancel [Page 5]
Zeilenga LDAP Cancel [Page 7]

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

@ -0,0 +1,507 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
Collective Attributes in LDAP
<draft-zeilenga-ldap-collective-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 <ietf-ldapext@netscape.com>. 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-07 [Page 1]
INTERNET-DRAFT LDAP Collective Attributes 17 May 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-07 [Page 2]
INTERNET-DRAFT LDAP Collective Attributes 17 May 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-07 [Page 3]
INTERNET-DRAFT LDAP Collective Attributes 17 May 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-07 [Page 4]
INTERNET-DRAFT LDAP Collective Attributes 17 May 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-07 [Page 5]
INTERNET-DRAFT LDAP Collective Attributes 17 May 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-07 [Page 6]
INTERNET-DRAFT LDAP Collective Attributes 17 May 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 are not believed to introduce any additional
security considerations to LDAP [LDAPTS].
5. IANA Considerations
It is requested that IANA register the LDAP descriptors used in this
document per the following registration template:
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
------------------------ ---- -----------------
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
Zeilenga draft-zeilenga-ldap-collective-07 [Page 7]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
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.
This document uses in this document were assigned by the ISO/IEC Joint
Technical Committee 1 - Subcommitte 6 to identify elements of X.500
schema. This document make no OID assignments, it only associates
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.
[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.
Zeilenga draft-zeilenga-ldap-collective-07 [Page 8]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
[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-07 [Page 9]

124
doc/drafts/draft-zeilenga-ldap-features-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 26 December 2001 26 June 2001
Expires in six months 17 May 2002
Feature Discovery in LDAP
<draft-zeilenga-ldap-features-01.txt>
<draft-zeilenga-ldap-features-03.txt>
Status of this Memo
@ -38,13 +38,29 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
1. Overview
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-03 [Page 1]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
1. Background and Intended Use
LDAP [RFC2251] is an extensible protocol with numerous elective
features. LDAP provides mechanisms for a client to discover supported
@ -52,22 +68,16 @@ Status of this Memo
subschema information. However, these mechanisms are not designed to
support general feature discovery.
Zeilenga draft-zeilenga-ldap-features-01 [Page 1]
INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
This document describes a simple, general-purpose mechanism which
clients may use to discovery the set of features supported by a
server.
clients may use to discover the set of features supported by a server.
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
this document are to be interpreted as described in RFC 2119
[RFC2119].
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].
2. Discovery of supported features
@ -79,8 +89,7 @@ INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
examine the values of this attribute to determine if a particular
feature is supported by the server.
The supportedFeatures attribute type is described [RFC2252] as
follows:
The supportedFeatures attribute type is described as follows:
( 1.3.6.1.4.1.4203.1.3.5
NAME 'supportedFeatures'
@ -89,6 +98,10 @@ INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
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
@ -97,29 +110,49 @@ INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
believed to introduce any new security risk to LDAP.
4. Acknowledgment
Zeilenga draft-zeilenga-ldap-features-03 [Page 2]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
4. IANA Considerations
It is requested that IANA register the LDAP 'supportedFeatures'
descriptor used in this document per the following registration
template:
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: RFCXXXX
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.
5. Author's Address
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
Zeilenga draft-zeilenga-ldap-features-01 [Page 2]
INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
References
[RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[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.
@ -129,9 +162,19 @@ References
Definitions", RFC 2252, December 1997.
8. Informative References
Zeilenga draft-zeilenga-ldap-features-03 [Page 3]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
Full Copyright
Copyright 2001, The Internet Society. All Rights Reserved.
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
@ -167,5 +210,18 @@ Full Copyright
Zeilenga draft-zeilenga-ldap-features-01 [Page 3]
Zeilenga draft-zeilenga-ldap-features-03 [Page 4]

300
doc/drafts/draft-zeilenga-ldap-namedref-xx.txt
View file

@ -6,11 +6,12 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 20 January 2002 20 July 2001
Expires: 20 May 2002 20 November 2001
Named Subordinate References in LDAP Directories
<draft-zeilenga-ldap-namedref-04.txt>
<draft-zeilenga-ldap-namedref-05.txt>
Status of this Memo
@ -47,35 +48,50 @@ Status of this Memo
Abstract
This document details schema and protocol elements for representing
and manipulating named subordinate references in LDAP [RFC2251]
directories. A referral object is used to hold subordinate reference
information in the directory. These referral objects hold one or more
URIs [RFC2396] contained in values of the ref attribute type and are
used to generate protocol referrals and continuations. A control,
and managing named subordinate references in LDAP directories.
Conventions
Zeilenga LDAP NamedRef [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
ManageDsaIT, is defined to allow manipulation of referral objects as
normal objects.
Schema definitions are provided using LDAPv3 description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Usage
The broadening of interest in LDAP directories beyond their use as
front ends to X.500 [X.500] directories has created a need to
represent knowledge information in a more general way. Knowledge
information is information about one or more servers maintained in
another server, used to link servers and services together.
The broadening of interest in LDAP (Lightweight Directory Access
Protocol) [RFC2251] directories beyond their use as front ends to
X.500 [X.500] directories has created a need to represent knowledge
information in a more general way. Knowledge information is
information about one or more servers maintained in another server,
used to link servers and services together.
This document defines a specific method of representing subordinate
knowledge references in LDAP directories. Other forms of knowledge
information are not detailed by this document. These forms may be
described in subsequent documents.
This document details schema and protocol elements for representing
and manipulating named subordinate references in LDAP directories. A
referral object is used to hold subordinate reference information in
the directory. These referral objects hold one or more URIs [RFC2396]
contained in values of the ref attribute type and are used to generate
protocol referrals and continuations.
A control, ManageDsaIT, is defined to allow manipulation of referral
and other special objects as normal objects. As the name of control
implies, it is intended to be analogous to the ManageDsaIT service
option described in X.511(97) [X.511].
Other forms of knowledge information are not detailed by this
document. These forms may be described in subsequent documents.
This document details subordinate referral processing requirements for
servers. This document does not describe protocol syntax and
@ -85,21 +101,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
to support replicated environments nor distributed operations (e.g.,
chaining of operations from one server to other servers).
The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
interpreted as described in BCP 14 [RFC2119].
2. Schema
The schema definitions are defined in terms of RFC 2252 [RFC2252].
2.1. The referral Object Class
A referral object is a directory entry whose structural object class
is (or is derived from) the referral object class.
Zeilenga LDAP NamedRef [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
( 2.16.840.1.113730.3.2.6
NAME 'referral'
DESC 'named subordinate reference object'
@ -108,24 +124,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
The referral object class is a structural object class used to
represent a subordinate reference in the directory. The referral
Zeilenga LDAP NamedRef [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
object class SHOULD be used in conjunction with the extensibleObject
object class to support the naming attributes used in the entry's
Distinguished Name (DN) [RFC2253]. Referral objects are directory
entries whose structural object class is (or is derived from)
referral.
Referral objects MUST only be instantiated at DSEs immediately
subordinate to leaf object entries within a naming context held by the
DSA. Referral objects correspond to X.500 subordinate knowledge
(subr) DSEs [X.501].
Referral objects are normally instantiated at DSEs immediately
subordinate to object entries within a naming context held by the DSA.
Referral objects are analogous to X.500 subordinate knowledge (subr)
DSEs [X.501].
In the presence of a ManageDsaIT control, referral objects are treated
as normal entries as described in section 3. Note that the ref
@ -157,6 +165,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
structure on the label portion of the syntax as it appears in the ref
attribute.
Zeilenga LDAP NamedRef [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
If the URI contained in a ref attribute value refers to a LDAP
[RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255]. The
LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
@ -165,24 +180,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
empty DN parts or with explicit scope specifier is not defined by this
specification.
Zeilenga LDAP NamedRef [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
Other URI schemes MAY be used so long as all operations returning
referrals based upon the value could be performed. This document does
not detail use of non-LDAP URIs. This is left to future
specifications.
All values of a ref attribute MUST point to services which are equally
capable of handling operations referred to these services.
The referential integrity of the URI SHOULD NOT be validated by the
server holding or returning the URI (whether as part of the value of
the attribute or as part of a referral result or search reference
server holding or returning the URI (whether as a value of the
attribute or as part of a referral result or search reference
response).
When returning a referral result or search continuation, the server
@ -206,8 +211,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
DSA (server) Information Tree. The control causes Directory-specific
entries (DSEs), regardless of type, to be treated as normal entries
allowing clients to interrogate and update these entries using LDAP
operations. This control is analogous to the ManageDsaIT option
described in X.511 [X.511].
operations.
A client MAY specify the following control when issuing an add,
compare, delete, modify, modifyDN, search request or an extended
@ -216,18 +220,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
The control type is 2.16.840.1.113730.3.4.2. The control criticality
may be TRUE or, if FALSE, absent. The control value is absent.
When the control is present in the request, the server SHALL NOT
generate a referral or continuation reference for any referral object
and instead treat the referral object as a normal entry. When not
present, referral objects SHALL be handled as described above.
Zeilenga LDAP NamedRef [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
When the control is present in the request, the server SHALL NOT
generate a referral or continuation reference based upon information
held in referral objects and instead SHALL treat the referral object
as a normal entry. The server, however, is still free to return
referrals for other reasons. When not present, referral objects SHALL
be handled as described above.
The control MAY cause other objects to be treated as normal entries as
defined by subsequent documents.
@ -252,8 +259,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
objectClass: referral
objectClass: extensibleObject
While typically the DN of the referral object and the DN of the object
in the referenced server are the same, they need not be the same.
Typically the DN of the referral object and the DN of the object in
the referenced server are the same.
If the ref attribute has multiple values, all the DNs contained within
the LDAP URLs SHOULD be equivalent. Administrators SHOULD avoid
@ -267,23 +274,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
The following sections contain specifications of how referral objects
should be used in different scenarios followed by examples that
illustrate that usage. The scenarios described consist of referral
operation when finding target of a non-search operation, when finding
the base of a search operation, and when generating search references.
Lastly, other operation processing considerations are presented.
It is to be noted that, in this document, a search operation is
conceptually divided into two distinct, sequential phases: (1) finding
the base object where the search is to begin, and (2) performing the
search itself. The first phase is similar to, but not the same as,
illustrate that usage. The scenarios described here consist of
referral object handling when finding target of a non-search
Zeilenga LDAP NamedRef [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
operation, when finding the base of a search operation, and when
generating search references. Lastly, other operation processing
considerations are presented.
It is to be noted that, in this document, a search operation is
conceptually divided into two distinct, sequential phases: (1) finding
the base object where the search is to begin, and (2) performing the
search itself. The first phase is similar to, but not the same as,
finding the target of a non-search operation.
It should also be noted that the ref attribute may have multiple
@ -324,6 +332,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
Also, in the context of this document, the "nearest naming context"
means the deepest context which the object is within. That is, if the
Zeilenga LDAP NamedRef [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
object is within multiple naming contexts, the nearest naming context
is the one which is subordinate to all other naming contexts the
object is within.
@ -332,14 +348,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
5.2. Target object considerations
This section details referral handling for add, compare, delete,
Zeilenga LDAP NamedRef [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
modify, and modify DN operations. If the client requests any of these
operations, there are four cases that the server must handle with
respect to the target object.
@ -368,7 +376,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
object.
The server SHOULD return the URI value contained in the ref
attribute of the referral object.
attribute of the referral object appropriately modified as
described above.
Example: If the client issues a modify request for the target object
of "OU=People,O=MNN,c=WW", the server will return:
@ -379,6 +388,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
}
Zeilenga LDAP NamedRef [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Case 3: The target object is not held by the server, but the nearest
naming context contains no referral object which the target object
is subordinate to.
@ -388,14 +405,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
request as appropriate for a nonexistent target (generally return
noSuchObject).
Zeilenga LDAP NamedRef [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
Case 4: The target object is not held by the server, but the nearest
naming context contains a referral object which the target object
is subordinate to.
@ -435,6 +444,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
modified by the alias dereferencing such that the return URL refers to
the new target object per [RFC2251, 4.1.11].
Zeilenga LDAP NamedRef [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Critical extensions MUST NOT be trimmed nor modified.
Case 1: The base object is not held by the server and is not within
@ -444,21 +461,15 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
a non-existent base which not within any naming context of the
server (generally return a superior referral or noSuchObject).
This document does not detail management or processing of superior
Zeilenga LDAP NamedRef [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
knowledge references.
Case 2: The base object is held by the server and is a referral
object.
The server SHOULD return the URI value contained in the ref
attribute of the referral object.
attribute of the referral object appropriately modified as
described above.
Example: If the client issues a subtree search in which the base
object is "OU=Roles,O=MNN,C=WW", the server will return
@ -490,6 +501,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
server SHOULD return a referral response which is constructed from
the URI portion of the ref value of the referral object.
Zeilenga LDAP NamedRef [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Example: If the client issues a base search request for
"CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
@ -501,13 +519,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
of subtree, the returned LDAP URL would explicitly specify "sub"
or "one", respectively, instead of "base".
Zeilenga LDAP NamedRef [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
Note that the DN part of the LDAP URL is modified such that it
refers to the appropriate entry in the referenced server.
@ -545,6 +556,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
Zeilenga LDAP NamedRef [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
SearchResultDone (success)
One Level Example:
@ -556,14 +575,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
possible sequence is shown:
SearchResultReference {
Zeilenga LDAP NamedRef [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
ldap://hostb/OU=People,O=MNN,C=WW??base
ldap://hostc/OU=People,O=MNN,C=WW??base
}
@ -586,13 +597,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
5.6.1 Bind
Servers SHOULD NOT return referral result code if the bind name (or
other identity in the DN form) is (or is subordinate to) a referral
object but MAY use the knowledge information to process the bind
request (such as in support a future distributed operation
specification). Where the server makes no use of the knowledge
information, the server processes the request normally as appropriate
for a non-existent authentication or authorization identity (e.g.
return invalidCredentials).
authentication identity or authorization identity) is (or is
subordinate to) a referral object but MAY use the knowledge
information to process the bind request (such as in support a future
distributed operation specification). Where the server makes no use
of the knowledge information, the server processes the request
normally as appropriate for a non-existent authentication or
authorization identity (e.g., return invalidCredentials).
5.6.2 Modify DN
@ -603,6 +614,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
return affectsMultipleDSAs instead of entryAlreadyExists.
Zeilenga LDAP NamedRef [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
6. Security Considerations
This document defines mechanisms that can be used to tie LDAP (and
@ -612,14 +629,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
protected from unauthorized disclosure as well.
Zeilenga LDAP NamedRef [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
7. Acknowledgments
This document borrows heavily from previous work by IETF LDAPext
@ -636,14 +645,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
<Kurt@OpenLDAP.org>
References
9. Normative References
[RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", RFC 2119 (Also BCP 14), March 1997.
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.
@ -659,24 +668,27 @@ References
[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
[RFC2396] Berners-Lee, T., R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models, and Services", 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Zeilenga LDAP NamedRef [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Definition", 1993.
[RFC2396] Berners-Lee, T., R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[X.501] ITU-T, "The Directory: Models", X.501, 1993.
10. Informative References
[X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
Services", X.500, 1993.
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.500,
1993.
Copyright 2001, The Internet Society. All Rights Reserved.
@ -711,18 +723,6 @@ Copyright 2001, The Internet Society. All Rights Reserved.

164
doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 26 December 2001 26 June 2001
Expires in six months 17 May 2002
LDAPv3: All Operational Attributes
<draft-zeilenga-ldap-opattrs-01.txt>
<draft-zeilenga-ldap-opattrs-03.txt>
Status of this Memo
@ -39,12 +39,27 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved.
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 does 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]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
1. Overview
X.500 [X.500] provides a mechanism for clients to request all
@ -52,24 +67,15 @@ Status of this Memo
to a search operation. This mechanism is often used by clients to
discover which operational attributes are present in an entry.
Zeilenga LDAP All Op Attrs [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
This documents updates LDAP [RFC2251] to provide a simple mechanism
This documents extends LDAP [RFC2251] to provide a simple mechanism
which clients may use to request the return of all operation
attributes. The mechanism is designed for use with existing general
purpose LDAP clients (including web browsers which support LDAP URLs)
and existing LDAP API.
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
this document are to be interpreted as described in RFC 2119
[RFC2119].
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
@ -86,7 +92,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
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 supportedFeatures [FEATURES]
1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
@ -102,6 +108,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
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
Zeilenga LDAP All Op Attrs [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
[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.
@ -110,12 +124,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
modification of existing LDAP APIs.
Zeilenga LDAP All Op Attrs [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
4. Security Considerations
This document provides a mechanism which clients may use to discover
@ -124,7 +132,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
operational attributes per local policy.
5. Acknowledgment
5. IANA Considerations
No IANA assignments are requested.
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.
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
@ -138,83 +156,65 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
<Kurt@OpenLDAP.org>
References
8. Normative References
[RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[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.
[RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
ldap-features-xx.txt (a work in progress).
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
Copyright 2001, 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
Zeilenga LDAP All Op Attrs [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
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.
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 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.
[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
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.

402
doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 13 May 2002 13 November 2001
Expires in six months 1 March 2002
Obsoletes: RFC 2596
Language Tags and Ranges in LDAP
draft-zeilenga-ldap-rfc2596-00.txt
draft-zeilenga-ldap-rfc2596-01.txt
Status of Memo
@ -40,36 +40,36 @@ Status of Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
This document details the use of Language Tags and Ranges in LDAP.
This document replaces RFC 2596.
It is often desirable to to be able to indicate the natural language
associated with values held in a directory and to be able to query the
directory for values which fulfill the user's language needs. This
document details the use of Language Tags and Ranges in the
Lightweight Directory Access Protocol (LDAP).
Zeilenga Language Tags and Ranges in LDAP [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Use
The Lightweight Directory Access Protocol (LDAP) [LDAPTS] provides a
The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
means for clients to interrogate and modify information stored in a
distributed directory system. The information in the directory is
maintained as attributes of entries. Most of these attributes have
@ -85,7 +85,13 @@ Conventions
This document replaces RFC 2596. Appendix A summaries changes made
since RFC 2596.
The remainder of this section provides a summary of Langauge Tags,
Appendix B discusses differences from X.500(1997) "contexts"
mechanism.
Appendix A and B are provided for information purposes and are not a
normative part of this specification.
The remainder of this section provides a summary of Language Tags,
Language Ranges, and Attribute Descriptions.
@ -102,20 +108,20 @@ Conventions
1.2. Language Ranges
Zeilenga Language Tags and Ranges in LDAP [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Language ranges are used to specify sets of language tags.
A language range matches a language tag if it exactly equals the tag,
or if it exactly equals a prefix of the tag such that the first
character following the prefix is "-". The special tag "*" matches
Zeilenga Language Tags and Ranges in LDAP [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
all tags.
Due to restrictions upon option naming in LDAP, this document uses a
@ -127,33 +133,51 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
1.3. Attribute Descriptions
An attribute consists of a type, a list of "subtyping" (or "tag")
options for that type, and a set of one or more values. The type and
the options are combined into the AttributeDescription, defined in
section 4.1.5 of RFC 2251 [RFC2251]. AttributeDescription may also
contain options which are not part of the attribute, but indicate some
function such as the transfer encoding.
This section provides an overview of attributes in LDAP. LDAP
attributes are defined in [Models].
In summary, an attribute with "subtyping" (or "tag") options is
treated as a subtype of the attribute without the options. If a
server does not support any of the options, the attribute is treated
as an unrecognized attribute.
An attribute consists of a type, a set of zero or more associated
tagging options, and a set of one or more values. The type and the
options are combined into the AttributeDescription.
AttributeDescriptions can also contain options which are not part of
the attribute, but indicate some other function such as the transfer
encoding.
An attribute with one or more tagging options is a direct subtype of
each attribute of the same with all but one of the tagging options.
If the attribute's type is a direct subtype of some other type, then
the attribute is also a direct subtype of the attribute whose
description consists of the the supertype and all of the tagging
options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
If the attribute description contains an unrecognized option, the
attribute description is treated as an unrecognized attribute type.
As language tags are intended to stored with the attribute, they are
to treated as "subtyping" (or "tag") options. Language range are used
only to match against language ranges and are not stored with the
attribute, they are not treated "subtyping" (or "tag") options but as
detailed in Section 3 of this document.
to treated as tagging options as described in Section 2. Language
range are used only to match against language ranges and are not
stored with the attribute. They are not treated tagging options (nor
as transfer options), but as described in Section 3.
2. Use of Language Tags in LDAP
This section describes how LDAP implementations MUST interpret
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
language tags in performing operations.
Servers which support storing attributes with language tag in the DIT
SHOULD allow any attribute type it recognizes that has the Directory
String syntax to have language tag options associated with it.
Servers which support storing attributes with language tag options in
the Directory Information Tree (DIT) SHOULD allow any attribute type
it recognizes that has the Directory String, IA5 String, or other
textual string syntax to have language tag options associated with it.
Servers MAY allow language options to be associated with other
attributes types.
@ -161,33 +185,48 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
with language tags in the directory.
Implementations MUST NOT otherwise interpret the structure of the tag
when comparing two tag, and MUST treat them as simply strings of
when comparing two tag, and MUST treat them simply as strings of
characters. Implementations MUST allow any arbitrary string which
conforms to the syntax defined in BCP 47 to be used as a language tag.
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
conforms to the syntax defined in BCP 47 [RFC3066] to be used as a
language tag.
2.1. Language Tag Options
A language tag option associates a natural language with values for
that attribute. An attribute description may contain multiple
language tag options. An entry may contain multiple attributes with
same attribute type but different language tag (and other) options.
A language tag option associates a natural language with values of an
attribute. An attribute description MAY contain multiple language tag
options. An entry MAY contain multiple attributes with same attribute
type but different combinations of language tag (and other) options.
A language tag option conforms to the following ABNF [RFC2234]:
language-tag-option = "lang-" Language-Tag
where the Language-Tag production is as defined in BCP 47 [RFC3066].
This production and those it imports from [RFC2234] are provided here
for convenience:
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
A language tag option is a tagging option [Models]. A language tag
option has no effect on the syntax of the attribute's values nor their
transfer encoding.
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
A language tag option is a "subtyping" (or "tag") option [RFC2251bis].
A language tag option has no effect on the tranfer encoding nor on the
syntax of the attribute values.
Examples of valid AttributeDescription:
@ -204,7 +243,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
2.2. Search Filter
If langugage tag options are present in an AttributeDescription in an
If language tag options are present in an AttributeDescription in an
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains each of the presented (and possibly
@ -220,33 +259,33 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (wrong value)
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
Client implementors should however note that providing a language tag
option in a search filter AttributeDescription will often filter out
desirable values where the tag does not match exactly. For example,
the filter (name;lang-en=Billy Ray) does NOT match the attribute
"name;lang-en-US: Billy Ray".
It is noted that providing a language tag option in a search filter
AttributeDescription will filter out desirable values where the tag
does not match exactly. For example, the filter (name;lang-en=Billy
Ray) does NOT match the attribute "name;lang-en-US: Billy Ray".
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language tag
option will not match as it is an unrecognized attribute type. No
error would be returned because of this; a presence filter would
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
option will not match as such it is an unrecognized attribute type.
No error would be returned because of this; a presence assertion would
evaluate to FALSE and all other assertions to Undefined.
If no options are specified in the assertion, then only the base
@ -276,14 +315,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
If language tag options are provided in an attribute description, then
only attributes in a directory entry whose attribute descriptions have
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
the same attribute type or its subtype and the provided language tags
options are to be returned. Thus if a client requests just the
attribute "name;lang-en", the server would return "name;lang-en" and
@ -302,6 +333,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
include language tag options are to be ignored, just as if they were
unknown attribute types.
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
If a request is made specifying all attributes or an attribute is
requested without providing a language tag option, then all attribute
values regardless of their language tag option are returned.
@ -330,16 +368,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
Language tag options can be present in an AttributeDescription used in
a compare request AttributeValueAssertion. This is to be treated by
servers the same as the use of language tag options in a search filter
with an equality match, as described in section 2.2. If there is no
with an equality match, as described in Section 2.2. If there is no
attribute in the entry with the same subtype and language tag options,
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name" and assertion value
@ -358,6 +388,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
options in the DIT, then any comparison which includes a language tag
option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
@ -388,14 +426,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
If a server does not support storing language tag options with
attribute values in the DIT, then it MUST treat an
AttributeDescription with a language tag option as an unrecognized
@ -414,6 +444,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
"delete", then if the stored values to be deleted have language tag
options, then those language tag options MUST be provided in the
modify operation, and if the stored values to be deleted do not have
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
any language tag option, then no language tag option is to be
provided.
@ -428,7 +466,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
Since the publication of RFC 2596, it has become apparent that there
is a need to provide a mechanism for a client to request attributes
based upon set of language tag options whose tags all begin with the
same sequence of subtags.
same sequence of language sub-tags.
AttributeDescriptions containing language range options are intended
to be used in attribute value assertions, search attribute lists, and
@ -436,22 +474,26 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
description matching of a range of language tags associated with
attributes.
A language range option conforms to the following ABNF [RFC 2234]:
A language range option conforms to the following ABNF [RFC2234]:
language-range-option = "lang-" [ Language-Tag "-" ]
where the Language-Tag production is as defined in BCP 47 [RFC3066].
This production and those it imports from [RFC2234] are provided here
for convenience:
A language range option matches a langugage tag option if language
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
A language range option matches a language tag option if language
range option less the trailing "-" matches exactly the language tag or
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
if the language range option (including the trailing "-") matches a
prefix of the language tag option. Note that the language range
option "lang-" matches all language tag options.
@ -459,17 +501,23 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
Examples of valid AttributeDescription containing language range
options:
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
givenName;lang-en-
CN;lang-
O;lang-x-;x-foobar
A language range option is not a "subtyping" (or "tag") option
[RFC2251bis]. Attributes cannot be stored with language range
options. Any attempt to add or update an attribute description with a
languague range option SHALL be treated as an undefined attribute type
and result in an error.
A language range option is not a tagging option. Attributes cannot be
stored with language range options. Any attempt to add or update an
attribute description with a language range option SHALL be treated as
an undefined attribute type and result in an error.
A language range option has no effect on the tranfer encoding nor on
A language range option has no effect on the transfer encoding nor on
the syntax of the attribute values.
Servers SHOULD support assertion of language ranges for any attribute
@ -478,8 +526,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
3.1. Search Filter
If a langugage range option is present in an AttributeDescription in
an assertion, then for each entry within scope, the values of each
If a language range option is present in an AttributeDescription in an
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains a language tag option matching the
language range option are to be returned.
@ -498,15 +546,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (wrong value)
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
@ -517,6 +558,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
evaluate to FALSE and all other assertions to Undefined.
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
3.2. Requested Attributes in Search
Clients can provide language range options in AttributeDescription in
@ -548,7 +595,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
Language range options can be present in an AttributeDescription used
in a compare request AttributeValueAssertion. This is to be treated
by servers the same as the use of language range options in a search
filter with an equality match, as described in section 3.1. If there
filter with an equality match, as described in Section 3.1. If there
is no attribute in the entry with the same subtype and a matching
language tag option, the noSuchAttributeType error will be returned.
@ -556,14 +603,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
value "Johann", against the entry with the following attributes:
objectclass: top
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
objectclass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
@ -573,6 +612,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
range option "lang-" matches any language tag option.)
However, if the client issued a compare request of type "name;lang-de"
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
and assertion value "Sibelius" against the above entry, the request
would fail with the noSuchAttributeType error.
@ -594,95 +641,98 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
the root DSE.
A server MAY restrict use of language tag options to a subset of the
attribute types it recongizes. This document does not define a
attribute types it recognizes. This document does not define a
mechanism for determining which subset of attribute types can be used
with language tag options.
5. Security Considerations
There are no known security considerations for this document. See the
security considerations sections of [LDAPTS] for security
considerations of LDAP in general.
Language tags and range options are used solely to indicate the native
language of values and in querying the directory for values which
fulfill the user's language needed. These options are not known to
raise specific security considerations. However, the reader should
consider general directory security issues detailed in the LDAP
technical specification [Roadmap].
6. Acknowledgements
6. Acknowledgments
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
This document borrows from a number of IETF documents including BCP
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
47.
7. References
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Zeilenga Language Tags and Ranges in LDAP [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251bis] Sermersheim, J., "Lightweight Directory Access Protocol
(v3)", draft-ietf-ldapbis-protocol-xx.txt (a work in
progress).
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47 (also RFC 3066), January 2001.
[LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-00.txt (a work in progress).
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
A. Differences from RFC 2596
8. Informative References
This document adds support for language ranges, provides a mechansism
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
Appendix A. Differences from RFC 2596
This document adds support for language ranges, provides a mechanism
that a client can use to discover whether a server supports language
tags, and clarifies how attributes with multiple language tags are to
be treated. This document is a significant rewrite of RFC 2596.
tags and ranges, and clarifies how attributes with multiple language
tags are to be treated. This document is a significant rewrite of RFC
2596.
B. Differences from X.500(1997)
Appendix B. Differences from X.500(1997)
X.500(1997) defines a different mechanism, contexts, as the means of
representing language tags (codes). This section summarizes the major
differences in approach.
X.500(1997) [X.501] defines a different mechanism, contexts, as the
means of representing language tags (codes). This section summarizes
the major differences in approach.
a) An X.500 operation which has specified a language code on a value
matches a value in the directory without a language code.
b) LDAP references BCP 47 [RFC3066], which allows for IANA
registration of new tags as well as unregistered tags.
c) LDAP supports language ranges.
Zeilenga Language Tags and Ranges in LDAP [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
d) LDAP does not allow language tags (and ranges) in distinguished
names.
e) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
Copyright 2001, The Internet Society. All Rights Reserved.
Zeilenga Language Tags and Ranges in LDAP [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
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
@ -727,5 +777,11 @@ Copyright 2001, The Internet Society. All Rights Reserved.
Zeilenga Language Tags and Ranges in LDAP [Page 13]
Zeilenga Language Tags and Ranges in LDAP [Page 14]

619
doc/drafts/draft-zeilenga-ldap-subentry-xx.txt Normal file
View file

@ -0,0 +1,619 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Date: 17 May 2002 Steven Legg
Expires in six months Adacel Technologies
Subentries in LDAP
<draft-zeilenga-ldap-subentry-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 Extension Working Group
mailing list <ietf-ldapext@netscape.com>. 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-05 [Page 1]
INTERNET-DRAFT Subentries in LDAP 17 May 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-05 [Page 2]
INTERNET-DRAFT Subentries in LDAP 17 May 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-05 [Page 3]
INTERNET-DRAFT Subentries in LDAP 17 May 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-05 [Page 4]
INTERNET-DRAFT Subentries in LDAP 17 May 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-05 [Page 5]
INTERNET-DRAFT Subentries in LDAP 17 May 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-05 [Page 6]
INTERNET-DRAFT Subentries in LDAP 17 May 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 the LDAP descriptors used in this
document per the following registration template:
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
subtreeSpecification A 2.5.18.6
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 7]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
where Type A is Attribute, Type O is ObjectClass, and Type R is
Administrative Role.
5.2 Object Identifiers
No IANA assignment of object identifiers is requested.
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.
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. 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.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 8]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
[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.
[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.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 9]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
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 base ]
[ sep sp specificExclusions ]
[ sep sp minimum ]
[ sep sp maximum ]
[ sep sp specificationFilter ]
sp "}"
base = id-base msp LocalName
specificExclusions = id-specificExclusions msp SpecificExclusions
minimum = id-minimum msp BaseDistance
maximum = id-maximum msp BaseDistance
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
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 10]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
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
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
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-05 [Page 11]

227
doc/drafts/draft-zeilenga-ldap-t-f-02.txt Normal file
View file

@ -0,0 +1,227 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
LDAP True/False Filters
<draft-zeilenga-ldap-t-f-02.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 <ietf-ldapext@netscape.com>. 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
This document extends the Lightweight Directory Access Protocol (LDAP)
to support absolute True and False filters based upon similar
capabilities found in X.500 directory systems. The document also
extends the String Representation of LDAP Search Filters to support
these filters.
Zeilenga LDAP True/False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
1. Background and Intended Use
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
True and False assertions. An 'and' filter with zero elements always
evaluates to True. An 'or' filter with zero elements always evaluates
to False. These filters are commonly used when requesting DSA-
specific Entries (DSEs) which do not necessarily have objectClass
attributes. That is, where "(objectClass=*)" may evaluate to False.
While LDAPv2 [RFC1777] placed no restriction on the number of elements
in 'and' and 'or' filter sets, the LDAPv2 string representation
[RFC1960] could not represent empty 'and' and 'or' filter sets. Due
to this, LDAPv3 [RFC2251] required 'and' and 'or' filter sets to have
at least one element. Hence, LDAPv3 does not provide absolute True or
False filters.
This documents extends LDAPv3 [RFC2251] to support absolute True and
False matches by allowing empty 'and' and 'or' and extends the filter
string representation [RFC2254] to allow empty filter lists.
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. Absolute True and False Filters
Implementations of this extension SHALL allow 'and' and 'or' choices
with zero filter elements.
An 'and' Filter consisting of an empty set of filters SHALL evaluate
to True. This filter is to represented by the string "(&)".
An 'or' Filter consisting of an empty set of filters SHALL evaluate to
False. This filter is to represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.3 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
3. Security Considerations
The (re)introduction of absolute True and False filters does not raise
any new security considerations.
Zeilenga LDAP True/False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
Implementors of this (or any) LDAP extension should be familiar with
general LDAP general security considerations [LDAPTS].
4. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.5.3 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.
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
6. 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.
[RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
7. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.
[RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1960, June 1996.
Zeilenga LDAP True/False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 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
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 True/False Filters [Page 4]

562
doc/drafts/draft-zeilenga-ldap-user-schema-xx.txt
View file

@ -6,14 +6,13 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 22 April 2002 22 October 2001
Expires in six months 17 May 2002
Obsoletes: RFC 1274
Updates: RFC 2798
LDAPv3: A Collection of User Schema
<draft-zeilenga-ldap-user-schema-03.txt>
<draft-zeilenga-ldap-user-schema-06.txt>
Status of this Memo
@ -41,7 +40,7 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
@ -50,14 +49,15 @@ Status of this Memo
Abstract
This document provides a collection of user schema elements for use
with LDAP collected from numerous sources including RFC 1274, X.501,
and X.520.
with LDAP (Lightweight Directory Access Protocol) from both ITU-T
Recommendations for the X.500 Directory and COSINE and Internet X.500
pilot projects.
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 1]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 1]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
Conventions
@ -66,9 +66,9 @@ Conventions
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
interpreted as described in [RFC2119].
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].
Table of Contents (to be expanded by editor)
@ -86,63 +86,63 @@ Table of Contents (to be expanded by editor)
2.5. caseIgnoreListSubstringsMatch
2.6. directoryStringFirstComponentMatch 5
2.7. integerOrderingMatch
2.7. keywordMatch
2.8. keywordMatch
2.9. numericStringOrderingMatch 6
2.10. octetStringOrderingMatch
2.11. storedPrefixMatch
2.12. wordMatch 7
2.12. wordMatch 7
3. Attribute Types
3.1. associatedDomain
3.2. associatedName
3.3. buildingName
3.3. co 8
3.4. destinationIndicator
3.5. documentAuthor
3.6. documentIdentifier 9
3.6. documentIdentifier
3.7. documentLocation
3.8. documentPublisher
3.8. documentPublisher 9
3.9. documentTitle
3.10. documentVersion
3.11. drink 10
3.12. houseIdentifier
3.13. homePhone
3.14. homePostalAddress
3.15. host 11
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 2]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.11. drink
3.12. homePhone 10
3.13. homePostalAddress
3.14. host
3.16. info
3.17. mail
3.18. manager 12
3.17. mail 11
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 2]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
3.18. manager
3.19. mobile
3.20. organizationalStatus
3.21. otherMailbox
3.22. pager 13
3.21. otherMailbox 12
3.22. pager
3.23. personalTitle
3.24. roomNumber
3.24. roomNumber 13
3.25. secretary
3.26. uid 14
3.26. uid
3.27. uniqueIdentifier
3.28. userClass
4. Object Classes 15
3.28. userClass 14
4. Object Classes
4.1. account
4.2. document
4.2. document 15
4.3. documentSeries
4.4. domainRelatedObject 16
4.4. domainRelatedObject
4.5. friendlyCountry
4.6. rFC822LocalPart
4.7. room 17
4.6. rFC822LocalPart 16
4.7. room
4.8. simpleSecurityObject
5. Security Considerations
6. Acknowledgements
7. Author's Address
References 18
Full Copyright 19
5. Security Considerations 17
6. IANA Considerations
7. Acknowledgments 19
8. Author's Address
9. Normative References
10. Informative References
Full Copyright 20
1. Background and Intended Use
@ -154,10 +154,10 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
COSINE and Internet X.500 pilot projects [RFC1274]. This document
obsoletes RFC 1274.
This document contains a summary of X.500 user schema [X.520] not
included in LDAPv3 [RFC2252][RFC2256]. Some of these items were
This document includes a summary of X.500 user schema [X.520] not
previously specified for use with LDAP. Some of these items were
described in the inetOrgPerson [RFC2798] schema. This document
supercedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
RFC 2798.
@ -167,9 +167,9 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 3]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 3]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
their X.500 counterparts.
@ -208,9 +208,9 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2.3. caseExactSubstringsMatch
2.4. caseExactSubstringsMatch
CaseExactSubstringsMatch determines whether the asserted value are
CaseExactSubstringsMatch determines whether the asserted value(s) are
substrings of an attribute value of DirectoryString syntax. The rule
is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except
that case is not ignored. (Source: X.520)
@ -219,13 +219,13 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2.4. caseIgnoreListSubstringsMatch
2.5. caseIgnoreListSubstringsMatch
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 4]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 4]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
CaseIgnoreListSubstringMatch compares the asserted substring with an
@ -243,7 +243,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2.5. directoryStringFirstComponentMatch
2.6. directoryStringFirstComponentMatch
DirectoryStringFirstComponentMatch compares for equality the asserted
DirectoryString value with an attribute value of type SEQUENCE whose
@ -258,7 +258,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2.6. integerOrderingMatch
2.7. integerOrderingMatch
The integerOrderingMatch rule compares the ordering of the asserted
integer with an attribute value of Integer syntax. The rule returns
@ -269,7 +269,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2.7. keywordMatch
2.8. keywordMatch
The keywordMatch rule compares the asserted string with keywords in an
attribute value of DirectoryString syntax. The rule returns TRUE if
@ -279,9 +279,9 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 5]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 5]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
X.520)
@ -290,7 +290,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2.8. numericStringOrderingMatch
2.9. numericStringOrderingMatch
NumericStringOrderingMatch compares the collation order of the
asserted string with an attribute value of NumericString syntax. The
@ -298,11 +298,11 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
that all space characters are skipped during comparison (case is
irrelevant as characters are numeric). (Source: X.520)
( 2.5.13.9 NAME 'NumericStringOrderingMatch'
( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2.9. octetStringOrderingMatch
2.10. octetStringOrderingMatch
OctetStringOrderingMatch compares the collation order of the asserted
octet string with an attribute value of OCTET STRING syntax. The rule
@ -317,7 +317,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2.10. storedPrefixMatch
2.11. storedPrefixMatch
StoredPrefixMatch determines whether an attribute value, whose syntax
is DirectoryString, is a prefix (i.e. initial substring) of the
@ -335,15 +335,15 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 6]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 6]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
which is a telephone number.
2.11. wordMatch
2.12. wordMatch
The wordMatch rule compares the asserted string with words in an
attribute value of DirectoryString syntax. The rule returns TRUE if
@ -358,8 +358,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3. Attribute Types
This section details attribute types for use in LDAP based upon their
X.500 descriptions.
This section details attribute types for use in LDAP.
3.1. associatedDomain
@ -388,15 +387,15 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.3. buildingName
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 7]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
The buildingName attribute type specifies the name of the building
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 7]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
where an organization or organizational unit is based. (Source: RFC
1274)
@ -409,8 +408,9 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.3. co
The co (Friendly Country Name) attribute type specifies names of
countries in human readable format. The standard attribute country
name must be one of the two-letter codes defined in [ISO 3166].
countries in human readable format. It is commonly used in
conjunction with the c (Country Name) [RFC2256] attribute type (which
restricted to one of the two-letter codes defined in [ISO3166]).
(Source: RFC 1274)
( 0.9.2342.19200300.100.1.43
@ -420,21 +420,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
3.4. destinationIndicator
The destinationIndicator attribute type specifies (according to CCITT
Recommendation F.1 and CCITT Recommendation F.31) the country and city
associated with the object (the addressee) needed to provide the
Public Telegram Service. An attribute value for Destination Indicator
is a printable string containing only alphabetical characters.
(Source: X.520)
( 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
3.5. documentAuthor
The documentAuthor attribute type specifies the distinguished name of
@ -445,13 +430,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 8]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.6. documentIdentifier
The documentIdentifier attribute type specifies a unique identifier
@ -466,6 +444,14 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.7. documentLocation
The documentLocation attribute type specifies the location of the
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 8]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
document original. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
@ -501,13 +487,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
The documentVersion attribute type specifies the version number of a
document. (Source: RFC 1274)
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 9]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
@ -521,25 +500,19 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' )
EQUALITY caseIgnoreMatch
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 9]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
3.12. houseIdentifier
The houseIdentifier attribute type specifies a linguistic construct
used to identify a particular building, for example a house number or
house name relative to a street, avenue, town or city, etc. An
attribute value for houseIdentifier is a string, e.g. "14". (Source:
X.520)
( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
3.13. homePhone
3.12. homePhone
The homePhone (Home Telephone Number) attribute type specifies a home
telephone number (e.g., "+44 71 123 4567") associated with a person.
@ -552,18 +525,10 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
3.14. homePostalAddress
3.13. homePostalAddress
The homePostalAddress attribute type specifies a home postal address
for an object. This should be limited to up to 6 lines of 30
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 10]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
for an object. This SHOULD be limited to up to 6 lines of 30
characters each. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.39
@ -573,7 +538,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
3.15. host
3.14. host
The host attribute type specifies a host computer. (Source: RFC 1274)
@ -590,8 +555,17 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
information pertinent to an object. It is RECOMMENDED that specific
usage of this attribute type is avoided, and that specific
requirements are met by other (possibly additional) attribute types.
It is noted the description attribute [RFC2256] for specifying
descriptive information pertinent to an object. (Source: RFC 1274)
Note that the description attribute type [RFC2256] is available for
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 10]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
specifying descriptive information pertinent to an object. (Source:
RFC 1274)
( 0.9.2342.19200300.100.1.4
NAME 'info'
@ -603,7 +577,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.17. mail
The mail (rfc822mailbox) attribute type holds an the electronic mail
address in RFC822 form (e.g.: user@example.com). Note that this
address in [RFC822] form (e.g.: user@example.com). Note that this
attribute SHOULD NOT be used to hold non-Internet addresses. (Source:
RFC 1274)
@ -612,14 +586,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
NAME ( 'mail' 'rfc822Mailbox' )
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 11]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
@ -647,6 +613,13 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 11]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
3.20. organizationalStatus
The organizationalStatus attribute type specifies a category by which
@ -654,9 +627,9 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
in academia might include undergraduate student, researcher, lecturer,
etc.
A Directory administrator should probably consider carefully the
distinctions between this and the title and userClass attributes.
(Source: RFC 1274)
A Directory administrator SHOULD consider carefully the distinctions
between this and the title and userClass attributes. (Source: RFC
1274)
( 0.9.2342.19200300.100.1.45
NAME 'organizationalStatus'
@ -668,14 +641,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.21. otherMailbox
The otherMailbox attribute type specifies values for electronic
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 12]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
mailbox types other than X.400 and RFC822. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.22
@ -703,6 +668,14 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
"Prof". (Source: RFC 1274)
( 0.9.2342.19200300.100.1.40
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 12]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
NAME 'personalTitle'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
@ -712,8 +685,8 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.24. roomNumber
The roomNumber attribute type specifies the room number of an object.
Note that the cn (commonName) attribute should be used for naming room
objects. (Source: RFC 1274)
Note that the cn (commonName) attribute type SHOULD be used for naming
room objects. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.6
NAME 'roomNumber'
@ -724,14 +697,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
3.25. secretary
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 13]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
The secretary attribute type specifies the secretary of a person. The
attribute value for Secretary is a distinguished name. (Source: RFC
1274)
@ -759,12 +724,20 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
The Unique Identifier attribute type specifies a "unique identifier"
for an object represented in the Directory. The domain within which
the identifier is unique, and the exact semantics of the identifier,
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 13]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
are for local definition. For a person, this might be an institution-
wide payroll number. For an organizational unit, it might be a
department code. An attribute value for uniqueIdentifier is a
directoryString. (Source: RFC 1274)
( 2.5.4.45 NAME 'uniqueIdentifier'
( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
@ -780,17 +753,10 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
The userClass attribute type specifies a category of computer user.
The semantics placed on this attribute are for local interpretation.
Examples of current usage od this attribute in academia are
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 14]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
undergraduate student, researcher, lecturer, etc. Note that the
organizationalStatus attribute may now often be preferred as it makes
no distinction between computer users and others. (Source: RFC 1274)
organizationalStatus attribute type is now often be preferred as it
makes no distinction between computer users and others. (Source: RFC
1274)
( 0.9.2342.19200300.100.1.8 NAME 'userClass'
EQUALITY caseIgnoreMatch
@ -800,13 +766,13 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
4. Object Classes
This section details attribute types for use in LDAP based upon their
X.500 descriptions.
This section details object classes for use in LDAP.
4.1. account
The account object class is used to define entries representing
computer accounts. The uid (userid) attribute should be used for
computer accounts. The uid (userid) attribute SHOULD be used for
naming entries of this object class. (Source: RFC 1274)
( 0.9.2342.19200300.100.4.5
@ -816,6 +782,12 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 14]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
4.2. document
The document object class is used to define entries which represent
@ -836,14 +808,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
represents a series of documents (e.g., The Request For Comments
memos). (Source: RFC 1274)
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 15]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
( 0.9.2342.19200300.100.4.9
NAME 'documentSeries'
SUP top STRUCTURAL
@ -868,11 +832,18 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
The friendlyCountry object class is used to define country entries in
the DIT. The object class is used to allow friendlier naming of
countries than that allowed by the object class country. The naming
attribute of object class country, c (countryName), has to be a 2
letter string defined in [ISO3166]. (Source: RFC 1274)
countries than that allowed by the object class country [RFC2256].
(Source: RFC 1274)
( 0.9.2342.19200300.100.4.18
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 15]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
NAME 'friendlyCountry'
SUP country STRUCTURAL
MUST co )
@ -881,8 +852,8 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
4.6. rFC822LocalPart
The rFC822LocalPart object class is used to define entries which
represent the local part of RFC822 mail addresses. This treats this
part of an RFC822 address as a domain [RFC2247]. (Source: RFC 1274)
represent the local part of [RFC822] mail addresses. This treats this
part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274)
( 0.9.2342.19200300.100.4.14
NAME 'rFC822localPart'
@ -892,14 +863,6 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
physicalDeliveryOfficeName $ postalAddress $
postalCode $ postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ seeAlso $ sn $ street $
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 16]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ x121Address ) )
@ -907,7 +870,7 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
4.7. room
The room object class is used to define entries representing rooms.
The cn (commonName) attribute should be used for naming entries of
The cn (commonName) attribute SHOULD be used for naming entries of
this object class. (Source: RFC 1274)
( 0.9.2342.19200300.100.4.7 NAME 'room'
@ -919,14 +882,24 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
4.8. simpleSecurityObject
The simpleSecurityObject object class is used to allow an entry to
have a userPassword attribute when an entry's principal object classes
do not allow userPassword as an attribute type. (Source: RFC 1274)
The simpleSecurityObject object class is used to require an entry to
have a userPassword attribute when the entry's structural object class
does not require (or allow) the userPassword attribute. (Source: RFC
1274)
( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
SUP top AUXILIARY
MUST userPassword )
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 16]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
Note: Security considerations related to the use of simple
authentication mechanisms in LDAP are discussed in RFC 2829
[RFC2829].
@ -939,44 +912,134 @@ INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
appropriate.
6. Acknowledgements
6. IANA Considerations
It is requested that IANA update the LDAP descriptors registry as
indicated the following template:
Subject: Request for LDAP Descriptor Registration Update
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:
The following descriptors should be added:
NAME Type OID
------------------------ ---- ---------
booleanMatch M 2.5.13.13
caseExactMatch M 2.5.13.5
caseExactOrderingMatch M 2.5.13.6
caseExactSubstringsMatch M 2.5.13.7
caseIgnoreListSubstringsMatch M 2.5.13.12
directoryStringFirstComponentMatch M 2.5.13.31
integerOrderingMatch M 2.5.13.15
keywordMatch M 2.5.13.32
numericStringOrderingMatch M 2.5.13.9
octetStringOrderingMatch M 2.5.13.18
storedPrefixMatch M 2.5.13.41
wordMatch M 2.5.13.32
The following descriptors should be updated to refer to RFC XXXX.
NAME Type OID
------------------------ ---- --------------------------
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 17]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
account O 0.9.2342.19200300.100.4.5
associatedDomain A 0.9.2342.19200300.100.1.37
associatedName A 0.9.2342.19200300.100.1.38
buildingName A 0.9.2342.19200300.100.1.48
co A 0.9.2342.19200300.100.1.43
document O 0.9.2342.19200300.100.4.6
documentAuthor A 0.9.2342.19200300.100.1.14
documentIdentifier A 0.9.2342.19200300.100.1.11
documentLocation A 0.9.2342.19200300.100.1.15
documentPublisher A 0.9.2342.19200300.100.1.56
documentSeries O 0.9.2342.19200300.100.4.8
documentTitle A 0.9.2342.19200300.100.1.12
documentVersion A 0.9.2342.19200300.100.1.13
domainRelatedObject O 0.9.2342.19200300.100.4.17
drink A 0.9.2342.19200300.100.1.5
favouriteDrink A 0.9.2342.19200300.100.1.5
friendlyCountry O 0.9.2342.19200300.100.4.18
friendlyCountryName A 0.9.2342.19200300.100.1.43
homePhone A 0.9.2342.19200300.100.1.20
homePostalAddress A 0.9.2342.19200300.100.1.39
homeTelephone A 0.9.2342.19200300.100.1.20
host A 0.9.2342.19200300.100.1.9
info A 0.9.2342.19200300.100.1.4
mail A 0.9.2342.19200300.100.1.3
manager A 0.9.2342.19200300.100.1.10
mobile A 0.9.2342.19200300.100.1.41
mobileTelephoneNumber A 0.9.2342.19200300.100.1.41
organizationalStatus A 0.9.2342.19200300.100.1.45
otherMailbox A 0.9.2342.19200300.100.1.22
pager A 0.9.2342.19200300.100.1.42
pagerTelephoneNumber A 0.9.2342.19200300.100.1.42
personalTitle A 0.9.2342.19200300.100.1.40
RFC822LocalPart O 0.9.2342.19200300.100.4.14
RFC822Mailbox A 0.9.2342.19200300.100.1.3
room O 0.9.2342.19200300.100.4.7
roomNumber A 0.9.2342.19200300.100.1.6
secretary A 0.9.2342.19200300.100.1.21
simpleSecurityObject O 0.9.2342.19200300.100.4.19
singleLevelQuality A 0.9.2342.19200300.100.1.50
uid A 0.9.2342.19200300.100.1.1
uniqueIdentifier A 0.9.2342.19200300.100.1.44
userClass A 0.9.2342.19200300.100.1.8
userId A 0.9.2342.19200300.100.1.1
where Type A is Attribute, Type O is ObjectClass, and Type M
is Matching Rule.
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 18]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
This document make no OID assignments, it only associates LDAP schema
descriptions with existing elements of X.500 schema.
7. Acknowledgments
This document borrows from a number of IETF documents including RFC
1274 by Paul Barker and Steve Kille. This document also borrows from
a number of ITU documents including X.520.
7. Author's Address
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 17]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
References
[ISO3166] International Standards Organization, "Codes for the
representation of names of countries", ISO 3166.
9. Normative References
[RFC822] D. Crocker, "Standard for the format of ARPA Internet text
messages", August 1982.
messages", STD 11 (also RFC 822), August 1982.
[RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities",
November 1987.
STD 13 (also RFC 1034), November 1987.
[RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
November 1991.
[RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 (also BCP 14), March 1997.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", January
@ -989,9 +1052,6 @@ References
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
April 2000.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
@ -999,22 +1059,33 @@ References
(v3): Technical Specification", draft-ietf-ldapbis-
ldapv3-ts-00.txt.
[X.520] "The Directory: Selected Attribute Types", ITU
Recommendation X.520, 1997.
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 18]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 19]
INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
10. Informative References
[ISO3166] International Standards Organization, "Codes for the
representation of names of countries", ISO 3166.
[RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
November 1991.
[RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
April 2000.
[X.520] International Telephone Union, "The Directory: Selected
Attribute Types", X.520, 1997.
Full Copyright
Copyright 2001, The Internet Society. All Rights Reserved.
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
@ -1048,20 +1119,5 @@ Full Copyright
Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 19]
Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 20]