draft-ietf-ldapbis-bcp64-05.txt   draft-ietf-ldapbis-bcp64-06.txt 
INTERNET-DRAFT Kurt D. Zeilenga INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: BCP OpenLDAP Foundation Intended Category: BCP OpenLDAP Foundation
Expires in six months 21 February 2005 Expires in six months 23 January 2006
Obsoletes: RFC 3383 Obsoletes: RFC 3383
IANA Considerations for LDAP IANA Considerations for LDAP
<draft-ietf-ldapbis-bcp64-05.txt> <draft-ietf-ldapbis-bcp64-06.txt>
Status of Memo Status of Memo
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Best Current Practice revision, submitted to the RFC Editor as a Best Current Practice
document. This document is intended to replace RFC 3383. document. This document is intended to replace RFC 3383.
Distribution of this memo is unlimited. Technical discussion of this Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group document will take place on the IETF LDAP Revision Working Group
(LDAPBIS) mailing list <ietf-ldapbis@openldap.org>. Please send (LDAPBIS) mailing list <ietf-ldapbis@openldap.org>. Please send
editorial comments directly to the document editor editorial comments directly to the document editor
<Kurt@OpenLDAP.org>. <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section By submitting this Internet-Draft, each author represents that any
4 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which he or she is aware
applicable patent or other IPR claims of which I am aware have been have been or will be disclosed, and any of which he or she becomes
disclosed, or will be disclosed, and any of which I become aware will aware will be disclosed, in accordance with Section 6 of BCP 79.
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006). All Rights Reserved.
Please see the Full Copyright section near the end of this document Please see the Full Copyright section near the end of this document
for more information. for more information.
Abstract Abstract
This document provides procedures for registering extensible elements This document provides procedures for registering extensible elements
of Lightweight Directory Access Protocol (LDAP). The document also of Lightweight Directory Access Protocol (LDAP). The document also
provides guidelines to Internet Assigned Numbers Authority (IANA) provides guidelines to Internet Assigned Numbers Authority (IANA)
describing conditions under which new values can be assigned. describing conditions under which new values can be assigned.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. In document are to be interpreted as described in BCP 14 [RFC2119]. In
this case, "the specification" as used by BCP 14 refers to the this case, "the specification" as used by BCP 14 refers to the
processing of protocols being submitted to the IETF standards processing of protocols being submitted to the IETF standards
process. process.
2.3. Common ABNF Productions 2.3. Common ABNF Productions
A number of syntaxes in this document are described using ABNF A number of syntaxes in this document are described using ABNF
[RFC2234]. These syntaxes rely on the following common productions: [ABNF]. These syntaxes rely on the following common productions:
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
LDIGIT = %x31-39 ; "1"-"9" LDIGIT = %x31-39 ; "1"-"9"
DIGIT = %x30 / LDIGIT ; "0"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9"
HYPHEN = %x2D ; "-" HYPHEN = %x2D ; "-"
DOT = %x2E ; "." DOT = %x2E ; "."
number = DIGIT / ( LDIGIT 1*DIGIT ) number = DIGIT / ( LDIGIT 1*DIGIT )
keychar = ALPHA / DIGIT / HYPHEN keychar = ALPHA / DIGIT / HYPHEN
leadkeychar = ALPHA leadkeychar = ALPHA
keystring = leadkeychar *keychar keystring = leadkeychar *keychar
A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
Unicode [Unicode] restricted to the <keystring> production. Unicode [Unicode] restricted to the <keystring> production.
3. IANA Considerations for LDAP 3. IANA Considerations for LDAP
This section details each kind of protocol value which can be This section details each kind of protocol value which can be
registered and provides IANA guidelines on how to assign new values. registered and provides IANA guidelines on how to assign new values.
IANA may reject obviously bogus registrations described. IANA may reject obviously bogus registrations.
LDAP values specified in RFCs MUST be registered. Other LDAP values, LDAP values specified in RFCs MUST be registered. Other LDAP values,
expecting those in private-use name spaces, SHOULD be registered. except those in private-use name spaces, SHOULD be registered. RFCs
RFCs SHOULD NOT reference, use, or otherwise recongize unregistered SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
LDAP values. values.
3.1. Object Identifiers 3.1. Object Identifiers
Numerous LDAP schema and protocol elements are identified by Object Numerous LDAP schema and protocol elements are identified by Object
Identifiers (OIDs) [X.680]. Specifications which assign OIDs to Identifiers (OIDs) [X.680]. Specifications which assign OIDs to
elements SHOULD state who delegated the OIDs for its use. elements SHOULD state who delegated the OIDs for its use.
For IETF developed elements, specifications SHOULD use OIDs under For IETF developed elements, specifications SHOULD use OIDs under
"Internet Directory Numbers" (1.3.6.1.1.x). For elements developed "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
by others, any properly delegated OID can be used, including those by others, any properly delegated OID can be used, including those
under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
Enterprise Numbers" (1.3.6.1.4.1.x). Enterprise Numbers" (1.3.6.1.4.1.x).
Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
Review with Specification Required. Only one OID per specification Review with Specification Required. Only one OID per specification
will be assigned. The specification MAY then assign any number of will be assigned. The specification MAY then assign any number of
OIDs within this arc without further coordination with IANA. OIDs within this arc without further coordination with IANA.
Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
assignment of Internet Private Enterprise Numbers is detailed in STD assignment of Internet Private Enterprise Numbers is detailed in RFC
16 [RFC1155]. 2578 [RFC2578].
To avoid interoperability problems between early implementations of a To avoid interoperability problems between early implementations of a
"work in progress" and implementations of the published specification "work in progress" and implementations of the published specification
(e.g., the RFC), experimental OIDs SHOULD be used in "works in (e.g., the RFC), experimental OIDs SHOULD be used in "works in
progress" and early implementations. OIDs under the Internet progress" and early implementations. OIDs under the Internet
Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
Practices for IANA assignment of these Internet Experimental numbers Practices for IANA assignment of these Internet Experimental numbers
is detailed in STD 16 [RFC1155]. is detailed in RFC 2578 [RFC2578]
3.2 Protocol Mechanisms 3.2 Protocol Mechanisms
LDAP provides a number of Root DSE attributes for discovery of LDAP provides a number of Root DSE attributes for discovery of
protocol mechanisms identified by OIDs, including the protocol mechanisms identified by OIDs, including the
supportedControl, supportedExtension, and supportedFeatures supportedControl, supportedExtension, and supportedFeatures
attributes [Models], attributes [Models],
A registry of OIDs used for discover of protocol mechanisms is A registry of OIDs used for discover of protocol mechanisms is
provided to allow implementors and others to locate the technical provided to allow implementors and others to locate the technical
skipping to change at page 5, line 24 skipping to change at page 5, line 24
LDAP allows short descriptive names (or descriptors) to be used LDAP allows short descriptive names (or descriptors) to be used
instead of a numeric Object Identifier to identify select protocol instead of a numeric Object Identifier to identify select protocol
extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL]
extensions, and other objects. extensions, and other objects.
While the protocol allows the same descriptor to refer to different While the protocol allows the same descriptor to refer to different
object identifiers in certain cases and the registry supports object identifiers in certain cases and the registry supports
multiple registrations of the same descriptor (each indicating a multiple registrations of the same descriptor (each indicating a
different kind of schema element and different object identifier), different kind of schema element and different object identifier),
multiple registrations of the same descriptor are to be avoided. All multiple registrations of the same descriptor are to be avoided. All
such registration requests require Expert Review. such multiple registration requests require Expert Review.
Descriptors are restricted to strings of UTF-8 encoded Unicode Descriptors are restricted to strings of UTF-8 encoded Unicode
characters restricted by the following ABNF: characters restricted by the following ABNF:
name = keystring name = keystring
Descriptors are case-insensitive. Descriptors are case-insensitive.
Multiple names may be assigned to a given OID. For purposes of Multiple names may be assigned to a given OID. For purposes of
registration, an OID is to be represented in numeric OID form (e.g., registration, an OID is to be represented in numeric OID form (e.g.,
skipping to change at page 10, line 35 skipping to change at page 10, line 35
all values requiring Standards Action. all values requiring Standards Action.
If the policy is Expert Review, the requester SHALL post the If the policy is Expert Review, the requester SHALL post the
completed form to the <directory@apps.ietf.org> mailing list for completed form to the <directory@apps.ietf.org> mailing list for
public review. The review period is two (2) weeks. If a revised public review. The review period is two (2) weeks. If a revised
form is later submitted, the review period is restarted. Anyone may form is later submitted, the review period is restarted. Anyone may
subscribe to this list by sending a request to subscribe to this list by sending a request to
<directory-request@apps.ietf.org>. During the review, objections may <directory-request@apps.ietf.org>. During the review, objections may
be raised by anyone (including the Expert) on the list. After be raised by anyone (including the Expert) on the list. After
completion of the review, the Expert, based upon public comments, completion of the review, the Expert, based upon public comments,
SHALL either approve the request and forward it to the IESG OR deny SHALL either approve the request and forward it to the IANA OR deny
the request. In either case, the Expert SHALL promptly notify the the request. In either case, the Expert SHALL promptly notify the
requester of the action. Actions of the Expert may be appealed requester of the action. Actions of the Expert may be appealed
[RFC2026]. The Expert is appointed by Applications Area Director(s). [RFC2026]. The Expert is appointed by Applications Area Director(s).
The requester is viewed as the owner of values registered under The requester is viewed as the owner of values registered under
Expert Review. Expert Review.
If the policy is First Come First Served, the requester SHALL submit If the policy is First Come First Served, the requester SHALL submit
the completed form directly to the IANA: <iana@iana.org>. The the completed form directly to the IANA: <iana@iana.org>. The
requester is viewed as the owner of values registered under First requester is viewed as the owner of values registered under First
Come First Served. Come First Served.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
Email: Kurt@OpenLDAP.org Email: Kurt@OpenLDAP.org
9. References 9. References
[[Note to the RFC Editor: please replace the citation tags used in [[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]] possible.]]
9.1. Normative References 9.1. Normative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-
based Internets", STD 16 (also RFC 1155), May 1990.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9 (also RFC 2026), October 1996. 3", BCP 9 (also RFC 2026), October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997. Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26 (also RFC IANA Considerations Section in RFCs", BCP 26 (also RFC
2434), October 1998. 2434), October 1998.
[RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure
of Management Information Version 2 (SMIv2)", RFC 2578
(STD: 58), April 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003. 10646", RFC 3629 (also STD 63), November 2003.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress. progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information [Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in Models", draft-ietf-ldapbis-models-xx.txt, a work in
skipping to change at page 20, line 41 skipping to change at page 20, line 41
C.5. LDAP authzId prefixes C.5. LDAP authzId prefixes
Name Prefix Owner Reference Name Prefix Owner Reference
---------------- ------ ----- --------- ---------------- ------ ----- ---------
dnAuthzId dn: IESG [AuthMeth] dnAuthzId dn: IESG [AuthMeth]
uAuthzId u: IESG [AuthMeth] uAuthzId u: IESG [AuthMeth]
Full Copyright Full Copyright
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Rights Intellectual Property Rights
 End of changes. 16 change blocks. 
28 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/