< draft-hollenbeck-rfc4933bis-00.txt		draft-hollenbeck-rfc4933bis-01.txt >
	Network Working Group S. Hollenbeck		Network Working Group S. Hollenbeck
	Internet-Draft VeriSign, Inc.		Internet-Draft VeriSign, Inc.
	Obsoletes: 4933 (if approved) April 6, 2009		Obsoletes: 4933 (if approved) May 14, 2009
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 8, 2009		Expires: November 15, 2009
	Extensible Provisioning Protocol (EPP) Contact Mapping		Extensible Provisioning Protocol (EPP) Contact Mapping
	draft-hollenbeck-rfc4933bis-00		draft-hollenbeck-rfc4933bis-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 8, 2009.		This Internet-Draft will expire on November 15, 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 6, line 22 ¶		skipping to change at page 6, line 22 ¶
	2.4.2. Postal Code		2.4.2. Postal Code
	Contact postal codes are represented using character strings. These		Contact postal codes are represented using character strings. These
	strings have a specified minimum length and a specified maximum		strings have a specified minimum length and a specified maximum
	length.		length.
	2.4.3. Country		2.4.3. Country
	Contact country identifiers are represented using two-character		Contact country identifiers are represented using two-character
	identifiers specified in [ISO.3166.1997].		identifiers specified in [ISO3166-1].
	2.5. Telephone Numbers		2.5. Telephone Numbers
	Contact telephone number structure is derived from structures defined		Contact telephone number structure is derived from structures defined
	in [ITU.E164.2005]. Telephone numbers described in this mapping are		in [ITU.E164.2005]. Telephone numbers described in this mapping are
	character strings that MUST begin with a plus sign ("+", ASCII value		character strings that MUST begin with a plus sign ("+", ASCII value
	0x002B), followed by a country code defined in [ITU.E164.2005],		0x002B), followed by a country code defined in [ITU.E164.2005],
	followed by a dot (".", ASCII value 0x002E), followed by a sequence		followed by a dot (".", ASCII value 0x002E), followed by a sequence
	of digits representing the telephone number. An optional "x"		of digits representing the telephone number. An optional "x"
	attribute is provided to note telephone extension information.		attribute is provided to note telephone extension information.
	skipping to change at page 17, line 17 ¶		skipping to change at page 17, line 17 ¶
	time. Server operators MAY receive and process transform commands,		time. Server operators MAY receive and process transform commands,
	but defer completing the requested action if human or third-party		but defer completing the requested action if human or third-party
	review is required before the requested action can be completed. In		review is required before the requested action can be completed. In
	such situations, the server MUST return a 1001 response code to the		such situations, the server MUST return a 1001 response code to the
	client to note that the command has been received and processed, but		client to note that the command has been received and processed, but
	the requested action is pending. The server MUST also manage the		the requested action is pending. The server MUST also manage the
	status of the object that is the subject of the command to reflect		status of the object that is the subject of the command to reflect
	the initiation and completion of the requested action. Once the		the initiation and completion of the requested action. Once the
	action has been completed, all clients involved in the transaction		action has been completed, all clients involved in the transaction
	MUST be notified using a service message that the action has been		MUST be notified using a service message that the action has been
	completed and that the status of the object has changed.		completed and that the status of the object has changed. Other
			notification methods MAY be used in addition to the required service
			message.
			Server operators SHOULD confirm that a client is authorized to
			perform a transform command on a given object. Any attempt to
			transform an object by an unauthorized client MUST be rejected, and
			the server MUST return a 2201 response code to the client to note
			that the client lacks privileges to execute the requested command.
	3.2.1. EPP <create> Command		3.2.1. EPP <create> Command
	The EPP <create> command provides a transform operation that allows a		The EPP <create> command provides a transform operation that allows a
	client to create a contact object. In addition to the standard EPP		client to create a contact object. In addition to the standard EPP
	command elements, the <create> command MUST contain a <contact:		command elements, the <create> command MUST contain a <contact:
	create> element that identifies the contact namespace. The <contact:		create> element that identifies the contact namespace. The <contact:
	create> element contains the following child elements:		create> element contains the following child elements:
	- A <contact:id> element that contains the desired server-unique		- A <contact:id> element that contains the desired server-unique
	skipping to change at page 20, line 47 ¶		skipping to change at page 20, line 47 ¶
	command elements, the <delete> command MUST contain a <contact:		command elements, the <delete> command MUST contain a <contact:
	delete> element that identifies the contact namespace. The <contact:		delete> element that identifies the contact namespace. The <contact:
	delete> element MUST contain the following child element:		delete> element MUST contain the following child element:
	- A <contact:id> element that contains the server-unique identifier		- A <contact:id> element that contains the server-unique identifier
	of the contact object to be deleted.		of the contact object to be deleted.
	A contact object SHOULD NOT be deleted if it is associated with other		A contact object SHOULD NOT be deleted if it is associated with other
	known objects. An associated contact SHOULD NOT be deleted until		known objects. An associated contact SHOULD NOT be deleted until
	associations with other known objects have been broken. A server		associations with other known objects have been broken. A server
	SHOULD notify clients of object relationships when a <delete> command		SHOULD notify clients that object relationships exist by sending a
	is attempted and fails due to existing object relationships.		2305 error response code when a <delete> command is attempted and
			fails due to existing object relationships.
	Example <delete> command:		Example <delete> command:
	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>		C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">		C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>		C: <command>
	C: <delete>		C: <delete>
	C: <contact:delete		C: <contact:delete
	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">		C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	C: <contact:id>sh8013</contact:id>		C: <contact:id>sh8013</contact:id>
	skipping to change at page 38, line 9 ¶		skipping to change at page 38, line 9 ¶
	<!--		<!--
	End of schema.		End of schema.
	-->		-->
	</schema>		</schema>
	END		END
	5. Internationalization Considerations		5. Internationalization Considerations
	EPP is represented in XML, which provides native support for encoding		EPP is represented in XML, which provides native support for encoding
	information using the Unicode character set and its more compact		information using the Unicode character set and its more compact
	representations, including UTF-8. Conformant XML processors		representations including UTF-8. Conformant XML processors recognize
	recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes		both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to
	provisions to identify and use other character encodings through use		identify and use other character encodings through use of an
	of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is		"encoding" attribute in an <?xml?> declaration, use of UTF-8 is
	REQUIRED with this specification.		RECOMMENDED in environments where parser encoding support
			incompatibility exists.
	All date-time values presented via EPP MUST be expressed in Universal		All date-time values presented via EPP MUST be expressed in Universal
	Coordinated Time using the Gregorian calendar. The XML Schema allows		Coordinated Time using the Gregorian calendar. The XML Schema allows
	use of time zone identifiers to indicate offsets from the zero		use of time zone identifiers to indicate offsets from the zero
	meridian, but this option MUST NOT be used with EPP. The extended		meridian, but this option MUST NOT be used with EPP. The extended
	date-time form using upper case "T" and "Z" characters defined in		date-time form using upper case "T" and "Z" characters defined in
	[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time		[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
	values as the XML Schema does not support truncated date-time forms		values as the XML Schema does not support truncated date-time forms
	or lower case "T" and "Z" characters.		or lower case "T" and "Z" characters.
	skipping to change at page 40, line 11 ¶		skipping to change at page 40, line 11 ¶
	Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer		Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer
	El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael		El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael
	Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson.		Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.hollenbeck-rfc4930bis]		[I-D.hollenbeck-rfc4930bis]
	Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",		Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
	draft-hollenbeck-rfc4930bis-00 (work in progress),		draft-hollenbeck-rfc4930bis-01 (work in progress),
	April 2009.		May 2009.
	[ISO.3166.1997]		[ISO3166-1]
	International Organization for Standardization, "Codes for		International Organization for Standardization, "Codes for
	the representation of names of countries and their		the representation of names of countries and their
	subdivisions -- Part 1: Country codes", ISO Standard 3166,		subdivisions -- Part 1: Country codes", ISO Standard 3166,
	October 1997.		November 2006.
	[ITU.E164.2005]		[ITU.E164.2005]
	International Telecommunication Union, "The international		International Telecommunication Union, "The international
	public telecommunication numbering plan", ITU-		public telecommunication numbering plan", ITU-
	T Recommendation E.164, February 2005.		T Recommendation E.164, February 2005.
	[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, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	[W3C.REC-xml-20040204]		[W3C.REC-xml-20040204]
	Maler, E., Sperberg-McQueen, C., Paoli, J., Yergeau, F.,		Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J.,
	and T. Bray, "Extensible Markup Language (XML) 1.0 (Third		and T. Bray, "Extensible Markup Language (XML) 1.0 (Third
	Edition)", World Wide Web Consortium FirstEdition REC-xml-		Edition)", World Wide Web Consortium FirstEdition REC-xml-
	20040204, February 2004,		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., Maloney, M., Mendelsohn, N., and D. Beech,		Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney,
	"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>.
	skipping to change at page 41, line 23 ¶		skipping to change at page 41, line 23 ¶
	[RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)		[RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
	Contact Mapping", RFC 4933, May 2007.		Contact Mapping", RFC 4933, May 2007.
	Appendix A. Changes from RFC 4933		Appendix A. Changes from RFC 4933
	1. Changed "This document obsoletes RFC 3733" to "This document is		1. Changed "This document obsoletes RFC 3733" to "This document is
	intended to obsolete RFC 4933".		intended to obsolete RFC 4933".
	2. Replaced references to RFC 0822 with references to 5322.		2. Replaced references to RFC 0822 with references to 5322.
	3. Replaced references to RFC 3733 with references to 4933.		3. Replaced references to RFC 3733 with references to 4933.
	4. Replaced references to RFC 4930 with references to 4930bis.		4. Replaced references to RFC 4930 with references to 4930bis.
			5. Updated reference to ISO 3166-1.
			6. Modified text in Section 3.2.2 to include 2305 response code.
			7. Updated Section 5.
			8. Added "Other notification methods MAY be used in addition to the
			required service message" in Section 3.2.
			9. Added 2201 response code text in Section 3.2.
	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. 14 change blocks.
	19 lines changed or deleted		35 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/