upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-02-03 20:40:05 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update RFCs and I-Ds...

Browse source
This commit is contained in:
Kurt Zeilenga 2004-08-27 18:41:02 +00:00
parent a17c9ec502
commit 6780800386
13 changed files with 6007 additions and 6022 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5812
doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
View file

File diff suppressed because it is too large Load diff

1453
doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
View file

File diff suppressed because it is too large Load diff

425
doc/drafts/draft-legg-ldap-acm-admin-xx.txt
View file

@ -1,17 +1,12 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-acm-admin-02.txt Adacel Technologies
Intended Category: Standards Track February 25, 2003
draft-legg-ldap-acm-admin-03.txt Adacel Technologies
Intended Category: Standards Track June 16, 2004
Access Control Administration in LDAP
Lightweight Directory Access Protocol (LDAP):
Access Control Administration
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
@ -36,62 +31,59 @@ Intended Category: Standards Track February 25, 2003
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Comments should be sent
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
to the author.
This Internet-Draft expires on 25 August 2003.
This Internet-Draft expires on 16 December 2004.
1. Abstract
Abstract
This document adapts the X.500 directory administrative model, as it
pertains to access control administration, for use by the Lightweight
Directory Access Protocol. The administrative model partitions the
Directory Information Tree for various aspects of directory data
administration, e.g. subschema, access control and collective
administration, e.g., subschema, access control and collective
attributes. This document provides the particular definitions that
support access control administration, but does not define a
particular access control scheme.
Legg Expires 25 August 2003 [Page 1]
Legg Expires 16 December 2004 [Page 1]
INTERNET-DRAFT Access Control Administration February 25, 2003
INTERNET-DRAFT Access Control Administration June 16, 2004
2. Table of Contents
Table of Contents
1. Abstract ...................................................... 1
2. Table of Contents ............................................. 2
3. Introduction .................................................. 2
4. Conventions ................................................... 2
5. Access Control Administrative Areas ........................... 3
6. Access Control Scheme Indication .............................. 3
7. Access Control Information .................................... 4
8. Access Control Subentries ..................................... 4
9. Applicable Access Control Information ......................... 5
10. Security Considerations ...................................... 6
11. Acknowledgements ............................................. 6
12. IANA Considerations .......................................... 6
13. Normative References ......................................... 7
14. Informative References ....................................... 7
15. Copyright Notice ............................................. 7
16. Author's Address ............................................. 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Access Control Administrative Areas. . . . . . . . . . . . . . 3
4. Access Control Scheme Indication . . . . . . . . . . . . . . . 3
5. Access Control Information . . . . . . . . . . . . . . . . . . 4
6. Access Control Subentries. . . . . . . . . . . . . . . . . . . 4
7. Applicable Access Control Information. . . . . . . . . . . . . 5
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References. . . . . . . . . . . . . . . . . . 6
11.2. Informative References. . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
3. Introduction
1. Introduction
This document adapts the X.500 directory administrative model [X501],
as it pertains to access control administration, for use by the
Lightweight Directory Access Protocol (LDAP) [RFC3377].
The administrative model [ADMIN] partitions the Directory Information
Tree (DIT) for various aspects of directory data administration, e.g.
subschema, access control and collective attributes. The parts of
the administrative model that apply to every aspect of directory data
administration are described in [ADMIN]. This document describes the
administrative framework for access control.
Tree (DIT) for various aspects of directory data administration,
e.g., subschema, access control and collective attributes. The parts
of the administrative model that apply to every aspect of directory
data administration are described in [ADMIN]. This document
describes the administrative framework for access control.
An access control scheme describes the means by which access to
directory information, and potentially to access rights themselves,
@ -102,28 +94,27 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
Other access control schemes may be defined by other documents.
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
of, Sections 4 and 8 of X.501 [X501].
4. Conventions
2. 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, RFC 2119
[RFC2119].
Legg Expires 25 August 2003 [Page 2]
Legg Expires 16 December 2004 [Page 2]
INTERNET-DRAFT Access Control Administration February 25, 2003
INTERNET-DRAFT Access Control Administration June 16, 2004
document are to be interpreted as described in RFC 2119 [RFC2119].
Schema definitions are provided using LDAP description formats
[RFC2252]. Note that the LDAP descriptions have been rendered with
additional white-space and line breaks for the sake of readability.
5. Access Control Administrative Areas
3. Access Control Administrative Areas
The specific administrative area [ADMIN] for access control is termed
an Access Control Specific Area (ACSA). The root of the ACSA is
@ -150,10 +141,9 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
An ACSP or ACIP has zero, one or more subentries that contain Access
Control Information (ACI).
4. Access Control Scheme Indication
6. Access Control Scheme Indication
The access control scheme (e.g. Basic Access Control [BAC]) in force
The access control scheme (e.g., Basic Access Control [BAC]) in force
in an ACSA is indicated by the accessControlScheme operational
attribute contained in the administrative entry for the relevant
ACSP.
@ -164,21 +154,21 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
( 2.5.24.1 NAME 'accessControlScheme'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
Legg Expires 25 August 2003 [Page 3]
INTERNET-DRAFT Access Control Administration February 25, 2003
SINGLE-VALUE USAGE directoryOperation )
An access control scheme conforming to the access control framework
described in this document MUST define a distinct OBJECT IDENTIFIER
Legg Expires 16 December 2004 [Page 3]
INTERNET-DRAFT Access Control Administration June 16, 2004
value to identify it through the accessControlScheme attribute.
Object Identifier Descriptors for access control scheme identifiers
may be registered with IANA [RFC3383].
may be registered with IANA [BCP64].
Only administrative entries for ACSPs are permitted to contain an
accessControlScheme attribute. If the accessControlScheme attribute
@ -191,8 +181,7 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
control scheme identified by the value of the accessControlScheme
attribute of the ACSP.
7. Access Control Information
5. Access Control Information
There are three categories of Access Control Information (ACI):
entry, subentry and prescriptive.
@ -216,24 +205,23 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
subentries of subordinate administrative points, where those
subentries are within the subtree or subtree refinement.
8. Access Control Subentries
6. Access Control Subentries
Each subentry which contains prescriptive ACI MUST have
Legg Expires 25 August 2003 [Page 4]
INTERNET-DRAFT Access Control Administration February 25, 2003
accessControlSubentry as a value of its objectClass attribute. Such
a subentry is called an access control subentry.
The LDAP description [RFC2252] for the accessControlSubentry
auxiliary object class is:
Legg Expires 16 December 2004 [Page 4]
INTERNET-DRAFT Access Control Administration June 16, 2004
( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
A subentry of this object class MUST contain at least one
@ -249,8 +237,7 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
Since a subtreeSpecification may define a subtree refinement, DACDs
within a given ACSA may arbitrarily overlap.
9. Applicable Access Control Information
7. Applicable Access Control Information
Although particular items of ACI may specify attributes or values as
the protected items, ACI is logically associated with entries.
@ -276,22 +263,21 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
administrative point as the subentry for which the decision is
being made.
Legg Expires 25 August 2003 [Page 5]
INTERNET-DRAFT Access Control Administration February 25, 2003
(3) Subentry ACI from the administrative point associated with the
subentry.
10. Security Considerations
8. Security Considerations
This document defines a framework for employing an access control
scheme, i.e. the means by which access to directory information and
scheme, i.e., the means by which access to directory information and
Legg Expires 16 December 2004 [Page 5]
INTERNET-DRAFT Access Control Administration June 16, 2004
potentially to access rights themselves may be controlled, but does
not itself define any particular access control scheme. The degree
of protection provided, and any security risks, are determined by the
@ -301,17 +287,15 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
Security considerations that apply to directory administration in
general [ADMIN] also apply to access control administration.
11. Acknowledgements
9. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
of, Sections 4 and 8 of X.501 [X501].
12. IANA Considerations
10. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP descriptors registry as indicated by the following
the LDAP descriptors registry [BCP64] as indicated by the following
templates:
Subject: Request for LDAP Descriptor Registration
@ -332,15 +316,9 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
Specification: RFC XXXX
Author/Change Controller: IESG
11. References
Legg Expires 25 August 2003 [Page 6]
INTERNET-DRAFT Access Control Administration February 25, 2003
13. Normative References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
@ -349,76 +327,46 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
Legg Expires 16 December 2004 [Page 6]
INTERNET-DRAFT Access Control Administration June 16, 2004
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[ADMIN] Legg, S., "Directory Administrative Model in LDAP",
draft-legg-ldap-admin-xx.txt, a work in progress, February
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
Directory Access Protocol (LDAP)", RFC 3672, December
2003.
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
[ADMIN] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Directory Administrative Model",
draft-legg-ldap-admin-xx.txt, a work in progress, June
2004.
11.2. Informative References
14. Informative References
[COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[BAC] Legg, S., "Basic and Simplified Access Control in LDAP",
draft-legg-ldap-acm-bac-xx.txt, a work in progress,
February 2003.
[BAC] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Basic and Simplified Access Control",
draft-legg-ldap-acm-bac-xx.txt, a work in progress, June
2004.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
August 2002.
[X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
Information technology - Open Systems Interconnection -
The Directory: Models
[X501] ITU-T Recommendation X.501 (02/2001), Information
technology - Open Systems Interconnection - The Directory:
Models
15. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
Legg Expires 25 August 2003 [Page 7]
INTERNET-DRAFT Access Control Administration February 25, 2003
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 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.
16. Author's Address
Author's Address
Steven Legg
Adacel Technologies Ltd.
@ -430,78 +378,125 @@ INTERNET-DRAFT Access Control Administration February 25, 2003
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Full Copyright Statement
Appendix A - Changes From Previous Drafts
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
A.1 Changes in Draft 01
Legg Expires 16 December 2004 [Page 7]
INTERNET-DRAFT Access Control Administration June 16, 2004
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Changes in Draft 01
Section 4 has been extracted to become a separate Internet draft,
draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
become the new Sections 4 to 8. Editorial changes have been made to
become the new Sections 3 to 7. Editorial changes have been made to
accommodate this split. No technical changes have been introduced.
A.2 Changes in Draft 02
Changes in Draft 02
RFC 3377 replaces RFC 2251 as the reference for LDAP.
Legg Expires 25 August 2003 [Page 8]
INTERNET-DRAFT Access Control Administration February 25, 2003
An IANA Considerations section has been added.
Changes in Draft 03
Legg Expires 25 August 2003 [Page 9]
Legg Expires 16 December 2004 [Page 8]
INTERNET-DRAFT Access Control Administration June 16, 2004
The document has been reformatted in line with current practice.
Legg Expires 16 December 2004 [Page 9]

1206
doc/drafts/draft-legg-ldap-acm-bac-xx.txt
View file

File diff suppressed because it is too large Load diff

297
doc/drafts/draft-legg-ldap-admin-xx.txt
View file

@ -1,17 +1,12 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-admin-01.txt Adacel Technologies
Intended Category: Standards Track February 25, 2003
draft-legg-ldap-admin-02.txt Adacel Technologies
Intended Category: Standards Track June 16, 2004
Directory Administrative Model in LDAP
Lightweight Directory Access Protocol (LDAP):
Directory Administrative Model
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
@ -36,96 +31,92 @@ Intended Category: Standards Track February 25, 2003
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Comments should be sent
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
to the author.
This Internet-Draft expires on 25 August 2003.
This Internet-Draft expires on 16 December 2004.
1. Abstract
Abstract
This document adapts the X.500 directory administrative model for use
by the Lightweight Directory Access Protocol. The administrative
model partitions the Directory Information Tree for various aspects
of directory data administration, e.g. subschema, access control and
of directory data administration, e.g., subschema, access control and
collective attributes. The generic framework that applies to every
aspect of administration is described in this document. The
definitions that apply for a specific aspect of administration, e.g.
definitions that apply for a specific aspect of administration, e.g.,
access control administration, are described in other documents.
Legg Expires 25 August 2003 [Page 1]
Legg Expires 16 December 2004 [Page 1]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
INTERNET-DRAFT Directory Administrative Model June 16, 2004
2. Table of Contents
Table of Contents
1. Abstract ...................................................... 1
2. Table of Contents ............................................. 2
3. Introduction .................................................. 2
4. Conventions ................................................... 2
5. Administrative Areas .......................................... 3
6. Autonomous Administrative Areas ............................... 3
7. Specific Administrative Areas ................................. 3
8. Inner Administrative Areas .................................... 4
9. Administrative Entries ........................................ 5
10. Security Considerations ...................................... 5
11. Acknowledgements ............................................. 5
12. Normative References ......................................... 5
13. Informative References ....................................... 6
14. Copyright Notice ............................................. 6
15. Author's Address ............................................. 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Administrative Areas . . . . . . . . . . . . . . . . . . . . . 2
4. Autonomous Administrative Areas. . . . . . . . . . . . . . . . 3
5. Specific Administrative Areas. . . . . . . . . . . . . . . . . 3
6. Inner Administrative Areas . . . . . . . . . . . . . . . . . . 4
7. Administrative Entries . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References. . . . . . . . . . . . . . . . . . 5
10.2. Informative References. . . . . . . . . . . . . . . . . 5
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
3. Introduction
1. Introduction
This document adapts the X.500 directory administrative model [X501]
for use by the Lightweight Directory Access Protocol (LDAP)
[RFC3377]. The administrative model partitions the Directory
Information Tree (DIT) for various aspects of directory data
administration, e.g. subschema, access control and collective
attributes. This document provides the definitions for the generic
parts of the administrative model that apply to every aspect of
directory data administration.
for use by the Lightweight Directory Access Protocol (LDAP) [LDAP].
The administrative model partitions the Directory Information Tree
(DIT) for various aspects of directory data administration, e.g.,
subschema, access control and collective attributes. This document
provides the definitions for the generic parts of the administrative
model that apply to every aspect of directory data administration.
Sections 5 to 9, in conjunction with [SUBENTRY], describe the means
Sections 3 to 7, in conjunction with [SUBENTRY], describe the means
by which administrative authority is aportioned and exercised in the
DIT.
Aspects of administration that conform to the administrative model
described in this document are detailed elsewhere, e.g. access
described in this document are detailed elsewhere, e.g., access
control administration is described in [ACA] and collective attribute
administration is described in [COLLECT].
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
of, Sections 4 and 8 of X.501 [X501].
4. Conventions
2. 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 RFC 2119 [RFC2119].
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Administrative Areas
Legg Expires 25 August 2003 [Page 2]
Legg Expires 16 December 2004 [Page 2]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
INTERNET-DRAFT Directory Administrative Model June 16, 2004
5. Administrative Areas
An administrative area is a subtree of the DIT considered from the
perspective of administration. The root entry of the subtree is an
administrative point. An administrative point is represented by an
entry holding an administrativeRole attribute [SUBENTRY]. The values
of this attribute identify the kind of administrative point.
6. Autonomous Administrative Areas
4. Autonomous Administrative Areas
The DIT may be partitioned into one or more non-overlapping subtrees
termed autonomous administrative areas. It is expected that the
@ -145,8 +136,7 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
encountered, at which point another autonomous administrative area
begins.
7. Specific Administrative Areas
5. Specific Administrative Areas
Entries in an administrative area may be considered in terms of a
specific administrative function. When viewed in this context, an
@ -164,19 +154,19 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
Alternatively, for each specific aspect of administration, the
autonomous administrative area may be partitioned into
Legg Expires 25 August 2003 [Page 3]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
non-overlapping specific administrative areas.
If so partitioned for a particular aspect of administration, each
entry of the autonomous administrative area is contained in one and
only one specific administrative area for that aspect, i.e. specific
Legg Expires 16 December 2004 [Page 3]
INTERNET-DRAFT Directory Administrative Model June 16, 2004
only one specific administrative area for that aspect, i.e., specific
administrative areas do not overlap.
The root entry of a specific administrative area's subtree is called
@ -202,13 +192,12 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
autonomous administrative area, which is used for access control
purposes only.
6. Inner Administrative Areas
8. Inner Administrative Areas
For some aspects of administration, e.g. access control or collective
attributes, inner administrative areas may be defined within the
specific administrative areas, to allow a limited form of delegation,
or for administrative or operational convenience.
For some aspects of administration, e.g., access control or
collective attributes, inner administrative areas may be defined
within the specific administrative areas, to allow a limited form of
delegation, or for administrative or operational convenience.
An inner administrative area may be nested within another inner
administrative area. The rules for nested inner areas are defined as
@ -220,19 +209,18 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
specific administrative area) extends from its inner administrative
point downwards until a specific administrative point of the same
administrative aspect is encountered. An inner administrative area
Legg Expires 25 August 2003 [Page 4]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
is bounded by the specific administrative area within which it is
defined.
7. Administrative Entries
Legg Expires 16 December 2004 [Page 4]
INTERNET-DRAFT Directory Administrative Model June 16, 2004
9. Administrative Entries
An entry located at an administrative point is an administrative
entry. Administrative entries MAY have subentries [SUBENTRY] as
@ -246,11 +234,10 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
subtree refinement associated with an inner area defined for that
aspect.
10. Security Considerations
8. Security Considerations
This document defines a generic framework for employing policy of
various kinds, e.g. access controls, to entries in the DIT. Such
various kinds, e.g., access controls, to entries in the DIT. Such
policy can only be correctly enforced at a directory server holding a
replica of a portion of the DIT if the administrative entries for
administrative areas that overlap the portion of the DIT being
@ -261,86 +248,50 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
Administrative entries and subentries SHOULD be protected from
unauthorized examination or changes by appropriate access controls.
11. Acknowledgements
9. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
of, Sections 4 and 8 of X.501 [X501].
10. References
12. Normative References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
[LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
Directory Access Protocol (LDAP)", RFC 3672, December
2003.
10.2. Informative References
Legg Expires 25 August 2003 [Page 5]
Legg Expires 16 December 2004 [Page 5]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
INTERNET-DRAFT Directory Administrative Model June 16, 2004
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
[COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[ACA] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Access Control Administration",
draft-legg-ldap-acm-admin-xx.txt, a work in progress, June
2004.
13. Informative References
[X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
Information technology - Open Systems Interconnection -
The Directory: Models
[ACA] Legg, S., "Access Control Administration in LDAP",
draft-legg-ldap-acm-admin-xx.txt, a work in progress,
February 2003.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
August 2002.
[X501] ITU-T Recommendation X.501 (02/2001), Information
technology - Open Systems Interconnection - The Directory:
Models
14. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Legg Expires 25 August 2003 [Page 6]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
15. Author's Address
11. Author's Address
Steven Legg
Adacel Technologies Ltd.
@ -352,20 +303,66 @@ INTERNET-DRAFT Directory Administrative Model February 25, 2003
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Full Copyright Statement
Appendix A - Changes From Previous Drafts
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
A.1 Changes in Draft 00
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
Legg Expires 16 December 2004 [Page 6]
INTERNET-DRAFT Directory Administrative Model June 16, 2004
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Changes in Draft 00
This document reproduces Section 4 from
draft-legg-ldap-acm-admin-00.txt as a standalone document. All
changes made are purely editorial. No technical changes have been
introduced.
A.2 Changes in Draft 01
Changes in Draft 01
RFC 3377 replaces RFC 2251 as the reference for LDAP.
Changes in Draft 02
The document has been reformatted in line with current practice.
@ -388,8 +385,6 @@ A.2 Changes in Draft 01
Legg Expires 25 August 2003 [Page 7]
Legg Expires 16 December 2004 [Page 7]

448
doc/drafts/draft-legg-ldap-binary-xx.txt Normal file
View file

@ -0,0 +1,448 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-binary-01.txt Adacel Technologies
Intended Category: Standards Track 16 June 2004
Updates: RFC 2251bis
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
<steven.legg@adacel.com.au>.
This Internet-Draft expires on 16 December 2004.
Abstract
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory has a defined syntax (i.e., data type). A syntax
Legg Expires 16 December 2004 [Page 1]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
definition specifies how attribute values conforming to the syntax
are normally represented when transferred in LDAP operations. This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values. This
document defines an attribute option, the binary option, which can be
used to specify that the associated attribute values are instead
encoded according to the Basic Encoding Rules (BER) used by X.500
directories.
Legg Expires 16 December 2004 [Page 2]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 5
7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References. . . . . . . . . . . . . . . . . . 6
10.2. Informative References. . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
which constrains the structure and format of its values.
The description of each syntax [SYNTAX] specifies how attribute or
assertion values [MODELS] conforming to the syntax are normally
represented when transferred in LDAP operations [PROT]. This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values.
This document defines an attribute option, the binary option, which
can be used in an attribute description [MODELS] in an LDAP operation
to specify that the associated attribute values or assertion value
are, or are requested to be, encoded according to the Basic Encoding
Rules (BER) [BER] as used by X.500 [X500] directories, instead of the
usual LDAP-specific encoding.
The binary option was originally defined in RFC 2251 [RFC2251]. The
LDAP technical specification [ROADMAP] has obsoleted the previously
defined LDAP technical specification [RFC3377], which included RFC
2251. However the binary option was not included in the newer LDAP
technical specification due to a lack of consistency in its
implementation. This document reintroduces the binary option.
However, except for the case of certain attribute syntaxes whose
values are required to BER encoded, no attempt is made here to
eliminate the known consistency problems. Rather the focus is on
capturing current behaviours. A more thorough solution is left for a
future specification.
Legg Expires 16 December 2004 [Page 3]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
2. 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, RFC 2119
[KEYWORD].
3. The binary Option
The binary option is indicated with the attribute option string
"binary" in an attribute description. Note that, like all attribute
options, the string representing the binary option is case
insensitive.
In terms of the protocol [PROT], the binary option specifies that the
contents octets of the associated AttributeValue or AssertionValue
OCTET STRING are a complete BER encoding of the relevant value.
Where the binary option is present in an attribute description the
associated attribute values or assertion value MUST be BER encoded.
Note that it is possible for a syntax to be defined such that its
LDAP-specific encoding is exactly the same as its BER encoding.
The binary option is not a tagging option [MODELS] so the presence of
the binary option does not specify an attribute subtype. An
attribute description containing the binary option references exactly
the same attribute as the same attribute description without the
binary option. The supertype/subtype relationships of attributes
with tagging options are not altered in any way by the presence or
absence of the binary option.
An attribute description SHALL be treated as unrecognized if it
contains the binary option and the syntax of the attribute does not
have an associated ASN.1 type [SYNTAX], or the BER encoding of that
type is not supported.
The presence or absence of the binary option only affects the
transfer of attribute and assertion values in protocol; servers store
any particular attribute value in a single format of their choosing.
4. Syntaxes Requiring Binary Transfer
Certain syntaxes are required to be transferred in the BER encoded
form. These syntaxes are said to have a binary transfer requirement.
The Certificate, Certificate List, Certificate Pair and Supported
Algorithm syntaxes [PKI] are examples of syntaxes with a binary
transfer requirement. These syntaxes also have an additional
requirement that the exact BER encoding must be preserved. Note that
Legg Expires 16 December 2004 [Page 4]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
this is a property of the syntaxes themselves, and not a property of
the binary option.
5. Attributes Returned in a Search
An LDAP search request [PROT] contains a list of the attributes (the
requested attributes list) to be returned from each entry matching
the search filter. An attribute description in the requested
attributes list also implicitly requests all subtypes of the
attribute type in the attribute description, whether through
attribute subtyping or attribute tagging option subtyping [MODELS].
The requested attributes list MAY contain attribute descriptions with
the binary option, but MUST NOT contain two attribute descriptions
with the same attribute type and the same tagging options (even if
only one of them has the binary option). The binary option in an
attribute description in the requested attributes list implicitly
applies to all the subtypes of the attribute type in the attribute
description (however, see Section 7).
Attributes of a syntax with the binary transfer requirement SHALL be
returned in the binary form, i.e., with the binary option in the
attribute description and the associated attribute values BER
encoded, regardless of whether the binary option was present in the
request (for the attribute or for one of its supertypes).
Attributes of a syntax without the binary transfer requirement SHOULD
be returned in the form explicitly requested. That is, if the
attribute description in the requested attributes list contains the
binary option then the corresponding attribute in the result SHOULD
be in the binary form. If the attribute description in the request
does not contain the binary option then the corresponding attribute
in the result SHOULD NOT be in the binary form. A server MAY omit an
attribute from the result if it does not support the requested
encoding.
Regardless of the encoding chosen, a particular attribute value is
returned at most once.
6. All User Attributes
If the list of attributes in a search request is empty, or contains
the special attribute description string "*", then all user
attributes are requested to be returned.
Attributes of a syntax with the binary transfer requirement SHALL be
returned in the binary form.
Legg Expires 16 December 2004 [Page 5]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Attributes of a syntax without the binary transfer requirement and
having a defined LDAP-specific encoding SHOULD NOT be returned in the
binary form.
Attributes of a syntax without the binary transfer requirement and
without a defined LDAP-specific encoding may be returned in the
binary form or omitted from the result.
7. Conflicting Requests
A particular attribute could be explicitly requested by an attribute
description and/or implicitly requested by the attribute descriptions
of one or more of its supertypes, or by the special attribute
description string "*". If the binary option is not present in all
these attribute descriptions, nor absent in all these attribute
descriptions, then the server is free to choose whether to return the
attribute in the binary form.
8. Security Considerations
When interpreting security-sensitive fields, and in particular fields
used to grant or deny access, implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used.
9. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP attribute description option registry [BCP64] as indicated
by the following template:
Subject: Request for
LDAP Attribute Description Option Registration
Option Name: binary
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: The existing registration for "binary"
should be updated to refer to RFC XXXX.
10. References
10.1. Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Legg Expires 16 December 2004 [Page 6]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
June 2004.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress, June
2004.
[PROT] Sermersheim, J., "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
May 2004.
[SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
Protocol (LDAP): Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
May 2004.
[PKI] Chadwick, D. and S. Legg, "Internet X.509 Public Key
Infrastructure Additional LDAP Schema for PKIs and PMIs",
draft-pkix-ldap-schema-xx.txt, a work in progress, April
2002.
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
10.2. Informative References
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
"Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services".
Author's Address
Legg Expires 16 December 2004 [Page 7]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
Email: steven.legg@adacel.com.au
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Legg Expires 16 December 2004 [Page 8]

614
doc/drafts/draft-legg-ldap-transfer-xx.txt Normal file
View file

@ -0,0 +1,614 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-transfer-03.txt Adacel Technologies
Intended Category: Standards Track 16 June 2004
Updates: RFC 2252bis
Lightweight Directory Access Protocol (LDAP):
Transfer Encoding Options
Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
<steven.legg@adacel.com.au>.
This Internet-Draft expires on 16 December 2004.
Abstract
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory has a defined syntax (i.e., data type). A syntax
Legg Expires 16 December 2004 [Page 1]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
definition specifies how attribute values conforming to the syntax
are normally represented when transferred in LDAP operations. This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values. This
document introduces a new category of attribute options, called
transfer encoding options, which can be used to specify that the
associated attribute values are encoded according to one of these
other methods.
Legg Expires 16 December 2004 [Page 2]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transfer Encoding Options. . . . . . . . . . . . . . . . . . . 4
4. Defined Transfer Encoding Options. . . . . . . . . . . . . . . 5
5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 6
6. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 7
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
which constrains the structure and format of its values.
The description of each syntax [SYNTAX] specifies how attribute or
assertion values [MODELS] conforming to the syntax are normally
represented when transferred in LDAP operations [PROT]. This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values.
This document introduces a new category of attribute options
[MODELS], called transfer encoding options, that allow attribute and
assertion values to be transferred using an alternative method of
encoding. This document defines several transfer encoding options
which can be used in an attribute description [MODELS] in an LDAP
operation to specify that the associated attribute values or
assertion value are, or are requested to be, encoded according to
specific Abstract Syntax Notation One (ASN.1) [X680] encoding rules,
instead of the usual LDAP-specific encoding. One option in
particular allows Extensible Markup Language (XML) [XML] encodings.
2. 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, RFC 2119
[KEYWORD].
This specification makes use of definitions from the XML Information
Set (Infoset) [ISET]. In particular, information item property names
Legg Expires 16 December 2004 [Page 3]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
are presented per the Infoset, e.g., [local name].
3. Transfer Encoding Options
Transfer encoding options enable attribute and assertion values to be
transferred using an alternative method of encoding to the default
LDAP-specific encoding. In fact, some attribute and assertion
syntaxes do not have a defined LDAP-specific encoding in which case
the only way values of those syntaxes can be transferred is by using
an alternative encoding.
The binary option [BINARY] is not formally regarded as a transfer
encoding option, though it has much in common with transfer encoding
options. The requirements governing the use of transfer encoding
options do not apply to the binary option. The requirements
governing the use of the binary option are described elsewhere
[BINARY].
In terms of the protocol [PROT], a transfer encoding option specifies
that the contents octets of an associated AttributeValue or
AssertionValue OCTET STRING are a complete encoding of the relevant
value according to the encoding method specified by the option.
Where a transfer encoding option is present in an attribute
description the associated attribute values or assertion value MUST
be encoded according to the encoding method corresponding to the
option. Note that it is possible for a syntax to be defined such
that its LDAP-specific encoding is exactly the same as its encoding
according to some transfer encoding option (e.g., the LDAP-specific
encoding might be defined to be the same as the BER encoding).
Transfer encoding options are mutually exclusive. An attribute
description SHALL NOT contain more than one transfer encoding option,
and SHALL NOT contain both a transfer encoding option and the binary
option.
Transfer encoding options are not tagging options [MODELS] so the
presence of a transfer encoding option does not specify an attribute
subtype. An attribute description containing a transfer encoding
option references exactly the same attribute as the same attribute
description without the transfer encoding option. The
supertype/subtype relationships of attributes with tagging options
are not altered in any way by the presence or absence of transfer
encoding options.
An attribute description SHALL be treated as unrecognized if it
contains a transfer encoding option and the syntax of the attribute
does not have an associated ASN.1 type [SYNTAX], or if the nominated
Legg Expires 16 December 2004 [Page 4]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
encoding is not supported for that type.
The presence or absence of a transfer encoding option only affects
the transfer of attribute and assertion values in protocol; servers
store any particular attribute value in a single format of their
choosing.
4. Defined Transfer Encoding Options
The attribute option string "transfer-ber" specifies that the
associated attribute values or assertion value are (to be) encoded
according to the Basic Encoding Rules [X690] of ASN.1. This option
is similar to the binary option [BINARY], however servers are more
restricted in when they can use "transfer-ber" which leads to more
predictability in the results returned to clients who request
"transfer-ber".
The attribute option string "transfer-der" specifies that the
associated attribute values or assertion value are (to be) encoded
according to the Distinguished Encoding Rules [X690] of ASN.1.
The attribute option string "transfer-gser" specifies that the
associated attribute values or assertion value are (to be) encoded
according to the Generic String Encoding Rules (GSER) [RFC3641].
The attribute option string "transfer-rxer" specifies that the
associated attribute values or assertion value are (to be) encoded as
an XML document [XML]. The [local name] of the [document element] of
the document information item representing the associated value SHALL
be the identifier of the NamedType [X680] in the LDAP ASN.1
specification [PROT] defining the associated attribute value or
assertion value, or "item" if the associated value isn't in a
NamedType. This means:
- for an AttributeValue the identifier is "value" in every case,
- for an AssertionValue in an AttributeValueAssertion the identifier
is "assertionValue",
- for an AssertionValue in a SubstringFilter the identifier is
"initial", "any" or "final", as appropriate,
- for an AssertionValue in a MatchingRuleAssertion the identifier is
"matchValue".
The [namespace name] of the [document element] SHALL have no value.
The content of the [document element] is the Robust XML Encoding
Rules (RXER) [RXER] encoding of the associated attribute or assertion
Legg Expires 16 December 2004 [Page 5]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
value. Note that the enclosing element for the RXER encoding has the
form it would take in an XLDAP operation [XLDAP].
Note that, like all attribute options, the strings representing
transfer encoding options are case insensitive.
All future registrations of option strings for transfer encoding
options should use the "transfer-" prefix so that LDAP clients and
servers can recognize that an option is a transfer encoding option
even though the particular encoding rules may be unrecognized.
5. Attributes Returned in a Search
An LDAP search request [PROT] contains a list of the attributes (the
requested attributes list) to be returned from each entry matching
the search filter. An attribute description in the requested
attributes list also implicitly requests all subtypes of the
attribute type in the attribute description, whether through
attribute subtyping or attribute tagging option subtyping [MODELS].
The requested attributes list MAY contain attribute descriptions with
a transfer encoding option, but MUST NOT contain two attribute
descriptions with the same attribute type and the same tagging
options (even if only one of them has a transfer encoding option). A
transfer encoding option in an attribute description in the requested
attributes list implicitly applies to the subtypes of the attribute
type in the attribute description.
If the list of attributes in a search request is empty, or contains
the special attribute description string "*", then all user
attributes are requested to be returned.
In general, it is possible for a particular attribute to be
explicitly requested by an attribute description and/or implicitly
requested by the attribute descriptions of one or more of its
supertypes. In such cases the effective transfer encoding being
requested for a particular attribute is determined by the transfer
encoding option (or lack thereof) in the most specific attribute
description in the requested attributes list that applies to the
attribute.
An applicable attribute description with an actual attribute type is
more specific than the special attribute description string "*".
If the attribute type of one applicable attribute description is a
direct or indirect subtype of the attribute type in another
applicable attribute description then the former attribute
description is more specific than the latter attribute description.
Legg Expires 16 December 2004 [Page 6]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
If two applicable attribute descriptions have the same attribute type
and the tagging options of one attribute description are a superset
of the tagging options of the other attribute description then the
former attribute description is more specific than the latter
attribute description.
Attributes MUST either be returned in the effective transfer encoding
requested, be returned with no attribute values, or be omitted from
the results. An attribute SHALL NOT be returned using an encoding
other than the effective transfer encoding requested.
Regardless of the encoding chosen, a particular attribute value is
returned at most once.
6. Syntaxes Requiring Binary Transfer
Certain syntaxes are required to be transferred in the BER encoded
form. These syntaxes are said to have a binary transfer requirement.
The Certificate, Certificate List, Certificate Pair and Supported
Algorithm syntaxes [PKI] are examples of syntaxes with a binary
transfer requirement. These syntaxes also have an additional
requirement that the exact BER encoding must be preserved. Note that
this is a property of the syntaxes themselves, and not a property of
the binary option or any of the transfer encoding options.
Transfer encoding options SHALL take precedence over the requirement
for binary transfer. For example, if the effective transfer encoding
requested is say "transfer-gser", then attribute values of a syntax
with a binary transfer requirement will be GSER encoded. In the
absence of a transfer encoding option the normal rules on binary
transfer and the use of the binary option SHALL apply.
7. Security Considerations
There is a requirement on some attribute syntaxes that the exact BER
encoding of values of that syntax be preserved. In general, a
transformation from the BER encoding into some other encoding (e.g.,
GSER) and back into the BER encoding will not necessarily reproduce
exactly the octets of the original BER encoding.
Applications needing the original BER encoding to be preserved, e.g.,
for the verification of digital signatures, MUST NOT request
attributes with such a requirement using a transfer encoding option.
These attributes MUST be requested explicitly or implicitly with the
binary option, or implicitly without the binary option (or any
transfer encoding option).
When interpreting security-sensitive fields, and in particular fields
Legg Expires 16 December 2004 [Page 7]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
used to grant or deny access, implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used.
8. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP attribute description option registry [BCP64] as indicated
by the following templates:
Subject: Request for
LDAP Attribute Description Option Registration
Option Name: transfer-ber
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Subject: Request for
LDAP Attribute Description Option Registration
Option Name: transfer-der
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Subject: Request for
LDAP Attribute Description Option Registration
Option Name: transfer-gser
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Subject: Request for
LDAP Attribute Description Option Registration
Option Name: transfer-rxer
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Specification: RFC XXXX
Author/Change Controller: IESG
Legg Expires 16 December 2004 [Page 8]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
Comments:
9. References
9.1. Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
June 2004.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress, June
2004.
[PROT] Sermersheim, J., "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
May 2004.
[SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
Protocol (LDAP): Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
May 2004.
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", RFC 3641, October 2003.
[BINARY] Legg, S., "Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option",
draft-legg-ldap-binary-xx.txt, a work in progress, June
2004.
[RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules for
ASN.1 Types", draft-legg-xed-rxer-00.txt, a work in
progress, June 2004.
[X680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Legg Expires 16 December 2004 [Page 9]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xml-20040204, February 2004.
[ISET] Cowan, J. and R. Tobin, "XML Information Set",
http://www.w3.org/TR/2001/REC-xml-infoset-20011024,
October 2001.
9.2. Informative References
[XLDAP] Legg, S. and D. Prager, "The XML Enabled Directory:
Protocols", draft-legg-xed-protocols-xx.txt, a work in
progress, May 2004.
Author's Address
Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
Email: steven.legg@adacel.com.au
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
Legg Expires 16 December 2004 [Page 10]
INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Changes in Draft 01
A transfer encoding option for RXER has been added.
Changes in Draft 02
The local name of the root element of the XML document representing
an attribute value encoded according to the transfer-rxer encoding
option has been changed from "item" to "value" to align with
revisions to the LDAP protocol specification [PROT].
The Directory XML Encoding Rules (DXER) have been renamed to the
Robust XML Encoding Rules (RXER).
Changes in Draft 03
The special attribute description strings that consist of the
asterisk character followed by a transfer encoding option, e.g.,
"*;transfer-ber", "*;transfer-gser", have been removed from this
specification. An LDAP control will be defined in a separate
document to provide equivalent functionality.
Legg Expires 16 December 2004 [Page 11]

531
doc/drafts/draft-rharrison-ldap-intermediate-resp-xx.txt
View file

@ -1,531 +0,0 @@
INTERNET-DRAFT R. Harrison
draft-rharrison-ldap-intermediate-resp-01.txt Novell, Inc.
Updates: 2251 K. Zeilenga
Intended Category: Standards Track OpenLDAP Foundation
March 28, 2003
The Lightweight Directory Access Protocol (LDAP)
Intermediate Response Message
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 (ldapext) mailing list <ietf-ldapext@netscape.com>. Please
send editorial comments directly to the document editor
<roger_harrison@novell.com>
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Lightweight Directory Access Protocol (LDAP) version 3 is a
client-request/server-response based protocol. With the exception
of the search operation, the entire response to an operation request
is returned in a single LDAP message. While this single-
request/single-response paradigm is sufficient for many operations
(including all but one of those currently defined by LDAP), both
intuition and practical experience validate the notion that it is
insufficient for some operations. When multiple messages are sent
Harrison & Zeilenga Expires September 28, 2003 [Page 1]
Internet-Draft LDAP Intermediate Response 28 March 2003
in response to a single request, all but the last of these response
messages are referred to as "intermediate responses".
This document defines and describes the IntermediateResponse
message, a general mechanism for defining single-request/multiple-
response operations in LDAP. The IntermediateResponse message is
defined in a way that maintains the protocol behavior of existing
LDAP operations. This message is intended to be used in conjunction
with the LDAP ExtendedRequest and ExtendedResponse to define new
single-request/multiple-response operations or in conjunction with a
control when extending existing LDAP operations in a way that
requires them to return intermediate response information.
1. Introduction
The Lightweight Directory Access Protocol (LDAP), version 3
[RFC3377] is an extensible protocol. Extended operations ([RFC2251]
Section 4.12) are defined to allow operations to be added to LDAP
without requiring a new revision of the protocol. Similarly,
controls ([RFC2251] section 4.1.12) are defined to extend or modify
the behavior of existing LDAP operations.
LDAP is a client-request/server-response based protocol. With the
exception of the search operation, the entire response to an
operation request is returned in a single protocol data unit (i.e.
LDAP message). While this single-request/single-response paradigm
is sufficient for many operations (including all but one of those
currently defined by [RFC3377]), both intuition and practical
experience validate the notion that it is insufficient for some
operations.
For example, the LDAP delete operation could be extended via a
subtree control to mean that an entire subtree is to be deleted. A
subtree delete operation needs to return continuation references
based upon subordinate knowledge information contained in the server
so that the client can complete the operation. Returning references
as they are found instead of with the final result allows the client
to progress the operation more efficiently because it does not have
to wait for the final result to get this continuation reference
information.
Similarly, an engineer might choose to design the subtree delete
operation as an extended operation of its own rather than using a
subtree control in conjunction with the delete operation. Once
again, the same continuation reference information is needed by the
client to complete the operation, and sending the continuation
references as they are found would allow the client progress the
operation more efficiently.
Operations that complete in stages or that progress through various
states as they complete might want to send intermediate responses to
the client, thereby informing it of the status of the operation.
For example, an LDAP implementation might define an extended
Harrison & Zeilenga Expires September 28, 2003 [Page 2]
Internet-Draft LDAP Intermediate Response 28 March 2003
operation to create a new replica of an administrative area on a
server, and the operation completes in three stages: (1) begin
creation of replica, (2) send replica data to server, (3) replica
creation complete. Intermediate messages might be sent from the
server to the client at the beginning of each stage with the final
response for the extended operation being sent after stage (3) is
complete.
As LDAP [RFC3377] is currently defined, there is no general LDAP
message type that can be used to return intermediate results. A
single, reusable LDAP message for carrying intermediate response
information is desired to avoid repeated modification of the
protocol. Although the ExtendedResponse message is defined in LDAP,
it is defined to be the one and only response message to an
ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
responses (LDAP Section 4.4), and to return intermediate responses
for the search operation ([RFC3377] Section 4.5.2, also see Section
5 below). The adaptation of ExtendedResponse as a general
intermediate response mechanism would be problematic. In
particular, existing APIs would likely have to be redesigned. It is
believed (based upon operational experience) that the addition of a
new message to carry intermediate result information is easier to
implement and is less likely to cause interoperability problems with
existing deployed implementations.
This document defines and describes the LDAP IntermediateResponse
message. This message is intended to be used in conjunction with
ExtendedRequest and ExtendedResponse to define new single-
request/multiple-response operations or in conjunction with a
control when extending existing LDAP operations in a way that
requires them to return intermediate response information.
It is intended that the definitions and descriptions of extended
operations and controls that make use of the IntermediateResponse
message will define the circumstances when an IntermediateResponse
message can be sent by a server and the associated meaning of an
IntermediateResponse message sent in a particular circumstance.
Similarly, it is intended that clients will explicitly solicit
IntermediateResponse messages by issuing operations that
specifically call for their return.
The LDAP Content Sync Operation [draft-zeilenga-ldup-sync] (a work
in progress) demonstrates one use of LDAP Intermediate Response
messages.
2. Conventions used in this document
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 [RFC2119].
Harrison & Zeilenga Expires September 28, 2003 [Page 3]
Internet-Draft LDAP Intermediate Response 28 March 2003
The term "request control" is used to describe a control that is
included in an LDAP request message sent from an LDAP client to an
LDAP server.
3. The IntermediateResponse Message
This document extends the protocolOp CHOICE of LDAPMessage
([RFC2251] Section 4.1.1) to include the field:
intermediateResponse IntermediateResponse
where IntermediateResponse is defined as:
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client
unless the client issues a request that specifically solicits their
return. This document defines two forms of solicitation: extended
operation and request control.
Although the responseName and responseValue are optional in some
circumstances, generally speaking IntermediateResponse messages have
a predefined responseName and a responseValue. The value of the
responseName (if present), the syntax of the responseValue (if
present) and the semantics associated with a particular
IntermediateResponse message MUST be specified in documents
describing the extended operation or request control that uses them.
Sections 3.1 and 3.2 describe additional requirements on the
inclusion of responseName and responseValue in IntermediateResponse
messages.
3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
A single-request/multiple-response operation may be defined using a
single ExtendedRequest message to solicit zero or more
IntermediateResponse messages of one or more kinds followed by an
ExtendedResponse message.
An extended operation that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the extended operation or by including identifying
information in the responseValue of each type of
IntermediateResponse message associated with the extended operation.
3.2. Usage with LDAP Request Controls
Any LDAP operation may be extended by the addition of one or more
controls ([RFC2251] Section 4.1.12). A control's semantics may
Harrison & Zeilenga Expires September 28, 2003 [Page 4]
Internet-Draft LDAP Intermediate Response 28 March 2003
include the return of zero or more IntermediateResponse messages
prior to returning the final result code for the operation. One or
more kinds of IntermediateResponse messages may be sent in response
to a request control.
All IntermediateResponse messages associated with request controls
SHALL include a responseName. This requirement ensures that the
client can correctly identify the source of IntermediateResponse
messages when
(a) two or more controls using IntermediateResponse messages
are included in a request for any LDAP operation or
(b) one or more controls using IntermediateResponse messages
are included in a request with an LDAP extended
operation that uses IntermediateResponse messages.
A request control that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the request control or by including identifying
information in the responseValue of each type of
IntermediateResponse message associated with the request control.
4. Advertising Support for IntermediateResponse Messages
Because IntermediateResponse messages are associated with extended
operations or controls and LDAP provides a means for advertising the
extended operations and controls supported by a server (using the
supportedExtensions and supportedControls attributes of the root DSE
attributes), no separate means for advertising support for
IntermediateResponse messages is needed (or provided).
5. Use of IntermediateResponse and ExtendedResponse with Search
It is noted that ExtendedResponse messages may be sent in response
to LDAP search operations with controls ([RFC2251] Section 4.5.1).
This use of ExtendedResponse messages SHOULD be viewed as deprecated
in favor of use of the IntermediateResponse messages.
6. Security Considerations
This document describes an enhancement to LDAP. All security
considerations of [RFC3377] apply to this document, however it does
not introduce any new security considerations to LDAP.
Security considerations specific to each extension using this
protocol mechanism shall be discussed in the technical specification
detailing the extension.
7. IANA Considerations
Harrison & Zeilenga Expires September 28, 2003 [Page 5]
Internet-Draft LDAP Intermediate Response 28 March 2003
Registration of the following value is requested [RFC3383].
7.1. LDAP Message Type
It is requested that IANA register upon Standards Action an LDAP
Message Type to identify the LDAP IntermediateResponse message as
defined in section 3 of this document.
The following registration template is suggested:
Subject: Request for LDAP Message Type Registration
Person & email address to contact for further information:
Roger Harrison <roger_harrison@novell.com>
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: Identifies the LDAP IntermediateResponse Message
Acknowledgments
The authors would like to acknowledge the members of the IETF LDAP
Extensions (ldapext) working group mail list who responded to the
suggestion that a multiple-response paradigm might be useful for
LDAP extended requests. Special thanks go to two individuals: David
Wilbur who first introduced the idea on the working group list, and
Thomas Salter, who succinctly summarized the group's discussion.
Normative References
[RFC2119]
Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC2251]
Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377]
Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September
2002.
[RFC3383]
Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)", RFC 3383, September 2002.
Informative References
[draft-zeilenga-ldup-sync]
Harrison & Zeilenga Expires September 28, 2003 [Page 6]
Internet-Draft LDAP Intermediate Response 28 March 2003
Zeilenga, K., "LDAP Content Synchronization Operation", Work in
Progress.
Authors' Addresses
Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
+1 801 861 2642
roger_harrison@novell.com
Kurt D. Zeilenga
OpenLDAP Foundation
Kurt@OpenLDAP.org
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 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.
Appendix A - Document Revision History
Editors' Note: this appendix should be removed prior to publication
as an RFC. It is provided as an aid to reviewers of this "work in
progress."
A.1. draft-rharrison-ldap-extPartResp-00.txt
Initial revision of draft.
Harrison & Zeilenga Expires September 28, 2003 [Page 7]
Internet-Draft LDAP Intermediate Response 28 March 2003
A.2. draft-rharrison-ldap-extPartResp-01.txt
Changed responseName to be optional to align with [RFC3377]
definition of ExtendedResponse.
A.3. draft-rharrison-ldap-extPartResp-02.txt
Minor terminology corrections. Clarified use of
ExtendedPartialResponse with LDAP extended operations and other LDAP
operations with controls.
A.4. draft-rharrison-ldap-intermediateResp-00.txt
- Changed name of ExtendedPartialResponse to IntermediateResponse.
- Retitled "Motivation" section to "Background and Intended Usage"
and expanded its contents.
- Added detail surrounding the use of the IntermediateResponse with
extended operations and request controls.
- Generalized the way that Intermediate response fits into the ASN.1
definition of LDAP.
- Added information on advertising IntermediateResponse.
- Added information on the use of IntermediateResponse with the
search operation.
A.5. draft-rharrison-ldap-intermediateResp-01.txt
This draft was oriented primarily to preparing the draft for
publication in accordance with established RFC formatting
guidelines. No substantial change in overall content was made.
Changes included the following:
- Retitled document
- Rewrote abstract
- Retitled "Background and Intended Usage" section to "Introduction"
and expanded its contents.
- Retitled Section 3 from "The Intermediate Response PDU" to "The
Intermediate Response Message".
- Renamed references to [RFCnnnn] format
- Added IANA Considerations section
- Retitled "References" section to "Normative References"
- Other small edits to bring draft in line with RFC formatting
Harrison & Zeilenga Expires September 28, 2003 [Page 8]
Internet-Draft LDAP Intermediate Response 28 March 2003
guidelines.
Harrison & Zeilenga Expires September 28, 2003 [Page 9]

335
doc/drafts/draft-sermersheim-ldap-subordinate-scope-xx.txt Normal file
View file

@ -0,0 +1,335 @@
Network Working Group J;. Sermersheim
Internet-Draft Novell, Inc
Updates: 2251 (if approved) July 2004
Expires: December 30, 2004
Subordinate Subtree Search Scope for LDAP
draft-sermersheim-ldap-subordinate-scope-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The Lightweight Directory Application Protocol (LDAP) specification
supports three scope values for the search operation -- namely:
baseObject, singleLevel, and wholeSubtree. This document introduces
a subordinateSubtree scope which constrains the search scope to all
subordinates of the named base object.
Discussion Forum
Sermersheim Expires December 30, 2004 [Page 1]
Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
Technical discussion of this document will take place on the IETF
LDAP Extensions mailing list <ldapext@ietf.org>. Please send
editorial comments directly to the author.
1. Overview
There are a number of reasons which have surfaced for introducing a
Lightweight Directory Application Protocol (LDAP) [RFC3377]
SearchRequest.scope [RFC2251] which constrains the search scope to
all subordinates of the named base object, and does not include the
base object (as wholeSubtree does). These reasons range from the
obvious utility of allowing an LDAP client application the ability to
exclude the base object from a wholeSubtree search scope, to
distributed operation applications which require this scope for
progressing search sub-operations resulting from an nssr DSE type
reference.
To meet these needs, the subordinateSubtree scope value is
introduced.
The subordinateSubtrees cope is applied to the SearchRequest.scope
field, the <scope> type and alternately the <extension> type of the
LDAP URL [RFC2255] and may be applied to other specifications which
include an LDAP search scope. A mechanism is also given which allows
LDAP Directory Server Agents (DSA)s to advertise support of this
search scope.
2. Application to SearchRequest.scope
A new item is added to this ENUMERATED type. The identifier is
subordinateSubtree and the number is 4.
A DSA which receives and supports the subordinateSubtree
SearchRequest.scope constrains the search scope to all subordinate
objects.
A DSA which receives but does not support the subordinateSubtree
SearchRequest.scope returns a protocolError resultCode in the
SearchResultDone.
3. LDAP URL applications
The LDAP URL [RFC2255] specification allows the conveyance of a
search scope. This section intoduces two ways in which the
subordinateScope search scope may be conveyed in an LDAP URL. One
way is by allowing a new "subord" scope in the <scope> part. Another
way is through the introduction of an LDAP URL extension. The LDAP
URL extension method is preferred for its criticality semantics.
Sermersheim Expires December 30, 2004 [Page 2]
Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
3.1 Application to LDAP URL <scope>
A new <scope> value of "subord" is added. Using the <scope> type
from LDAP URL [RFC2255], the ABNF is as follows:
scope /= "subord"
Implementations processing but which do not understand or support the
"subord" <scope> of an LDAP URL raise an appropriate error.
3.2 Application to LDAP URL <extension>
An LDAP URL <extension> mechanism is introduced here. The <extype>
is IANA-ASSIGNED-OID.1 or the descriptor 'subordScope', and the
exvalue is omitted. The extension may be marked as either critical
or non-critical.
If supported, the subordScope extension overrides any value set in
the <scope> field.
4. DSA Advertisement of support
A DSA may advertise its support of the subordinateSubtree item in the
SearchRequest.scope by inclusion of IANA-ASSIGNED-OID.2 in the
'supportedFeatures' attribute of the root DSE.
5. Security Considerations
This specification introduces no security concerns above any
associated with the existing wholeSubtree search scope value.
As with the wholeSubtree search scope, this scope specifies that a
search be applied to an entire subtree hierarchy. Implementations
should be aware of the relative cost of using or allowing this scope.
6 Normative References
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Sermersheim Expires December 30, 2004 [Page 3]
Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
Author's Address
Jim Sermersheim
Novell, Inc
1800 South Novell Place
Provo, Utah 84606
USA
Phone: +1 801 861-3088
EMail: jimse@novell.com
Appendix A. IANA Considerations
Registration of the following values is requested [RFC3383].
A.1 LDAP Object Identifier Registrations
It is requested that IANA register upon Standards Action an LDAP
Object Identifier in identifying the protocol elements defined in
this technical specification. The following registration template is
provided:
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Jim Sermersheim
jimse@novell.com
Specification: RFCXXXX
Author/Change Controller: IESG
Comments:
2 delegations will be made under the assigned OID:
IANA-ASSIGNED-OID.1 subordScope LDAP URL extension
IANA-ASSIGNED-OID.2 subordinateScope Supported Feature
A.2 LDAP Protocol Mechanism Registrations
It is requested that IANA register upon Standards Action the LDAP
protocol mechanism described in this document. The following
registration templates are given:
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID.1
Description: subordScope LDAP URL extension
Person & email address to contact for further information:
Sermersheim Expires December 30, 2004 [Page 4]
Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
Jim Sermersheim
jimse@novell.com
Usage: Extension
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: none
A.3 LDAP Descriptor Registrations
It is requested that IANA register upon Standards Action the LDAP
descriptors described in this document. The following registration
templates are given:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): subordScope
Object Identifier: IANA-ASSIGNED-OID.1
Person & email address to contact for further information:
Jim Sermersheim
jimse@novell.com
Usage: URL Extension
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: none
Sermersheim Expires December 30, 2004 [Page 5]
Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sermersheim Expires December 30, 2004 [Page 6]

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

@ -3,21 +3,18 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 26 October 2003
Expires in six months 18 July 2004
LDAP: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-06.txt>
Requesting Attributes by Object Class in the
Lightweight Directory Access Protocol
<draft-zeilenga-ldap-adlist-08.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
@ -25,20 +22,27 @@ Status of this Memo
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
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.''
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
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@ -47,17 +51,19 @@ Status of this Memo
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-06 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
provides mechanisms for clients to request all user application
attributes, all operational attributes, and/or attributes selected by
their description. This document extends LDAP to support a mechanism
that LDAP clients may use to request the return of all attributes
belonging to an object class.
1. Overview
@ -66,17 +72,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
search operation [RFC2251] support requesting a sets of attributes.
This set is determined by a list of attribute descriptions. Two
special descriptors are defined to request all user attributes ("*")
[RFC2251] and all operational attributes ("+") [OPATTRS]. However,
[RFC2251] and all operational attributes ("+") [RFC3673]. 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. A plus sign ("+", U+002B) is used
to distinguish an object class identifier from an attribute
descriptions.
specified in attributes lists, such as in Search requests, to request
the return all attributes belonging to an object class. The
COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
class identifier from an attribute descriptions.
For example, the attribute list of "+country" is equivalent to the
For example, the attribute list of "@country" is equivalent to the
attribute list of 'c', 'searchGuide', 'description', and
'objectClass'. This object class and its attributes are described in
[RFC2256].
@ -99,23 +105,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
3. 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.
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
the attributes field of the LDAP SearchRequest [RFC2251] or other
request structures who borrow the attributes field and its semantics
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
(e.g., attributes field in pre/post read controls [READENTRY]). 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 "SUP"erior) was itself listed.
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 [X.680] data
type:
@ -125,7 +133,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
The Description is string conforming to the ABNF [RFC2234]:
Description = AttributeDescription | ObjectClassDescription.
ObjectClassDescription = "+" ObjectClass *( ";" options )
ObjectClassDescription = AtSign ObjectClass *( ";" options )
AtSign = "@" ; U+0040
where <AttributeDescription> and <options> productions are as defined
in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
@ -138,8 +147,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
may be defined in future specifications.
Servers supporting this feature SHOULD publish the object identifier
(OID) 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE. Clients supporting this feature
(OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
[RFC3674] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
@ -148,30 +157,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
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 raise additional
individually, this shorthand is not believed to raise additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP security considerations [RFC3377].
4. IANA Considerations
The OID 1.3.6.1.4.1.4203.1.11.2 is used to identify the LDAP "OC AD
List" feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation,
under its IANA-assigned private enterprise allocation [PRIVATE], for
use in this specification.
Registration of this protocol mechanism is requested per BCP 64
[RFC3383].
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
4. IANA Considerations
Registration of the LDAP Protocol Mechanism [RFC3383] defined in
document is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.2
Description: OC AD Lists
@ -182,12 +186,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
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>
Email: Kurt@OpenLDAP.org
6. Normative References
@ -209,8 +218,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt, a work in progress.
[Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
December 2003.
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
@ -220,14 +237,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
7. Informative References
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
@ -237,6 +246,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
3673, December 2003.
[READENTRY] Zeilenga, K., "LDAP Read Entry Controls",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
@ -247,37 +263,78 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Zeilenga Requesting Attributes by Object Class [Page 6]

167
doc/drafts/draft-zeilenga-ldap-assert-xx.txt
View file

@ -3,21 +3,17 @@
INTERNET-DRAFT Kurt D. Zeilenga
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 25 October 2003
Expires in six months 18 July 2004
The LDAP Assertion Control
<draft-zeilenga-ldap-assert-01.txt>
<draft-zeilenga-ldap-assert-03.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 IESG for consideration as a Standard Track
document. Distribution of this memo is unlimited. Technical
@ -25,20 +21,27 @@ Status of this Memo
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
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.''
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
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@ -48,16 +51,17 @@ Abstract
This document defines the Lightweight Directory Access Protocol (LDAP)
Assertion Control which allows a client to specify that a directory
operation should only be processed if an assertion applied to the
target entry of the operation is true. It can be used to construct
"test and set" and "test and clear" and other conditional operations.
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
operation should only be processed if an assertion applied to the
target entry of the operation is true. It can be used to construct
"test and set" and "test and clear" and other conditional operations.
1. Overview
@ -70,8 +74,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
The control can be used with the Modify operation [RFC2251] to perform
atomic "test and set" and "test and clear" operations as the asserted
condition is evaluated as an integral part the operation. The control
may be attached to other update operations to support conditional add,
delete, and renaming of objects.
may be attached to other update operations to support conditional
addition, deletion, and renaming of objects.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
@ -103,19 +107,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
Unbind operations. It is also inappropriate for the Start TLS
[RFC2830] operation.
Zeilenga LDAP Assertion Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
Unbind operations. It is also inappropriate for the Start TLS
[RFC2830] operation.
When the control is attached to an LDAP request, the processing of the
request is conditional on the evaluation of the Filter as applied
against the target of the operation. If the Filter evaluates to TRUE,
@ -133,8 +138,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
[RFC2251]. Hence, if the evaluation fails, no entries or
continuations references are returned.
[RFC2251]. Hence, no entries or continuations references are returned
if the assertion fails.
Servers implementing this technical specification SHOULD publish the
object identifier IANA-ASSIGNED-OID as a value of the
@ -154,22 +159,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
appropriately protected.
As with any general assertion mechanism, the mechanism can be used to
determine directory content. Hence, the mechanism SHOULD be subject
determine directory content. Hence, this mechanism SHOULD be subject
to appropriate access controls.
Some assertions may be very complex, requiring significant time and
resources to evaluate. Hence, the mechanism SHOULD be subject to
appropriate administrative controls.
All security considerations for the base operations [RFC2251] to which
this control is attached to apply, as do general LDAP security
considerations [RFC3377].
Zeilenga LDAP Assertion Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
resources to evaluate. Hence, this mechanism SHOULD be subject to
appropriate administrative controls.
All security considerations for the base operations [RFC2251] to which
this control is attached to apply, as do general LDAP security
considerations [RFC3377].
5. IANA Considerations
@ -212,6 +219,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: assertionFailed
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
@ -222,17 +237,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
The assertion control concept is attributed to Morteza Ansari.
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Email: Kurt@OpenLDAP.org
8. Normative References
@ -262,61 +272,50 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
@ -337,3 +336,5 @@ Full Copyright
Zeilenga LDAP Assertion Control [Page 6]

3
doc/rfc/INDEX
View file

@ -15,7 +15,6 @@ rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2596.txt Use of Language Codes in LDAP (PS)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2696.txt LDAP Simple Paged Result Control (I)
rfc2713.txt LDAP Java schema (I)
@ -44,6 +43,8 @@ rfc3703.txt LDAP: Schema for Policy Core (PS)
rfc3712.txt LDAP: Schema for Printer Services (I)
rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
rfc3771.txt LDAP: Intermediate Response Message (PS)
rfc3829.txt LDAP Authorization Identity Controls (I)
rfc3866.txt Language Tag and Ranges in LDAP (PS)
Legend:
STD Standard

507
doc/rfc/rfc2596.txt
View file

@ -1,507 +0,0 @@
Network Working Group M. Wahl
Request for Comments: 2596 Innosoft International, Inc.
Category: Standards Track T. Howes
Netscape Communications Corp.
May 1999
Use of Language Codes in LDAP
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract
The Lightweight Directory Access Protocol [1] 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 [2] of entries. Most of these attributes have syntaxes
which are human-readable strings, and it is desirable to be able to
indicate the natural language associated with attribute values.
This document describes how language codes [3] are carried in LDAP
and are to be interpreted by LDAP servers. All implementations MUST
be prepared to accept language codes in the LDAP protocols. Servers
may or may not be capable of storing attributes with language codes
in the directory. This document does not specify how to determine
whether particular attributes can or cannot have language codes.
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 RFC 2119 [4].
2. Language Codes
Section 2 of RFC 1766 [3] describes the language code format which is
used in LDAP. Briefly, it is a string of ASCII alphabetic characters
and hyphens. Examples include "fr", "en-US" and "ja-JP".
Wahl & Howes Standards Track [Page 1]
RFC 2596 Use of Language Codes in LDAP May 1999
Language codes are case insensitive. For example, the language code
"en-us" is the same as "EN-US" and "en-US".
Implementations MUST NOT otherwise interpret the structure of the
code when comparing two codes, and MUST treat them as simply strings
of characters. Client and server implementations MUST allow any
arbitrary string which follows the patterns given in RFC 1766 to be
used as a language code.
3. Use of Language Codes in LDAP
This section describes how LDAP implementations MUST interpret
language codes in performing operations.
In general, an attribute with a language code is to be treated as a
subtype of the attribute without a language code. If a server does
not support storing language codes with attribute values in the DIT,
then it MUST always treat an attribute with a language code as an
unrecognized attribute.
3.1. Attribute Description
An attribute consists of a type, a list of options for that type, and
a set of one or more values. In LDAP, the type and the options are
combined into the AttributeDescription, defined in section 4.1.5 of
[1]. This is represented as an attribute type name and a possibly-
empty list of options. One of these options associates a natural
language with values for that attribute.
language-option = "lang-" lang-code
lang-code = printable-ascii ; a code as defined in RFC 1766
Multiple language options may be present on a particular value.
The language code has no effect on the character set encoding for
string representations of DirectoryString syntax values; the UTF-8
representation of UniversalString (ISO 10646) is always used.
Examples of valid AttributeDescription:
givenName;lang-en-US
CN;lang-ja
In LDAP and in examples in this document, a directory attribute is
represented as an AttributeDescription with a list of values. Note
that the data could be stored in the LDAP server in a different
representation.
Wahl & Howes Standards Track [Page 2]
RFC 2596 Use of Language Codes in LDAP May 1999
3.2. Distinguished Names and Relative Distinguished Names
No attribute description options are permitted in Distinguished Names
or Relative Distinguished Names. Thus language codes MUST NOT be
used in forming DNs.
3.3. Search Filter
If a language code is present in an AttributeDescription in a search
filter, then only attribute values in the directory which match the
base attribute type or its subtype, the language code and the
assertion value match this filter.
Thus for example a filter of an equality match of type "name;lang-
en-US" and assertion value "Billy Ray", against the following
directory entry
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
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
CN;lang-EN-US;dynamic: Billy Ray MATCHES
CN;lang-en;dynamic: Billy Ray DOES NOT MATCH (differing lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN: Ray DOES NOT MATCH (wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
Client implementors should however note that providing a language
code in a search filter AttributeDescription will often filter out
desirable values where the language code 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 language codes with attribute
values in the DIT, then any filter which includes a language code
will always fail to match, as it is an unrecognized attribute type.
No error would be returned because of this; a presence filter would
evaluate to FALSE and all other forms to Undefined.
If no language code is specified in the search filter, then only the
base attribute type and the assertion value need match the value in
the directory.
Thus for example a filter of an equality match of type "name" and
assertion value "Billy Ray", against the following directory entry
Wahl & Howes Standards Track [Page 3]
RFC 2596 Use of Language Codes in LDAP May 1999
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
name;lang-EN-US: Billy Ray MATCHES
name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-EN-US;dynamic: Billy Ray MATCHES
CN;lang-en;dynamic: Billy Ray MATCHES
name: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (wrong value)
Thus in general, clients SHOULD NOT use the language code option in
AttributeDescription fields in search filters.
3.4. Compare
A language code 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 codes in a search filter with
an equality match, as described in the previous section. If there is
no attribute in the entry with the same subtype and language code,
the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name" and assertion value
"Johann", against an entry with all the following directory entry
objectclass: top
objectclass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius
will cause the server to return compareTrue.
However, if the client issued a compare request of type "name;lang-
de" and assertion value "Johann" against the above entry, the request
would fail with the noSuchAttributeType error.
If the server does not support storing language codes with attribute
values in the DIT, then any comparison which includes a language code
will always fail to locate an attribute type, and noSuchAttributeType
will be returned.
Thus in general, clients SHOULD NOT use the language code option in
AttributeDescription fields in the compare request.
3.5. Requested Attributes in Search
Clients MAY provide language codes in AttributeDescription in the
requested attribute list in a search request.
Wahl & Howes Standards Track [Page 4]
RFC 2596 Use of Language Codes in LDAP May 1999
If a language code is provided in an attribute description, then only
attribute values in a directory entry which have the same language
code as that provided are to be returned. Thus if a client requests
an attribute "description;lang-en", the server MUST NOT return values
of an attribute "description" or "description;lang-fr".
Clients MAY provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
different options. For example a client MAY provide both "name;lang-
en" and "name;lang-fr", and this would permit an attribute with
either language code to be returned. Note there would be no need to
provide both "name" and "name;lang-en" since all subtypes of name
would match "name".
If a server does not support storing language codes with attribute
values in the DIT, then any attribute descriptions in the list which
include language codes are to be ignored, just as if they were
unknown attribute types.
If a request is made specifying all attributes or an attribute is
requested without providing a language code, then all attribute
values regardless of their language code are returned.
For example, if the client requests a "description" attribute, and a
matching entry contains
objectclass: top
objectclass: organization
O: Software GmbH
description: software
description;lang-en: software products
description;lang-de: Softwareprodukte
postalAddress: Berlin 8001 Germany
postalAddress;lang-de: Berlin 8001 Deutschland
The server will return:
description: software
description;lang-en: software products
description;lang-de: Softwareprodukte
3.6. Add Operation
Clients MAY provide language codes in AttributeDescription in
attributes of a new entry to be created, subject to the limitation
that the client MUST NOT use language codes in the attribute value or
values which form the RDN of the entry.
Wahl & Howes Standards Track [Page 5]
RFC 2596 Use of Language Codes in LDAP May 1999
A client MAY provide multiple attributes with the same attribute type
and value, so long as each attribute has a different language code,
and at most one attribute does not have a language code option.
Servers which support storing language codes in the DIT MUST allow
any attribute it recognizes that has the Directory String syntax to
have a language option associated with it. Servers SHOULD allow
language options to be associated with other attributes.
For example, the following is a legal request.
objectclass: top
objectclass: person
objectclass: residentialPerson
name: John Smith
CN: John Smith
CN;lang-en: John Smith
SN: Smith
streetAddress: 1 University Street
streetAddress;lang-en: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
If a server does not support storing language codes with attribute
values in the DIT, then it MUST treat an AttributeDescription with a
language code as an unrecognized attribute. If the server forbids the
addition of unrecognized attributes then it MUST fail the add request
with the appropriate result code.
3.7. Modify Operation
A client MAY provide a language code in an AttributeDescription as
part of a modification element in the modify operation.
Attribute types and language codes MUST match exactly against values
stored in the directory. For example, if the modification is a
"delete", then if the stored values to be deleted have a language
code, the language code MUST be provided in the modify operation, and
if the stored values to be deleted do not have a language code, then
no language code is to be provided.
If the server does not support storing language codes with attribute
values in the DIT, then it MUST treat an AttributeDescription with a
language code as an unrecognized attribute, and MUST fail the request
with an appropriate result code.
Wahl & Howes Standards Track [Page 6]
RFC 2596 Use of Language Codes in LDAP May 1999
3.8. Diagnostic Messages
Servers SHOULD use only printable ASCII characters in the
errorMessage field, as not all clients will be able to display the
full range of Unicode.
4. Differences from X.500(1997)
X.500(1997) defines a different mechanism, contexts, as the means of
representing language tags. 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 RFC 1766, which allows for IANA registration of
new tags.
c) LDAP does not allow language codes in distinguished names.
d) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
5. Security Considerations
There are no known security considerations for this document. See
the security considerations sections of [1] and [2] for security
considerations of LDAP in general.
6. Acknowledgements
This document is a product of the IETF ASID and LDAPEXT working
groups. Martin Duerst provided many valuable comments on an earlier
version of this document.
7. Bibliography
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[2] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
X.500 Directory Access Protocol Attribute Syntax Definitions",
RFC 2252, December 1997.
[3] Alvestrand, H.,"Tags for the Identification of Languages", RFC
1766, March 1995.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Wahl & Howes Standards Track [Page 7]
RFC 2596 Use of Language Codes in LDAP May 1999
8. Authors' Addresses
Mark Wahl
Innosoft International, Inc.
8911 Capital of Texas Hwy Suite 4140
Austin, TX 78759 USA
EMail: M.Wahl@innosoft.com
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd
Mountain View, CA 94043 USA
Phone: +1 650 937-3419
EMail: howes@netscape.com
Wahl & Howes Standards Track [Page 8]
RFC 2596 Use of Language Codes in LDAP May 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wahl & Howes Standards Track [Page 9]