< draft-ietf-ldapbis-bcp64-06.txt		draft-ietf-ldapbis-bcp64-07.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 23 January 2006		Expires in six months 31 January 2006
	Obsoletes: RFC 3383		Obsoletes: RFC 3383
	IANA Considerations for LDAP		IANA Considerations for LDAP
	<draft-ietf-ldapbis-bcp64-06.txt>		<draft-ietf-ldapbis-bcp64-07.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
	skipping to change at page 3, line 5 ¶		skipping to change at page 2, line 49 ¶
	2. Terminology and Conventions		2. Terminology and Conventions
	This section details terms and conventions used in this document.		This section details terms and conventions used in this document.
	2.1. Policy Terminology		2.1. Policy Terminology
	The terms "IESG Approval", "Standards Action", "IETF Consensus",		The terms "IESG Approval", "Standards Action", "IETF Consensus",
	"Specification Required", "First Come First Served", "Expert Review",		"Specification Required", "First Come First Served", "Expert Review",
	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
			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
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 29 ¶
	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
	A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded		Keywords are case-insensitive.
	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.		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
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 26 ¶
	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.
	The first step is for the requester to fill out the appropriate form.		The first step is for the requester to fill out the appropriate form.
	Templates are provided in Appendix A.		Templates are provided in Appendix A.
	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 viewed as the owner of		(possibly revised) to IANA. The IESG SHALL be regarded as the
	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-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 IANA 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 registration owner of values
	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 owner of values registered under First		requester is viewed as the registration owner of values registered
	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 trademarks 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
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 22 ¶
	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 their 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 owner is not unable or unwilling to make necessary updates,		where the registration owner is not unable or unwilling to make
	the IESG MAY assume ownership in order to update the registration.		necessary updates, the IESG MAY assume ownership of the registration
			in order to update the registration.
	5.3. Comments		5.3. Comments
	For cases where others (anyone other than the owner) have significant		For cases where others (anyone other than the registration owner)
	objections to the claims in a registration and the owner does not		have significant objections to the claims in a registration and the
	agree to change the registration, comments MAY be attached to a		registration owner does not agree to change the registration,
	registration upon Expert Review. For registrations owned by the		comments MAY be attached to a registration upon Expert Review. For
	IESG, the objections SHOULD be addressed by initiating a request for		registrations owned by the IESG, the objections SHOULD be addressed
	Expert Review.		by initiating a request for Expert Review.
	The form to these requests is ad hoc, but MUST include the specific		The form to 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 3
	skipping to change at page 19, line 11 ¶		skipping to change at page 19, line 14 ¶
	was removed.		was removed.
	- Numerous editorial changes were made.		- Numerous editorial changes were made.
	Appendix C. Initial Values for new registries		Appendix C. Initial Values for new registries
	This appendix provides initial values for new registries.		This appendix provides initial values for new registries.
	C.1. LDAP Syntaxes		C.1. LDAP Syntaxes
	Object Identifier Syntax Owner Reference		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.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.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.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.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.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.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.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.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.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.21 Enhanced Guide IESG [Syntaxes]
End of changes. 11 change blocks.
	20 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/