draft-ietf-ldapbis-bcp64-07.txt   rfc4520.txt 
INTERNET-DRAFT Kurt D. Zeilenga Network Working Group K. Zeilenga
Intended Category: BCP OpenLDAP Foundation Request for Comments: 4520 OpenLDAP Foundation
Expires in six months 31 January 2006
Obsoletes: RFC 3383
IANA Considerations for LDAP
<draft-ietf-ldapbis-bcp64-07.txt>
Status of Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Best Current Practice
document. This document is intended to replace RFC 3383.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
(LDAPBIS) mailing list <ietf-ldapbis@openldap.org>. Please send
editorial comments directly to the document editor
<Kurt@OpenLDAP.org>.
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Obsoletes: 3383
Task Force (IETF), its areas, and its working groups. Note that other Category: Best Current Practice
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet Assigned Numbers Authority (IANA) Considerations for
and may be updated, replaced, or obsoleted by other documents at any the Lightweight Directory Access Protocol (LDAP)
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 Status of This Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet Best Current Practices for the
http://www.ietf.org/shadow.html Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2006). All Rights Reserved. Copyright Notice
Please see the Full Copyright section near the end of this document Copyright (C) The Internet Society (2006).
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 the Lightweight Directory Access Protocol (LDAP). The document
provides guidelines to Internet Assigned Numbers Authority (IANA) also provides guidelines to the Internet Assigned Numbers Authority
describing conditions under which new values can be assigned. (IANA) describing conditions under which new values can be assigned.
1. Introduction 1. Introduction
The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
extensible protocol. LDAP supports: extensible protocol. LDAP supports:
- addition of new operations, - the addition of new operations,
- extension of existing operations, and - the extension of existing operations, and
- extensible schema. - the extensible schema.
This document details procedures for registering values of used to
unambiguously identify extensible elements of the protocol including:
- LDAP message types; This document details procedures for registering values used to
- LDAP extended operations and controls; unambiguously identify extensible elements of the protocol, including
- LDAP result codes; the following:
- LDAP authentication methods;
- LDAP attribute description options; and
- Object Identifier descriptors.
- LDAP message types
- LDAP extended operations and controls
- LDAP result codes
- LDAP authentication methods
- LDAP attribute description options
- Object Identifier descriptors
These registries are maintained by the Internet Assigned Numbers These registries are maintained by the Internet Assigned Numbers
Authority (IANA). Authority (IANA).
In addition, this document provides guidelines to IANA describing the In addition, this document provides guidelines to IANA describing the
conditions under which new values can be assigned. conditions under which new values can be assigned.
This document replaces RFC 3383. This document replaces RFC 3383.
2. Terminology and Conventions 2. Terminology and Conventions
skipping to change at page 3, line 11 skipping to change at page 2, line 30
and "Private Use" are used as defined in BCP 26 [RFC2434]. and "Private Use" are used as defined in BCP 26 [RFC2434].
The term "registration owner" (or "owner") refers to the party The term "registration owner" (or "owner") refers to the party
authorized to change a value's registration. authorized to change a value's registration.
2.2. Requirement Terminology 2.2. Requirement Terminology
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
[ABNF]. These syntaxes rely on the following common productions: [RFC4234]. 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
keyword = keystring keyword = keystring
Keywords are case-insensitive. Keywords are case insensitive.
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 that 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. 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,
except those in private-use name spaces, SHOULD be registered. RFCs except those in private-use name spaces, SHOULD be registered. RFCs
SHOULD NOT reference, use, or otherwise recognize unregistered LDAP SHOULD NOT reference, use, or otherwise recognize unregistered 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 that assign OIDs to
elements SHOULD state who delegated the OIDs for its use. elements SHOULD state who delegated the OIDs for their 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 RFC assignment of Internet Private Enterprise Numbers are detailed in RFC
2578 [RFC2578]. 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 RFC 2578 [RFC2578] are 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 DSA-Specific Entry (DSE) attributes
protocol mechanisms identified by OIDs, including the for discovery of protocol mechanisms identified by OIDs, including
supportedControl, supportedExtension, and supportedFeatures the supportedControl, supportedExtension, and supportedFeatures
attributes [Models], attributes [RFC4512].
A registry of OIDs used for discover of protocol mechanisms is A registry of OIDs used for discovery of protocol mechanisms is
provided to allow implementors and others to locate the technical provided to allow implementors and others to locate the technical
specification for these protocol mechanisms. Future specifications specification for these protocol mechanisms. Future specifications
of additional Root DSE attributes holding values identifying protocol of additional Root DSE attributes holding values identifying protocol
mechanisms MAY extend this registry for their values. mechanisms MAY extend this registry for their values.
Protocol Mechanisms are registered on a First Come First Served Protocol mechanisms are registered on a First Come First Served
basis. basis.
3.3 LDAP Syntaxes 3.3. LDAP Syntaxes
This registry provides a listing of LDAP syntaxes [Models]. Each This registry provides a listing of LDAP syntaxes [RFC4512]. Each
LDAP syntax is identified by an object identifier (OID). This LDAP syntax is identified by an OID. This registry is provided to
registry is provided to allow implementors and others to locate the allow implementors and others to locate the technical specification
technical specification describing a particular LDAP Syntax. describing a particular LDAP Syntax.
LDAP Syntaxes are registered on a First Come First Served with LDAP Syntaxes are registered on a First Come First Served with
Specification Required basis. Specification Required basis.
Note: unlike object classes, attribute types and various other kinds Note: Unlike object classes, attribute types, and various other kinds
of schema elements, descriptors are not used in LDAP to identify LDAP of schema elements, descriptors are not used in LDAP to
Syntaxes. identify LDAP Syntaxes.
3.4. Object Identifier Descriptors 3.4. Object Identifier Descriptors
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 [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
extensions, and other objects. extensions, and other objects.
While the protocol allows the same descriptor to refer to different Although the protocol allows the same descriptor to refer to
object identifiers in certain cases and the registry supports different object identifiers in certain cases and the registry
multiple registrations of the same descriptor (each indicating a supports multiple registrations of the same descriptor (each
different kind of schema element and different object identifier), indicating a different kind of schema element and different object
multiple registrations of the same descriptor are to be avoided. All identifier), multiple registrations of the same descriptor are to be
such multiple registration requests require Expert Review. avoided. All 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 [RFC3629] encoded
characters restricted by the following ABNF: Unicode 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.,
1.1.0.23.40) conforming to the ABNF: 1.1.0.23.40) conforming to the following ABNF:
numericoid = number 1*( DOT number ) numericoid = number 1*( DOT number )
While the protocol places no maximum length restriction upon While the protocol places no maximum length restriction upon
descriptors, they should be short. Descriptors longer than 48 descriptors, they should be short. Descriptors longer than 48
characters may be viewed as too long to register. characters may be viewed as too long to register.
A value ending with a hyphen ("-") reserves all descriptors which A value ending with a hyphen ("-") reserves all descriptors that
start with that value. For example, the registration of the option start with that value. For example, the registration of the option
"descrFamily-" reserves all options which start with "descrFamily-" "descrFamily-" reserves all options that start with "descrFamily-"
for some related purpose. for some related purpose.
Descriptors beginning with "x-" are for Private Use and cannot be Descriptors beginning with "x-" are for Private Use and cannot be
registered. registered.
Descriptors beginning with "e-" are reserved for experiments and will Descriptors beginning with "e-" are reserved for experiments and will
be registered on a First Come First Served basis. be registered on a First Come First Served basis.
All other descriptors require Expert Review to be registered. All other descriptors require Expert Review to be registered.
The registrant need not "own" the OID being named. The registrant need not "own" the OID being named.
The OID name space is managed by The ISO/IEC Joint Technical The OID name space is managed by the ISO/IEC Joint Technical
Committee 1 - Subcommittee 6. Committee 1 - Subcommittee 6.
3.5. AttributeDescription Options 3.5. AttributeDescription Options
An AttributeDescription [Models] can contain zero or more options An AttributeDescription [RFC4512] can contain zero or more options
specifying additional semantics. An option SHALL be restricted to a specifying additional semantics. An option SHALL be restricted to a
string UTF-8 encoded Unicode characters limited by the following string of UTF-8 encoded Unicode characters limited by the following
ABNF: ABNF:
option = keystring option = keystring
Options are case-insensitive. Options are case insensitive.
While the protocol places no maximum length restriction upon option While the protocol places no maximum length restriction upon option
strings, they should be short. Options longer than 24 characters may strings, they should be short. Options longer than 24 characters may
be viewed as too long to register. be viewed as too long to register.
Values ending with a hyphen ("-") reserve all option names which Values ending with a hyphen ("-") reserve all option names that start
start with the name. For example, the registration of the option with the name. For example, the registration of the option
"optionFamily-" reserves all options which start with "optionFamily-" "optionFamily-" reserves all options that start with "optionFamily-"
for some related purpose. for some related purpose.
Options beginning with "x-" are for Private Use and cannot be Options beginning with "x-" are for Private Use and cannot be
registered. registered.
Options beginning with "e-" are reserved for experiments and will be Options beginning with "e-" are reserved for experiments and will be
registered on a First Come First Served basis. registered on a First Come First Served basis.
All other options require Standards Action or Expert Review with All other options require Standards Action or Expert Review with
Specification Required to be registered. Specification Required to be registered.
3.6. LDAP Message Types 3.6. LDAP Message Types
Each protocol message is encapsulated in an LDAPMessage envelope Each protocol message is encapsulated in an LDAPMessage envelope
[Protocol]. The protocolOp CHOICE indicates the type of message [RFC4511. The protocolOp CHOICE indicates the type of message
encapsulated. Each message type consists of an ASN.1 identifier in encapsulated. Each message type consists of an ASN.1 identifier in
the form of a keyword and a non-negative choice number. The choice the form of a keyword and a non-negative choice number. The choice
number is combined with the class (APPLICATION) and data type number is combined with the class (APPLICATION) and data type
(CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
encoding. The choice numbers for existing protocol messages are encoding. The choice numbers for existing protocol messages are
implicit in the protocol's ASN.1 defined in [Protocol]. implicit in the protocol's ASN.1 defined in [RFC4511].
New values will be registered upon Standards Action. New values will be registered upon Standards Action.
Note: LDAP provides extensible messages which reduces, but does not Note: LDAP provides extensible messages that reduce but do not
eliminate, the need to add new message types. eliminate the need to add new message types.
3.7. LDAP Authentication Method 3.7. LDAP Authentication Method
The LDAP Bind operation supports multiple authentication methods The LDAP Bind operation supports multiple authentication methods
[Protocol]. Each authentication choice consists of an ASN.1 [RFC4511]. Each authentication choice consists of an ASN.1
identifier in the form of a keyword and a non-negative integer. identifier in the form of a keyword and a non-negative integer.
The registrant SHALL classify the authentication method usage using The registrant SHALL classify the authentication method usage using
one of the following terms: one of the following terms:
COMMON - method is appropriate for common use on the COMMON - method is appropriate for common use on the
Internet, Internet.
LIMITED USE - method is appropriate for limited use, LIMITED USE - method is appropriate for limited use.
OBSOLETE - method has been deprecated or otherwise found to OBSOLETE - method has been deprecated or otherwise found to
be inappropriate for any use. be inappropriate for any use.
Methods without publicly available specifications SHALL NOT be Methods without publicly available specifications SHALL NOT be
classified as COMMON. New registrations of class OBSOLETE cannot be classified as COMMON. New registrations of the class OBSOLETE cannot
registered. be registered.
New authentication method integers in the range 0-1023 require New authentication method integers in the range 0-1023 require
Standards Action to be registered. New authentication method Standards Action to be registered. New authentication method
integers in the range 1024-4095 require Expert Review with integers in the range 1024-4095 require Expert Review with
Specification Required. New authentication method integers in the Specification Required. New authentication method integers in the
range 4096-16383 will be registered on a First Come First Served range 4096-16383 will be registered on a First Come First Served
basis. Keywords associated with integers in the range 0-4095 SHALL basis. Keywords associated with integers in the range 0-4095 SHALL
NOT start with "e-" or "x-". Keywords associated with integers in NOT start with "e-" or "x-". Keywords associated with integers in
the range 4096-16383 SHALL start with "e-". Values greater than or the range 4096-16383 SHALL start with "e-". Values greater than or
equal to 16384 and keywords starting with "x-" are for Private Use equal to 16384 and keywords starting with "x-" are for Private Use
and cannot be registered. and cannot be registered.
Note: LDAP supports Simple Authentication and Security Layers [SASL] Note: LDAP supports Simple Authentication and Security Layers
as an authentication choice. SASL is an extensible [RFC4422] as an authentication choice. SASL is an extensible
authentication framework. authentication framework.
3.8. LDAP Result Codes 3.8. LDAP Result Codes
LDAP result messages carry an resultCode enumerated value to indicate LDAP result messages carry a resultCode enumerated value to indicate
the outcome of the operation [Protocol]. Each result code consists the outcome of the operation [RFC4511]. Each result code consists of
of a ASN.1 identifier in the form of a keyword and a non-negative an ASN.1 identifier in the form of a keyword and a non-negative
integer. integer.
New resultCodes integers in the range 0-1023 require Standards Action New resultCodes integers in the range 0-1023 require Standards Action
to be registered. New resultCode integers in the range 1024-4095 to be registered. New resultCode integers in the range 1024-4095
require Expert Review with Specification Required. New resultCode require Expert Review with Specification Required. New resultCode
integers in the range 4096-16383 will be registered on a First Come integers in the range 4096-16383 will be registered on a First Come
First Served basis. Keywords associated with integers in the range First Served basis. Keywords associated with integers in the range
0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
integers in the range 4096-16383 SHALL start with "e-". Values integers in the range 4096-16383 SHALL start with "e-". Values
greater than or equal to 16384 and keywords starting with "x-" are greater than or equal to 16384 and keywords starting with "x-" are
for Private Use and cannot be registered. for Private Use and cannot be registered.
3.9. LDAP Search Scope 3.9. LDAP Search Scope
LDAP SearchRequest messages carry a scope enumerated value to LDAP SearchRequest messages carry a scope-enumerated value to
indicate the extend of search within the DIT [Protocol] Each search indicate the extent of search within the DIT [RFC4511]. Each search
value consists of a ASN.1 identifier in the form of a keyword and a value consists of an ASN.1 identifier in the form of a keyword and a
non-negative integer. non-negative integer.
New scope integers in the range 0-1023 require Standards Action to be New scope integers in the range 0-1023 require Standards Action to be
registered. New scope integers in the range 1024-4095 require Expert registered. New scope integers in the range 1024-4095 require Expert
Review with Specification Required. New scope integers in the range Review with Specification Required. New scope integers in the range
4096-16383 will be registered on a First Come First Served basis. 4096-16383 will be registered on a First Come First Served basis.
Keywords associated with integers in the range 0-4095 SHALL NOT start Keywords associated with integers in the range 0-4095 SHALL NOT start
with "e-" or "x-". Keywords associated with integers in the range with "e-" or "x-". Keywords associated with integers in the range
4096-16383 SHALL start with "e-". Values greater than or equal to 4096-16383 SHALL start with "e-". Values greater than or equal to
16384 and keywords starting with "x-" are for Private Use and cannot 16384 and keywords starting with "x-" are for Private Use and cannot
be registered. be registered.
3.10. LDAP Filter Choice 3.10. LDAP Filter Choice
LDAP filters are used in making assertions against an object LDAP filters are used in making assertions against an object
represented in the directory [Protocol]. The Filter CHOICE indicates represented in the directory [RFC4511]. The Filter CHOICE indicates
a type of assertion. Each Filter CHOICE consists of an ASN.1 a type of assertion. Each Filter CHOICE consists of an ASN.1
identifier in the form of a keyword and a non-negative choice number. identifier in the form of a keyword and a non-negative choice number.
The choice number is combined with the class (APPLICATION) and data The choice number is combined with the class (APPLICATION) and data
type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
message's encoding. message's encoding.
Note: LDAP provides the extensibleMatching choice which reduces, but Note: LDAP provides the extensibleMatching choice, which reduces but
does not eliminate, the need to add new filter choices. does not eliminate the need to add new filter choices.
3.11. LDAP ModifyRequest Operation Type 3.11. LDAP ModifyRequest Operation Type
The LDAP ModifyRequest carries a sequence of modification operations The LDAP ModifyRequest carries a sequence of modification operations
[Protocol]. Each kind (e.g., add, delete, replace) of operation is [RFC4511]. Each kind (e.g., add, delete, replace) of operation
consists of a ASN.1 identifier in the form of a keyword and a consists of an ASN.1 identifier in the form of a keyword and a non-
non-negative integer. negative integer.
New operation type integers in the range 0-1023 require Standards New operation type integers in the range 0-1023 require Standards
Action to be registered. New operation type integers in the range Action to be registered. New operation type integers in the range
1024-4095 require Expert Review with Specification Required. New 1024-4095 require Expert Review with Specification Required. New
operation type integers in the range 4096-16383 will be registered on operation type integers in the range 4096-16383 will be registered on
a First Come First Served basis. Keywords associated with integers a First Come First Served basis. Keywords associated with integers
in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
associated with integers in the range 4096-16383 SHALL start with associated with integers in the range 4096-16383 SHALL start with
"e-". Values greater than or equal to 16384 and keywords starting "e-". Values greater than or equal to 16384 and keywords starting
with "x-" are for Private Use and cannot be registered. with "x-" are for Private Use and cannot be registered.
3.12. LDAP authzId Prefixes 3.12. LDAP authzId Prefixes
Authorization Identities in LDAP are strings conforming to the Authorization Identities in LDAP are strings conforming to the
<authzId> production [AuthMeth]. This production is extensible. <authzId> production [RFC4513]. This production is extensible. Each
Each new specific authorization form is identified by a prefix string new specific authorization form is identified by a prefix string
conforming to the following ABNF: conforming to the following ABNF:
prefix = keystring COLON prefix = keystring COLON
COLON = %x3A ; COLON (":" U+003A) COLON = %x3A ; COLON (":" U+003A)
Prefixes are case-insensitive. Prefixes are case insensitive.
While the protocol places no maximum length restriction upon prefix While the protocol places no maximum length restriction upon prefix
strings, they should be short. Prefixes longer than 12 characters strings, they should be short. Prefixes longer than 12 characters
may be viewed as too long to register. may be viewed as too long to register.
Prefixes beginning with "x-" are for Private Use and cannot be Prefixes beginning with "x-" are for Private Use and cannot be
registered. registered.
Prefixes beginning with "e-" are reserved for experiments and will be Prefixes beginning with "e-" are reserved for experiments and will be
registered on a First Come First Served basis. registered on a First Come First Served basis.
All other prefixes require Standards Action or Expert Review with All other prefixes require Standards Action or Expert Review with
Specification Required to be registered. Specification Required to be registered.
3.13. Directory Systems Names 3.13. Directory Systems Names
The IANA-maintained "Directory Systems Names" registry [IANADSN] of The IANA-maintained "Directory Systems Names" registry [IANADSN] of
valid keywords for well known attributes was used in the LDAPv2 valid keywords for well-known attributes was used in the LDAPv2
string representation of a distinguished name [RFC1779]. LDAPv2 is string representation of a distinguished name [RFC1779]. LDAPv2 is
now Historic [RFC3494]. now Historic [RFC3494].
Directory systems names are not known to be used in any other Directory systems names are not known to be used in any other
context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section context. LDAPv3 [RFC4514] uses Object Identifier Descriptors
3.2] (which have a different syntax than directory system names). [Section 3.2] (which have a different syntax than directory system
names).
New Directory System Names will no longer be accepted. For New Directory System Names will no longer be accepted. For
historical purposes, the current list of registered names should historical purposes, the current list of registered names should
remain publicly available. remain publicly available.
4. Registration Procedure 4. Registration Procedure
The procedure given here MUST be used by anyone who wishes to use a The procedure given here MUST be used by anyone who wishes to use a
new value of a type described in Section 3 of this document. new value of a type described in Section 3 of this document.
skipping to change at page 10, line 33 skipping to change at page 9, line 39
If the policy is Standards Action, the completed form SHOULD be If the policy is Standards Action, the completed form SHOULD be
provided to the IESG with the request for Standards Action. Upon provided to the IESG with the request for Standards Action. Upon
approval of the Standards Action, the IESG SHALL forward the request approval of the Standards Action, the IESG SHALL forward the request
(possibly revised) to IANA. The IESG SHALL be regarded as the (possibly revised) to IANA. The IESG SHALL be regarded as the
registration owner of all values requiring Standards Action. registration owner of 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-
<directory-request@apps.ietf.org>. During the review, objections may request@apps.ietf.org>. During the review, objections may be raised
be raised by anyone (including the Expert) on the list. After by anyone (including the Expert) on the list. After completion of
completion of the review, the Expert, based upon public comments, the review, the Expert, based on public comments, SHALL either
SHALL either approve the request and forward it to the IANA OR deny approve the request and forward it to the IANA OR deny the request.
the request. In either case, the Expert SHALL promptly notify the In either case, the Expert SHALL promptly notify the requester of the
requester of the action. Actions of the Expert may be appealed action. Actions of the Expert may be appealed [RFC2026]. The Expert
[RFC2026]. The Expert is appointed by Applications Area Director(s). is appointed by Applications Area Directors. The requester is viewed
The requester is viewed as the registration owner of values as the registration owner of values registered under Expert Review.
registered under 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 registration owner of values registered requester is viewed as the registration owner of values registered
under First Come First Served. under First Come First Served.
Neither the Expert nor IANA will take position on the claims of Neither the Expert nor IANA will take position on the claims of
copyright or trademarks issues regarding completed forms. copyright or trademark issues regarding completed forms.
Prior to submission of the Internet Draft (I-D) to the RFC Editor but Prior to submission of the Internet Draft (I-D) to the RFC Editor but
after IESG review and tentative approval, the document editor SHOULD after IESG review and tentative approval, the document editor SHOULD
revise the I-D to use registered values. revise the I-D to use registered values.
5. Registration Maintenance 5. Registration Maintenance
This section discusses maintenance of registrations. This section discusses maintenance of registrations.
5.1. Lists of Registered Values 5.1. Lists of Registered Values
IANA makes lists of registered values readily available to the IANA makes lists of registered values readily available to the
Internet community on their web site: <http://www.iana.org/>. Internet community on its web site: <http://www.iana.org/>.
5.2. Change Control 5.2. Change Control
The registration owner MAY update the registration subject to the The registration owner MAY update the registration subject to the
same constraints and review as with new registrations. In cases same constraints and review as with new registrations. In cases
where the registration owner is not unable or unwilling to make where the registration owner is unable or is unwilling to make
necessary updates, the IESG MAY assume ownership of the registration necessary updates, the IESG MAY assume ownership of the registration
in order to update the registration. in order to update the registration.
5.3. Comments 5.3. Comments
For cases where others (anyone other than the registration owner) For cases where others (anyone other than the registration owner)
have significant objections to the claims in a registration and the have significant objections to the claims in a registration and the
registration owner does not agree to change the registration, registration owner does not agree to change the registration,
comments MAY be attached to a registration upon Expert Review. For comments MAY be attached to a registration upon Expert Review. For
registrations owned by the IESG, the objections SHOULD be addressed registrations owned by the IESG, the objections SHOULD be addressed
by initiating a request for Expert Review. by initiating a request for Expert Review.
The form to these requests is ad hoc, but MUST include the specific The form of these requests is ad hoc, but MUST include the specific
objections to be reviewed and SHOULD contain (directly or by objections to be reviewed and SHOULD contain (directly or by
reference) materials supporting the objections. reference) materials supporting the objections.
6. Security Considerations 6. Security Considerations
The security considerations detailed in BCP 26 [RFC2434] are The security considerations detailed in BCP 26 [RFC2434] are
generally applicable to this document. Additional security generally applicable to this document. Additional security
considerations specific to each name space are discussed in Section 3 considerations specific to each name space are discussed in Section
where appropriate. 3, where appropriate.
Security considerations for LDAP are discussed in documents Security considerations for LDAP are discussed in documents
comprising the technical specification [Roadmap]. comprising the technical specification [RFC4510].
7. Acknowledgment 7. Acknowledgement
This document is a product of the IETF LDAP Revision (LDAPBIS) This document is a product of the IETF LDAP Revision (LDAPBIS)
Working Group (WG). This document is a revision of RFC 3383, also a Working Group (WG). This document is a revision of RFC 3383, also a
product of the LDAPBIS WG. product of the LDAPBIS WG.
This document includes text borrowed from "Guidelines for Writing an This document includes text borrowed from "Guidelines for Writing an
IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
Harald Alvestrand. Harald Alvestrand.
8. Author's Address 8. References
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
9. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
9.1. Normative References 8.1. Normative References
[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, 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, RFC 2119, March 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, RFC 2434,
2434), October 1998. October 1998.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[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", STD 63, RFC 3629, November 2003.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in (LDAP): Technical Specification Road Map", RFC 4510, June
progress. 2006.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Connection Level Security Mechanisms", Protocol (LDAP): The Protocol", RFC 4511, June 2006.
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
Models", draft-ietf-ldapbis-models-xx.txt, a work in (LDAP): Directory Information Models", RFC 4512, June
progress. 2006.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
draft-ietf-ldapbis-url-xx.txt, a work in progress. Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
2006.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0" 3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the 3.1" (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[X.680] International Telecommunication Union - [X.680] International Telecommunication Union - Telecommunication
Telecommunication Standardization Sector, "Abstract Standardization Sector, "Abstract Syntax Notation One
Syntax Notation One (ASN.1) - Specification of Basic (ASN.1) - Specification of Basic Notation", X.680(2002)
Notation", X.680(2002) (also ISO/IEC 8824-1:2002). (also ISO/IEC 8824-1:2002).
9.2. Informative References 8.2. Informative References
[RFC1779] Kille, S., "A String Representation of Distinguished [RFC1779] Kille, S., "A String Representation of Distinguished
Names", RFC 1779, March 1995. Names", RFC 1779, March 1995.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March version 2 (LDAPv2) to Historic Status", RFC 3494, March
2003. 2003.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. (LDAP): String Representation of Distinguished Names", RFC
4514, June 2006.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[SASL] Melnikov, A. (Editor), "Simple Authentication and [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Security Layer (SASL)", Authentication and Security Layer (SASL)", RFC 4422, June
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 2006.
[IANADSN] IANA, "Directory Systems Names", [IANADSN] IANA, "Directory Systems Names",
http://www.iana.org/assignments/directory-system-names. http://www.iana.org/assignments/directory-system-names.
Appendix A. Registration Templates Appendix A. Registration Templates
This appendix provides registration templates for registering new This appendix provides registration templates for registering new
LDAP values. Note that more than one value may be requested by LDAP values. Note that more than one value may be requested by
extending the template by listing multiple values, or through use of extending the template by listing multiple values, or through use of
tables. tables.
skipping to change at page 14, line 29 skipping to change at page 13, line 24
Subject: Request for LDAP OID Registration Subject: Request for LDAP OID Registration
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (I-D) Specification: (I-D)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.2. LDAP Protocol Mechanism Registration Template A.2. LDAP Protocol Mechanism Registration Template
Subject: Request for LDAP Protocol Mechanism Registration Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: Object Identifier:
Description: Description:
Person & email address to contact for further information: Person & email address to contact for further information:
Usage: (One of Control or Extension or Feature or other) Usage: (One of Control or Extension or Feature or other)
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.3. LDAP Syntax Registration Template A.3. LDAP Syntax Registration Template
Subject: Request for LDAP Syntax Registration Subject: Request for LDAP Syntax Registration
Object Identifier: Object Identifier:
Description: Description:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.4. LDAP Descriptor Registration Template A.4. LDAP Descriptor Registration Template
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Descriptor (short name): Descriptor (short name):
Object Identifier: Object Identifier:
Person & email address to contact for further information: Person & email address to contact for further information:
Usage: (One of administrative role, attribute type, matching rule, Usage: (One of administrative role, attribute type, matching rule,
name form, object class, URL extension, or other) name form, object class, URL extension, or other)
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.5. LDAP Attribute Description Option Registration Template A.5. LDAP Attribute Description Option Registration Template
Subject: Request for LDAP Attribute Description Option Registration Subject: Request for LDAP Attribute Description Option Registration
Option Name: Option Name:
Family of Options: (YES or NO) Family of Options: (YES or NO)
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.6. LDAP Message Type Registration Template A.6. LDAP Message Type Registration Template
Subject: Request for LDAP Message Type Registration Subject: Request for LDAP Message Type Registration
LDAP Message Name: LDAP Message Name:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (Approved I-D) Specification: (Approved I-D)
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.7. LDAP Authentication Method Registration Template A.7. LDAP Authentication Method Registration Template
Subject: Request for LDAP Authentication Method Registration Subject: Request for LDAP Authentication Method Registration
Authentication Method Name: Authentication Method Name:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.8. LDAP Result Code Registration Template A.8. LDAP Result Code Registration Template
Subject: Request for LDAP Result Code Registration Subject: Request for LDAP Result Code Registration
Result Code Name: Result Code Name:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.8. LDAP Search Scope Registration Template A.8. LDAP Search Scope Registration Template
Subject: Request for LDAP Search Scope Registration Subject: Request for LDAP Search Scope Registration
Search Scope Name: Search Scope Name:
Filter Scope String: Filter Scope String:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.9. LDAP Filter Choice Registration Template A.9. LDAP Filter Choice Registration Template
Subject: Request for LDAP Filter Choice Registration Subject: Request for LDAP Filter Choice Registration
Filter Choice Name: Filter Choice Name:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
A.10. LDAP ModifyRequest Operation Registration Template A.10. LDAP ModifyRequest Operation Registration Template
Subject: Request for LDAP ModifyRequest Operation Registration Subject: Request for LDAP ModifyRequest Operation Registration
ModifyRequest Operation Name: ModifyRequest Operation Name:
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (RFC, I-D, URI) Specification: (RFC, I-D, URI)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request.)
Appendix B. Changes since RFC 3383 Appendix B. Changes since RFC 3383
This informative appendix provides a summary of changes made since RFC This informative appendix provides a summary of changes made since
3383. RFC 3383.
- Object Identifier Descriptors practices were updated to require - Object Identifier Descriptors practices were updated to require
all descriptors defined in RFCs to be registered and all descriptors defined in RFCs to be registered and
recommending all other descriptors (excepting those in recommending all other descriptors (excepting those in
private-use name space) be registered. Additionally, all private-use name space) be registered. Additionally, all
requests for multiple registrations of the same descriptor are requests for multiple registrations of the same descriptor are
now subject to Expert Review. now subject to Expert Review.
- Protocol Mechanisms practices were updated to include values of - Protocol Mechanisms practices were updated to include values of
the 'supportedFeatures' attribute type. the 'supportedFeatures' attribute type.
- LDAP Syntax, Search Scope, Filter Choice, ModifyRequest - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
operation, and authzId prefixes registries were added. operation, and authzId prefixes registries were added.
[[Initial values provided in Appendix C. This Appendix is to be
removed by the RFC Editor before publication as an RFC.]]
- References to RFCs comprising the LDAP technical specifications - References to RFCs comprising the LDAP technical specifications
have been updated to latest revisions. have been updated to latest revisions.
- References to ISO 10646 have been replaced with [Unicode]. - References to ISO 10646 have been replaced with [Unicode].
- The "Assigned Values" appendix providing initial registry values - The "Assigned Values" appendix providing initial registry
was removed. values was removed.
- Numerous editorial changes were made. - Numerous editorial changes were made.
Appendix C. Initial Values for new registries Author's Address
This appendix provides initial values for new registries.
C.1. LDAP Syntaxes
Object Identifier Syntax Owner Reference
----------------------------- -------------------------- ----- ---------
1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]
C.2. LDAP Search Scopes
Name URLString Value Owner Reference
---------------- --------- ----- ----- -------------------
baseObject base 0 IESG [Protocol][LDAPURL]
singleLevel one 1 IESG [Protocol][LDAPURL]
wholeSubtree sub 2 IESG [Protocol][LDAPURL]
C.3. LDAP Filter Choices
Name Value Owner Reference
---------------- ----- ----- ---------
and 0 IESG [Protocol]
or 1 IESG [Protocol]
not 2 IESG [Protocol]
equalityMatch 3 IESG [Protocol]
substrings 4 IESG [Protocol]
greaterOrEqual 5 IESG [Protocol]
lessOrEqual 6 IESG [Protocol]
present 7 IESG [Protocol]
approxMatch 8 IESG [Protocol]
extensibleMatch 9 IESG [Protocol]
C.4. LDAP ModifyRequest Operations
Name Value Owner Reference
---------------- ----- ----- ---------
add 0 IESG [Protocol]
delete 1 IESG [Protocol]
replace 2 IESG [Protocol]
C.5. LDAP authzId prefixes Kurt D. Zeilenga
OpenLDAP Foundation
Name Prefix Owner Reference EMail: Kurt@OpenLDAP.org
---------------- ------ ----- ---------
dnAuthzId dn: IESG [AuthMeth]
uAuthzId u: IESG [AuthMeth]
Full Copyright Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found on the procedures with respect to rights in RFC documents can be
in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification such proprietary rights by implementers or users of this
can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 103 change blocks. 
294 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/