< draft-hollenbeck-rfc4930bis-00.txt		draft-hollenbeck-rfc4930bis-01.txt >
	Network Working Group S. Hollenbeck		Network Working Group S. Hollenbeck
	Internet-Draft VeriSign, Inc.		Internet-Draft VeriSign, Inc.
	Obsoletes: 4930 (if approved) April 3, 2009		Obsoletes: 4930 (if approved) May 5, 2009
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 5, 2009		Expires: November 6, 2009
	Extensible Provisioning Protocol (EPP)		Extensible Provisioning Protocol (EPP)
	draft-hollenbeck-rfc4930bis-00		draft-hollenbeck-rfc4930bis-01
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	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.
	This Internet-Draft will expire on October 5, 2009.		This Internet-Draft will expire on November 6, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 49 ¶
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	In examples, "C:" represents lines sent by a protocol client and "S:"		In examples, "C:" represents lines sent by a protocol client and "S:"
	represents lines returned by a protocol server. Indentation and		represents lines returned by a protocol server. Indentation and
	white space in examples are provided only to illustrate element		white space in examples are provided only to illustrate element
	relationships and are not a REQUIRED feature of this protocol.		relationships and are not a REQUIRED feature of this protocol. A
			protocol client that is authorized to manage an existing object is
			described as a "sponsoring" client throughout this document.
	2. Protocol Description		2. Protocol Description
	EPP is a stateful XML protocol that can be layered over multiple		EPP is a stateful XML protocol that can be layered over multiple
	transport protocols. Protected using lower-layer security protocols,		transport protocols. Protected using lower-layer security protocols,
	clients exchange identification, authentication, and option		clients exchange identification, authentication, and option
	information, and then engage in a series of client-initiated command-		information, and then engage in a series of client-initiated command-
	response exchanges. All EPP commands are atomic (there is no partial		response exchanges. All EPP commands are atomic (there is no partial
	success or partial failure) and designed so that they can be made		success or partial failure) and designed so that they can be made
	idempotent (executing a command more than once has the same net		idempotent (executing a command more than once has the same net
	skipping to change at page 23, line 23 ¶		skipping to change at page 23, line 23 ¶
	The values of the <version> and <lang> elements MUST exactly match		The values of the <version> and <lang> elements MUST exactly match
	one of the values presented in the EPP greeting.		one of the values presented in the EPP greeting.
	- A <svcs> element that contains one or more <objURI> elements that		- A <svcs> element that contains one or more <objURI> elements that
	contain namespace URIs representing the objects to be managed		contain namespace URIs representing the objects to be managed
	during the session. The <svcs> element MAY contain an OPTIONAL		during the session. The <svcs> element MAY contain an OPTIONAL
	<svcExtension> element that contains one or more <extURI> elements		<svcExtension> element that contains one or more <extURI> elements
	that identify object extensions to be used during the session.		that identify object extensions to be used during the session.
	The PLAIN Simple Authentication and Security Layer (SASL) mechanism		The PLAIN Simple Authentication and Security Layer (SASL) mechanism
	presented in [RFC2595] describes a format for providing a user		presented in [RFC4616] describes a format for providing a user
	identifier, an authorization identifier, and a password as part of a		identifier, an authorization identifier, and a password as part of a
	single plain text string. The EPP authentication mechanism is		single plain text string. The EPP authentication mechanism is
	similar, though EPP does not require a session-level authorization		similar, though EPP does not require a session-level authorization
	identifier and the user identifier and password are separated into		identifier and the user identifier and password are separated into
	distinct XML elements. Additional identification and authorization		distinct XML elements. Additional identification and authorization
	schemes MUST be provided at other protocol layers to provide more		schemes MUST be provided at other protocol layers to provide more
	robust security services.		robust security services.
	Example <login> command:		Example <login> command:
	skipping to change at page 25, line 6 ¶		skipping to change at page 25, line 6 ¶
	S: <msg>Command completed successfully</msg>		S: <msg>Command completed successfully</msg>
	S: </result>		S: </result>
	S: <trID>		S: <trID>
	S: <clTRID>ABC-12345</clTRID>		S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54321-XYZ</svTRID>		S: <svTRID>54321-XYZ</svTRID>
	S: </trID>		S: </trID>
	S: </response>		S: </response>
	S:</epp>		S:</epp>
	The EPP <login> command is used to establish a session with an EPP		The EPP <login> command is used to establish a session with an EPP
	server. A <login> command MUST be rejected if received within the		server. A <login> command MUST be rejected if received within the
	bounds of an existing session. This action MUST be open to all		bounds of an existing session. This command MUST be available to all
	authorized clients.		clients.
	2.9.1.2. EPP <logout> Command		2.9.1.2. EPP <logout> Command
	The EPP <logout> command is used to end a session with an EPP server.		The EPP <logout> command is used to end a session with an EPP server.
	The <logout> command MUST be represented as an empty element with no		The <logout> command MUST be represented as an empty element with no
	child elements.		child elements.
	A server MAY end a session due to client inactivity or excessive		A server MAY end a session due to client inactivity or excessive
	client session longevity. The parameters for determining excessive		client session longevity. The parameters for determining excessive
	client inactivity or session longevity are a matter of server policy		client inactivity or session longevity are a matter of server policy
	skipping to change at page 26, line 6 ¶		skipping to change at page 26, line 6 ¶
	S: <msg>Command completed successfully; ending session</msg>		S: <msg>Command completed successfully; ending session</msg>
	S: </result>		S: </result>
	S: <trID>		S: <trID>
	S: <clTRID>ABC-12345</clTRID>		S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54321-XYZ</svTRID>		S: <svTRID>54321-XYZ</svTRID>
	S: </trID>		S: </trID>
	S: </response>		S: </response>
	S:</epp>		S:</epp>
	The EPP <logout> command is used to end a session with an EPP server.		The EPP <logout> command is used to end a session with an EPP server.
	A <logout> command MUST be rejected if the command has not been		A <logout> command MUST be rejected if the command has not been
	preceded by a successful <login> command. This action MUST be open		preceded by a successful <login> command. This command MUST be
	to all authorized clients.		available to all clients.
	2.9.2. Query Commands		2.9.2. Query Commands
	2.9.2.1. EPP <check> Command		2.9.2.1. EPP <check> Command
	The EPP <check> command is used to determine if an object can be		The EPP <check> command is used to determine if an object can be
	provisioned within a repository. It provides a hint that allows a		provisioned within a repository. It provides a hint that allows a
	client to anticipate the success or failure of provisioning an object		client to anticipate the success or failure of provisioning an object
	using the <create> command as object provisioning requirements are		using the <create> command as object provisioning requirements are
	ultimately a matter of server policy.		ultimately a matter of server policy.
	skipping to change at page 44, line 29 ¶		skipping to change at page 44, line 29 ¶
	categories:		categories:
	x0zz Protocol Syntax		x0zz Protocol Syntax
	x1zz Implementation-specific Rules		x1zz Implementation-specific Rules
	x2zz Security		x2zz Security
	x3zz Data Management		x3zz Data Management
	x4zz Server System		x4zz Server System
	x5zz Connection Management		x5zz Connection Management
	The third and fourth digits provide response detail within the		The third and fourth digits provide response detail within the
	categories defined by the first and second digits. Specific result		categories defined by the first and second digits. The complete list
	codes are listed in the table below.		of valid result codes is enumerated below and in the normative
			schema.
	Every EPP response MUST include a result code and a human-readable		Every EPP response MUST include a result code and a human-readable
	description of the result code. The language used to represent the		description of the result code. The language used to represent the
	description MAY be identified using an instance of the "lang"		description MAY be identified using an instance of the "lang"
	attribute within the <msg> element. If not specified, the default		attribute within the <msg> element. If not specified, the default
	language is English, identified as "en". A description of the		language is English, identified as "en". A description of the
	structure of valid values for the "lang" attribute is described in		structure of valid values for the "lang" attribute is described in
	[RFC4646].		[RFC4646].
	Response text MAY be translated into other languages, though the		Response text MAY be translated into other languages, though the
	skipping to change at page 62, line 41 ¶		skipping to change at page 62, line 41 ¶
	Registration request for the EPP shared structure XML schema:		Registration request for the EPP shared structure XML schema:
	URI: urn:ietf:params:xml:schema:eppcom-1.0		URI: urn:ietf:params:xml:schema:eppcom-1.0
	Registrant Contact: See the "Author's Address" section of this		Registrant Contact: See the "Author's Address" section of this
	document.		document.
	XML: See the "Shared Structure Schema" section of this document.		XML: See the "Shared Structure Schema" section of this document.
			A MIME media type registration template is included in Appendix B.
	7. Security Considerations		7. Security Considerations
	EPP provides only simple client authentication services. A passive		EPP provides only simple client authentication services. A passive
	attack is sufficient to recover client identifiers and passwords,		attack is sufficient to recover client identifiers and passwords,
	allowing trivial command forgery. Protection against most common		allowing trivial command forgery. Protection against most common
	attacks and more robust security services MUST be provided by other		attacks and more robust security services MUST be provided by other
	protocol layers. Specifically, EPP instances MUST be protected using		protocol layers. Specifically, EPP instances MUST be protected using
	a transport mechanism or application protocol that provides		a transport mechanism or application protocol that provides
	integrity, confidentiality, and mutual strong client-server		integrity, confidentiality, and mutual strong client-server
	authentication.		authentication.
	EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595]		EPP uses a variant of the PLAIN SASL mechanism described in [RFC4616]
	to provide a simple application-layer authentication service that		to provide a simple application-layer authentication service that
	augments or supplements authentication and identification services		augments or supplements authentication and identification services
	that might be available at other protocol layers. Where the PLAIN		that might be available at other protocol layers. Where the PLAIN
	SASL mechanism specifies provision of an authorization identifier,		SASL mechanism specifies provision of an authorization identifier,
	authentication identifier, and password as a single string separated		authentication identifier, and password as a single string separated
	by ASCII NUL characters, EPP specifies use of a combined		by ASCII NUL characters, EPP specifies use of a combined
	authorization and authentication identifier and a password provided		authorization and authentication identifier and a password provided
	as distinct XML elements.		as distinct XML elements.
	Repeated password guessing attempts can be discouraged by limiting		Repeated password guessing attempts can be discouraged by limiting
	skipping to change at page 65, line 28 ¶		skipping to change at page 65, line 28 ¶
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying		[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
	Languages", BCP 47, RFC 4646, September 2006.		Languages", BCP 47, RFC 4646, September 2006.
	[W3C.REC-xml-20040204]		[W3C.REC-xml-20040204]
	Bray, T., Maler, E., Paoli, J., Yergeau, F., and C.		Bray, T., Maler, E., Yergeau, F., Paoli, J., and C.
	Sperberg-McQueen, "Extensible Markup Language (XML) 1.0		Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
	(Third Edition)", World Wide Web Consortium		(Third Edition)", World Wide Web Consortium
	FirstEdition REC-xml-20040204, February 2004,		FirstEdition REC-xml-20040204, February 2004,
	<http://www.w3.org/TR/2004/REC-xml-20040204>.		<http://www.w3.org/TR/2004/REC-xml-20040204>.
	[W3C.REC-xmlschema-1-20041028]		[W3C.REC-xmlschema-1-20041028]
	Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney,		Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
	"XML Schema Part 1: Structures Second Edition", World Wide		"XML Schema Part 1: Structures Second Edition", World Wide
	Web Consortium Recommendation REC-xmlschema-1-20041028,		Web Consortium Recommendation REC-xmlschema-1-20041028,
	October 2004,		October 2004,
	<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.		<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
	[W3C.REC-xmlschema-2-20041028]		[W3C.REC-xmlschema-2-20041028]
	Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes		Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
	Second Edition", World Wide Web Consortium		Second Edition", World Wide Web Consortium
	Recommendation REC-xmlschema-2-20041028, October 2004,		Recommendation REC-xmlschema-2-20041028, October 2004,
	<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.		<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
	9.2. Informative References		9.2. Informative References
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, September 1981.		RFC 793, September 1981.
	[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, June 1999.
	[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO		[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
	10646", RFC 2781, February 2000.		10646", RFC 2781, February 2000.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",		[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
	RFC 3080, March 2001.		RFC 3080, March 2001.
	[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol		[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol
	Requirements", RFC 3375, September 2002.		Requirements", RFC 3375, September 2002.
			[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
			Security Layer (SASL) Mechanism", RFC 4616, August 2006.
	[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",		[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
	RFC 4930, May 2007.		RFC 4930, May 2007.
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
	RFC 4960, September 2007.		RFC 4960, September 2007.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	October 2008.		October 2008.
	[W3C.REC-P3P-20020416]		[W3C.REC-P3P-20020416]
	skipping to change at page 69, line 30 ¶		skipping to change at page 69, line 30 ¶
	Person & email address for further information: See the "Author's		Person & email address for further information: See the "Author's
	Address" section of this document.		Address" section of this document.
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: IETF		Author/Change controller: IETF
	Appendix C. Changes from RFC 4930		Appendix C. Changes from RFC 4930
	1. Changed "This document obsoletes RFC 3730" to "This document is		1. Changed "This document obsoletes RFC 3730" to "This document is
	intended to obsolete RFC 4930".		intended to obsolete RFC 4930".
	2. Replaced references to RFC 2821 with references to RFC 5321.		2. Replaced references to RFC 2595 with references to RFC 4616.
	3. Replaced references to RFC 2960 with references to RFC 4960.		3. Replaced references to RFC 2821 with references to RFC 5321.
	4. Replaced references to RFC 3066 with references to RFC 4646.		4. Replaced references to RFC 2960 with references to RFC 4960.
	5. Replaced references to RFC 3730 with references to RFC 4930.		5. Replaced references to RFC 3066 with references to RFC 4646.
			6. Replaced references to RFC 3730 with references to RFC 4930.
			7. Added "A protocol client that is authorized to manage an
			existing object is described as a "sponsoring" client throughout
			this document" in Section 1.1.
			8. Changed "This action MUST be open to all authorized clients" to
			"This command MUST be available to all clients" in the
			descriptions of the <login> and <logout> commands.
			9. Changed "Specific result codes are listed in the table below" to
			"The complete list of valid result codes is enumerated below and
			in the normative schema" in Section 3.
			10. Added reference to Appendix B in the IANA Considerations
			section.
	Author's Address		Author's Address
	Scott Hollenbeck		Scott Hollenbeck
	VeriSign, Inc.		VeriSign, Inc.
	21345 Ridgetop Circle		21345 Ridgetop Circle
	Dulles, VA 20166-6503		Dulles, VA 20166-6503
	US		US
	EMail: shollenbeck@verisign.com		EMail: shollenbeck@verisign.com
End of changes. 16 change blocks.
	24 lines changed or deleted		41 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/