draft-ietf-regext-org-11.txt		draft-ietf-regext-org-12.txt
	Internet Engineering Task Force L. Zhou		Internet Engineering Task Force L. Zhou
	Internet-Draft CNNIC		Internet-Draft CNNIC
	Intended status: Standards Track N. Kong		Intended status: Standards Track N. Kong
	Expires: April 13, 2019 Consultant		Expires: June 3, 2019 Consultant
	G. Zhou		G. Zhou
	J. Yao		J. Yao
	CNNIC		CNNIC
	J. Gould		J. Gould
	Verisign, Inc.		Verisign, Inc.
	October 10, 2018		November 30, 2018
	Extensible Provisioning Protocol (EPP) Organization Mapping		Extensible Provisioning Protocol (EPP) Organization Mapping
	draft-ietf-regext-org-11		draft-ietf-regext-org-12
	Abstract		Abstract
	This document describes an Extensible Provisioning Protocol (EPP)		This document describes an Extensible Provisioning Protocol (EPP)
	mapping for provisioning and management of organization objects		mapping for provisioning and management of organization objects
	stored in a shared central repository. Specified in Extensible		stored in a shared central repository. Specified in Extensible
	Markup Language (XML), this extended mapping is applied to provide		Markup Language (XML), this extended mapping is applied to provide
	additional features required for the provisioning of organizations.		additional features required for the provisioning of organizations.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 13, 2019.		This Internet-Draft will expire on June 3, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	3.2. Organization Roles . . . . . . . . . . . . . . . . . . . 4		3.2. Organization Roles . . . . . . . . . . . . . . . . . . . 4
	3.2.1. Role Type . . . . . . . . . . . . . . . . . . . . . . 4		3.2.1. Role Type . . . . . . . . . . . . . . . . . . . . . . 4
	3.2.2. Role Status . . . . . . . . . . . . . . . . . . . . . 4		3.2.2. Role Status . . . . . . . . . . . . . . . . . . . . . 4
	3.2.3. Role Identifier . . . . . . . . . . . . . . . . . . . 4		3.2.3. Role Identifier . . . . . . . . . . . . . . . . . . . 4
	3.3. Contact and Client Identifiers . . . . . . . . . . . . . 5		3.3. Contact and Client Identifiers . . . . . . . . . . . . . 5
	3.4. Organization Status Values . . . . . . . . . . . . . . . 5		3.4. Organization Status Values . . . . . . . . . . . . . . . 5
	3.5. Role Status Values . . . . . . . . . . . . . . . . . . . 6		3.5. Role Status Values . . . . . . . . . . . . . . . . . . . 6
	3.6. Parent Identifier . . . . . . . . . . . . . . . . . . . . 7		3.6. Parent Identifier . . . . . . . . . . . . . . . . . . . . 7
	3.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.8. Dates and Times . . . . . . . . . . . . . . . . . . . . . 7		3.8. Dates and Times . . . . . . . . . . . . . . . . . . . . . 7
	4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7		4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8
	4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7		4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 8
	4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 8		4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 8
	4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 9		4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 10
	4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 15		4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 16
	4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15		4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 16
	4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 15		4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 16
	4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 19		4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 20
	4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 20		4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 21
	4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 20		4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 21
	4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 21		4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 22
	4.3. Offline Review of Requested Actions . . . . . . . . . . . 25		4.3. Offline Review of Requested Actions . . . . . . . . . . . 26
	5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27		5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
	6. Internationalization Considerations . . . . . . . . . . . . . 36		6. Internationalization Considerations . . . . . . . . . . . . . 37
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 36		7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 37
	7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 37		7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 38
	7.3. Role Type Values Registry . . . . . . . . . . . . . . . . 37		7.3. Role Type Values Registry . . . . . . . . . . . . . . . . 38
	7.3.1. Registration Template . . . . . . . . . . . . . . . . 37		7.3.1. Registration Template . . . . . . . . . . . . . . . . 38
	7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 37		7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 38
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 38		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 39
	8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 39		8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 40
	8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 39		8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 40
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 39		9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 40		10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 41
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	11.1. Normative References . . . . . . . . . . . . . . . . . . 40		11.1. Normative References . . . . . . . . . . . . . . . . . . 41
	11.2. Informative References . . . . . . . . . . . . . . . . . 41		11.2. Informative References . . . . . . . . . . . . . . . . . 42
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	There are many entities, such as registrars, resellers, DNS service		There are many entities, such as registrars, resellers, DNS service
	operators, or privacy proxies involved in the domain registration		operators, or privacy proxies involved in the domain registration
	business. These kind of entities have not been formally defined as		business. These kind of entities have not been formally defined as
	an object in EPP which will be specified as "organization" in this		having an object in Extensible Provisioning Protocol (EPP). This
	document.		document provides a way to specify them as "organization" entities.
	This document describes an organization object mapping for version		This document describes an organization object mapping for version
	1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This		1.0 of the EPP [RFC5730]. This mapping is specified using the XML
	mapping is specified using the XML 1.0 as described in		1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as
	[W3C.REC-xml-20040204] and XML Schema notation as described in		described in [W3C.REC-xmlschema-1-20041028] and
	[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].		[W3C.REC-xmlschema-2-20041028].
	2. Conventions Used in This Document		2. 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 BCP 14		document are to be interpreted as described in BCP 14
	[RFC2119][RFC8174] when, and only when, they appear in all capitals,		[RFC2119][RFC8174] when, and only when, they appear in all capitals,
	as shown here.		as shown here.
	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 specification.		relationships and are not a required feature of this specification.
	XML is case sensitive. Unless stated otherwise, XML specifications		XML is case sensitive. Unless stated otherwise, XML specifications
	and examples provided in this document MUST be interpreted in the		and examples provided in this document MUST be interpreted in the
	character case presented to develop a conforming implementation.		character case presented.
	The XML namespace prefix "org" is used, but implementations MUST NOT		The XML namespace prefix "org" is used for the namespace
			"urn:ietf:params:xml:ns:epp:org-1.0", but implementations MUST NOT
	depend on it and instead employ a proper namespace-aware XML parser		depend on it and instead employ a proper namespace-aware XML parser
	and serializer to interpret and output the XML documents.		and serializer to interpret and output the XML documents.
	3. Object Attributes		3. Object Attributes
	An EPP organization object has attributes and associated values that		An EPP organization object has attributes and associated values that
	can be viewed and modified by the sponsoring client or the server.		can be viewed and modified by the sponsoring client or the server.
	This section describes each attribute type in detail. The formal		This section describes each attribute type in detail. The formal
	syntax for the attribute values described here can be found in the		syntax for the attribute values described here can be found in the
	"Formal Syntax" section of this document and in the appropriate		"Formal Syntax" section of this document and in the appropriate
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	The organization roles are used to represent the relationship an		The organization roles are used to represent the relationship an
	organization could have. Its corresponding element is <org:role>.		organization could have. Its corresponding element is <org:role>.
	An organization object MUST always have at least one associated role.		An organization object MUST always have at least one associated role.
	Roles can be set only by the client that sponsors an organization		Roles can be set only by the client that sponsors an organization
	object. A client can change the role of an organization object using		object. A client can change the role of an organization object using
	the EPP <update> command.		the EPP <update> command.
	3.2.1. Role Type		3.2.1. Role Type
	An organization role MUST have a type which supports a list of		An organization role MUST have a type field. This may have any of
	values. An organization could have multiple roles with a different		the values listed in Section 7.3. An organization could have
	role type. See Section 7.3 for a list of values. Its corresponding		multiple roles with different role types. Its corresponding element
	element is <org:type>.		is <org:type>.
	3.2.2. Role Status		3.2.2. Role Status
	A role of an organization object MAY have its own statuses. Its		A role of an organization object MAY have its own statuses. Its
	corresponding element is <org:status>. The values of the role status		corresponding element is <org:status>. The values of the role status
	are defined in Section 3.5.		are defined in Section 3.5.
	3.2.3. Role Identifier		3.2.3. Role Identifier
	A role MAY have a third-party-assigned identifier such as the IANA ID		A role MAY have a third-party-assigned identifier such as the IANA ID
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	<org:role>		<org:role>
	<org:type>registrar</org:type>		<org:type>registrar</org:type>
	<org:status>ok</org:status>		<org:status>ok</org:status>
	<org:status>linked</org:status>		<org:status>linked</org:status>
	<org:roleID>1362</org:roleID>		<org:roleID>1362</org:roleID>
	</org:role>		</org:role>
	3.3. Contact and Client Identifiers		3.3. Contact and Client Identifiers
	All EPP contacts are identified by a server-unique identifier.		All EPP contacts are identified by server-unique identifiers.
	Contact identifiers are character strings with a specified minimum		Contact identifiers are character strings with a specified minimum
	length, a specified maximum length, and a specified format. Contact		length, a specified maximum length, and a specified format. Contact
	identifiers use the "clIDType" client identifier syntax described in		identifiers use the "clIDType" client identifier syntax described in
	[RFC5730].		[RFC5730].
	3.4. Organization Status Values		3.4. Organization Status Values
	An organization object MUST always have at least one associated		An organization object MUST always have at least one associated
	status value.		status value. Status values can be set only by the client that
			sponsors an organization object and by the server on which the object
			resides. A client can change the status of an organization object
			using the EPP <update> command. Each status value MAY be accompanied
			by a string of human-readable text that describes the rationale for
			the status applied to the object.
			A client MUST NOT alter server status values set by the server. A
			server MAY alter or override status values set by a client, subject
			to local server policies. The status of an object MAY change as a
			result of either a client-initiated transform command or an action
			performed by a server operator.
	Status values that can be added or removed by a client are prefixed		Status values that can be added or removed by a client are prefixed
	with "client". Corresponding status values that can be added or		with "client". Corresponding server status values that can be added
	removed by a server are prefixed with "server". The "hold" and		or removed by a server are prefixed with "server". The "hold" and
	"terminated" status values are server-managed when the organization		"terminated" status values are server-managed when the organization
	has no parent identifier [Section 3.6] and otherwise MAY be client-		has no parent identifier [Section 3.6] and otherwise MAY be client-
	managed based on server policy.		managed based on server policy. Other status values that do not
			begin with either "client" or "server" are server-managed.
	Status Value Descriptions:		Status Value Descriptions:
	o ok: This is the normal status value for an object that has no		o ok: This is the normal status value for an object that has no
	pending operations or prohibitions. This value is set and removed		operations pending or active prohibitions. This value is set and
	by the server as other status values are added or removed.		removed by the server as other status values are added or removed.
	o hold: Organization transform commands and new links MUST be		o hold: Organization transform commands and new links MUST be
	rejected.		rejected.
	o terminated: The organization which has been terminated MUST NOT be		o terminated: The organization which has been terminated MUST NOT be
	linked. Organization transform commands and new links MUST be		linked. Organization transform commands and new links MUST be
	rejected.		rejected.
	o linked: The organization object has at least one active		o linked: The organization object has at least one active
	association with another object. The "linked" status is not		association with another object. The "linked" status is not
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 25 ¶
	o pendingCreate, pendingUpdate, pendingDelete: A transform command		o pendingCreate, pendingUpdate, pendingDelete: A transform command
	has been processed for the object, but the action has not been		has been processed for the object, but the action has not been
	completed by the server. Server operators can delay action		completed by the server. Server operators can delay action
	completion for a variety of reasons, such as to allow for human		completion for a variety of reasons, such as to allow for human
	review or third-party action. A transform command that is		review or third-party action. A transform command that is
	processed, but whose requested action is pending, is noted with		processed, but whose requested action is pending, is noted with
	response code 1001.		response code 1001.
	"pendingCreate", "ok", "hold", and "terminated" are mutually		"pendingCreate", "ok", "hold", and "terminated" are mutually
	exclusive statuses. Organization MUST have only one of these		exclusive statuses. Organization MUST have exactly one of these
	statuses set.		statuses set.
	"ok" status MAY only be combined with "linked" status.		"ok" status MAY only be combined with "linked" status.
	A client or server MAY combine "linked" with either		A client or server MAY combine "linked" with either
	"clientLinkProhibited" or "serverLinkProhibited" if new links must be		"clientLinkProhibited" or "serverLinkProhibited" if new links must be
	prohibited.		prohibited.
	"pendingDelete" status MUST NOT be combined with either		"pendingDelete" status MUST NOT be combined with either
	"clientDeleteProhibited" or "serverDeleteProhibited" status.		"clientDeleteProhibited" or "serverDeleteProhibited" status.
	The pendingCreate, pendingDelete, and pendingUpdate status values		The pendingCreate, pendingDelete, and pendingUpdate status values
	MUST NOT be combined with each other.		MUST NOT be combined with each other.
			If "clientUpdateProhibited" or "serverUpdateProhibited" is set, the
			client will not be able to update the object. For
			"clientUpdateProhibited", the client will first need to remove
			"clientUpdateProhibited" prior to attempting to update the object.
			The server can modify the object at any time.
	3.5. Role Status Values		3.5. Role Status Values
	A role SHOULD have at least one associated status value. Valid		A role SHOULD have at least one associated status value. Valid
	values include "ok", "linked", "clientLinkProhibited", and		values include "ok", "linked", "clientLinkProhibited", and
	"serverLinkProhibited".		"serverLinkProhibited".
	Status Value Descriptions:		Status Value Descriptions:
	o ok: This is the normal status value for an role that has no		o ok: This is the normal status value for an role that has no
	pending operations or prohibitions. This value is set and removed		operations pending or active prohibitions. This value is set and
	by the server as other status values are added or removed.		removed by the server as other status values are added or removed.
	o linked: The role of an organization object has at least one active		o linked: The role of an organization object has at least one active
	association with another object. The "linked" status is not		association with another object. The "linked" status is not
	explicitly set by the client. Servers SHOULD provide services to		explicitly set by the client. Servers SHOULD provide services to
	determine existing object associations.		determine existing object associations.
	o clientLinkProhibited, serverLinkProhibited: Requests to add new		o clientLinkProhibited, serverLinkProhibited: Requests to add new
	links to the role MUST be rejected.		links to the role MUST be rejected.
	3.6. Parent Identifier		3.6. Parent Identifier
	There can be more than one layer of organizations, such as a		There can be more than one layer of organizations, such as a
	reseller. The parent identifier, as defined with the <org:parentId>		reseller. The parent identifier, as defined with the <org:parentId>
	element, represents the parent organization identifier in a child		element, represents the parent organization identifier in a child
	organization.		organization.
	Take a reseller organization, for example, the parent identifier is		The case of reseller organizations provides an example. The parent
	not defined for the top level reseller, namely the registrar of the		identifier is not defined for the top level reseller, namely the
	registry. An N-tier reseller has a parent reseller and at least one		registrar of the registry. An N-tier reseller has a parent reseller
	child reseller. A reseller customer has a parent reseller and no		and at least one child reseller. A reseller customer has a parent
	child resellers.		reseller and no child resellers.
	Loops MUST be prohibited. For example: if organization A has B as		Loops MUST be prohibited. For example: if organization A has B as
	its parent identifier, organization B should not have organization A		its parent identifier, organization B cannot have organization A as
	as its parent identifier. The same is true for larger loops		its parent identifier. The same is true for larger loops involving
	involving three or more organizations.		three or more organizations.
	3.7. URL		3.7. URL
	The URL represents the organization web home page, as defined with		The URL represents the organization web home page, as defined with
	the <org:url> element.		the <org:url> element.
	3.8. Dates and Times		3.8. Dates and Times
	Date and time attribute values MUST be represented in Universal		Date and time attribute values MUST be represented in Universal
	Coordinated Time (UTC) using the Gregorian calendar. The extended		Coordinated Time (UTC) using the Gregorian calendar. The extended
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 31 ¶
	4.1.1. EPP <check> Command		4.1.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.
	In addition to the standard EPP command elements, the <check> command		In addition to the standard EPP command elements, the <check> command
	MUST contain an <org:check> element. This element or its ancestor		MUST contain an <org:check> element. This element or its ancestor
	element MUST identify the organization namespace. The <org:check>		element MUST identify the organization namespace
	ement contains the following child elements:		"urn:ietf:params:xml:ns:epp:org-1.0". The <org:check> element
			contains the following child elements:
	o One or more <org:id> elements that contain the server-unique		o One or more <org:id> elements that contain the server-unique
	identifier of the organization objects to be queried.		identifier of the organization objects to be queried.
	Example <check> command:		Example <check> 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: <check>		C: <check>
	skipping to change at page 8, line 41 ¶		skipping to change at page 9, line 23 ¶
	C: <org:id>1523res</org:id>		C: <org:id>1523res</org:id>
	C: </org:check>		C: </org:check>
	C: </check>		C: </check>
	C: <clTRID>ABC-12345</clTRID>		C: <clTRID>ABC-12345</clTRID>
	C: </command>		C: </command>
	C:</epp>		C:</epp>
	When a <check> command has been processed successfully, the EPP		When a <check> command has been processed successfully, the EPP
	<resData> element MUST contain a child <org:chkData> element. This		<resData> element MUST contain a child <org:chkData> element. This
	element or its ancestor element MUST identify the organization		element or its ancestor element MUST identify the organization
	namespace. The <org:chkData> element contains one or more <org:cd>		namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:chkData>
	elements that contain the following child elements:		element contains one or more <org:cd> elements that contain the
			following child elements:
	o An <org:id> element that identifies the queried object. This		o An <org:id> element that identifies the queried object. This
	element MUST contain an "avail" attribute whose value indicates		element MUST contain an "avail" attribute whose value indicates
	object availability (can it be provisioned or not) at the moment		object availability (can it be provisioned or not) at the moment
	the <check> command was completed. A value of "1" or "true" means		the <check> command was completed. A value of "1" or "true" means
	that the object can be provisioned. A value of "0" or "false"		that the object can be provisioned. A value of "0" or "false"
	means that the object cannot be provisioned.		means that the object cannot be provisioned.
	o An OPTIONAL <org:reason> element that may be provided when an		o An OPTIONAL <org:reason> element that may be provided when an
	object cannot be provisioned. If present, this element contains		object cannot be provisioned. If present, this element contains
	server-specific text to help explain why the object cannot be		server-specific text to help explain why the object cannot be
	provisioned. This text MUST be represented in the response		provisioned. This text MUST be represented in the response
	language previously negotiated with the client; an OPTIONAL "lang"		language previously negotiated with the client; an OPTIONAL "lang"
	attribute MAY be present to identify the language if the		attribute as defined in [RFC5646] may be present to identify the
	negotiated value is something other than the default value of		language if the negotiated value is something other than the
	"en"(English).		default value of "en"(English).
	Example <check> response:		Example <check> response:
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>		S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">		S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>		S: <response>
	S: <result code="1000">		S: <result code="1000">
	S: <msg lang="en">Command completed successfully</msg>		S: <msg lang="en">Command completed successfully</msg>
	S: </result>		S: </result>
	S: <resData>		S: <resData>
	skipping to change at page 9, line 50 ¶		skipping to change at page 10, line 39 ¶
	S: </trID>		S: </trID>
	S: </response>		S: </response>
	S:</epp>		S:</epp>
	An EPP error response MUST be returned if a <check> command cannot be		An EPP error response MUST be returned if a <check> command cannot be
	processed for any reason.		processed for any reason.
	4.1.2. EPP <info> Command		4.1.2. EPP <info> Command
	The EPP <info> command is used to retrieve information associated		The EPP <info> command is used to retrieve information associated
	with an organization object. It is up to the server policy to decide		with an organization object. In addition to the standard EPP command
	what attributes will be returned of an organization object. In		elements, the <info> command MUST contain a <org:info> element. This
	addition to the standard EPP command elements, the <info> command		element or its ancestor element MUST identify the organization
	MUST contain a <org:info> element. This element or its ancestor		namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:info>
	element MUST identify the organization namespace. The <org:info>
	element contains the following child elements:		element contains the following child elements:
	o An <org:id> element that contains the server-unique identifier of		o An <org:id> element that contains the server-unique identifier of
	the organization object to be queried.		the organization object to be queried.
	Example <info> command:		Example <info> 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>
	skipping to change at page 10, line 30 ¶		skipping to change at page 11, line 21 ¶
	C: <org:id>res1523</org:id>		C: <org:id>res1523</org:id>
	C: </org:info>		C: </org:info>
	C: </info>		C: </info>
	C: <clTRID>ABC-12345</clTRID>		C: <clTRID>ABC-12345</clTRID>
	C: </command>		C: </command>
	C:</epp>		C:</epp>
	When an <info> command has been processed successfully, the EPP		When an <info> command has been processed successfully, the EPP
	<resData> element MUST contain a child <org:infData> element. This		<resData> element MUST contain a child <org:infData> element. This
	element or its ancestor element MUST identify the organization		element or its ancestor element MUST identify the organization
	namespace. The <org:infData> element contains the following child		namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:infData>
	elements:		element contains the following child elements:
	o An <org:id> element that contains the server-unique identifier of		o An <org:id> element that contains the server-unique identifier of
	the organization object, as defined in Section 3.1.		the organization object, as defined in Section 3.1.
	o An <org:roid> element that contains the Repository Object		o An <org:roid> element that contains the Repository Object
	IDentifier assigned to the organization object when the object was		IDentifier assigned to the organization object when the object was
	created.		created.
	o One or more <org:role> elements that contain the role type, role		o One or more <org:role> elements that contain the role type, role
	statuses and optional role id of the organization.		statuses and optional role id of the organization.
	skipping to change at page 11, line 33 ¶		skipping to change at page 12, line 20 ¶
	8. The <org:postalInfo> element contains the following child		8. The <org:postalInfo> element contains the following child
	elements:		elements:
	* An <org:name> element that contains the name of the		* An <org:name> element that contains the name of the
	organization.		organization.
	* An OPTIONAL <org:addr> element that contains address		* An OPTIONAL <org:addr> element that contains address
	information associated with the organization. A <org:addr>		information associated with the organization. A <org:addr>
	element contains the following child elements:		element contains the following child elements:
	+ One, two, or three OPTIONAL <org:street> elements that		+ One, two, or three <org:street> elements that contain the
	contain the organization's street address.		organization's street address.
	+ An <org:city> element that contains the organization's city.		+ An <org:city> element that contains the organization's city.
	+ An OPTIONAL <org:sp> element that contains the		+ An OPTIONAL <org:sp> element that contains the
	organization's state or province.		organization's state or province.
	+ An OPTIONAL <org:pc> element that contains the		+ An OPTIONAL <org:pc> element that contains the
	organization's postal code.		organization's postal code.
	+ An <org:cc> element that contains the organization's country		+ An <org:cc> element that contains the alpha-2 organization's
	code.		country code. The detailed format of this element is
			described in section 2.4.3 of [RFC5733].
	o An OPTIONAL <org:voice> element that contains the organization's		o An OPTIONAL <org:voice> element that contains the organization's
	voice telephone number. The detailed format of this element is		voice telephone number. The detailed format of this element is
	described in Section 2.5 of [RFC5733].		described in Section 2.5 of [RFC5733].
	o An OPTIONAL <org:fax> element that contains the organization's		o An OPTIONAL <org:fax> element that contains the organization's
	facsimile telephone number.		facsimile telephone number.
	o An OPTIONAL <org:email> element that contains the organization's		o An OPTIONAL <org:email> element that contains the organization's
	email address.		email address. The detailed format of this element is described
			in section 2.6 of [RFC5733].
	o An OPTIONAL <org:url> element that contains the URL to the website		o An OPTIONAL <org:url> element that contains the URL to the website
	of the organization.		of the organization. The detailed format of this element is
			described in [RFC3986].
	o Zero or more OPTIONAL <org:contact> elements that contain		o Zero or more <org:contact> elements that contain identifiers for
	identifiers for the contact objects to be associated with the		the contact objects to be associated with the organization object.
	organization object. Contact object identifiers MUST be known to
	the server before the contact object can be associated with the		Contact object identifiers MUST be known to the server before the
	organization object. The required "type" is used to represent		contact object can be associated with the organization object.
	contact types. The type values include "admin", "tech",		The required "type" is used to represent contact types. The type
	"billing", "abuse", and "custom". The OPTIONAL "typeName"		values include "admin", "tech", "billing", "abuse", and "custom".
	attribute is used to define the name of a "custom" type.		The OPTIONAL "typeName" attribute is used to define the name of a
			"custom" type.
	o An OPTIONAL <org:clID> element that contains the organization		o An OPTIONAL <org:clID> element that contains the organization
	identifier of the sponsoring client. There is no <org:clID>		identifier of the sponsoring client. There is no <org:clID>
	element if the organization is managed by the registry.		element if the organization is managed by the registry.
	o An <org:crID> element that contains the identifier of the client		o An <org:crID> element that contains the identifier of the client
	that created the organization object.		that created the organization object.
	o An <org:crDate> element that contains the date and time of		o An <org:crDate> element that contains the date and time of
	organization object creation.		organization object creation.
	skipping to change at page 15, line 39 ¶		skipping to change at page 16, line 39 ¶
	service message that the action has been completed and that the		service message that the action has been completed and that the
	status of the object has changed. Other notification methods MAY be		status of the object has changed. Other notification methods MAY be
	used in addition to the required service message.		used in addition to the required service message.
	4.2.1. EPP <create> Command		4.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 an organization object. In addition to the standard		client to create an organization object. In addition to the standard
	EPP command elements, the <create> command MUST contain a		EPP command elements, the <create> command MUST contain a
	<org:create> element. This element or its ancestor element MUST		<org:create> element. This element or its ancestor element MUST
	identify the organization namespace. The <org:create> element		identify the organization namespace "urn:ietf:params:xml:ns:epp:org-
	contains the following child elements:		1.0". The <org:create> element contains the following child
			elements:
	o An <org:id> element that contains the desired server-unique		o An <org:id> element that contains the desired server-unique
	identifier for the organization to be created, as defined in		identifier for the organization to be created, as defined in
	Section 3.1.		Section 3.1.
	o One or more <org:role> elements that contain the role type, role		o One or more <org:role> elements that contain the role type, role
	statuses and optional role id of the organization.		statuses and optional role id of the organization.
	* An <org:type> element that contains the type of the		* An <org:type> element that contains the type of the
	organization, as defined in Section 3.2.		organization, as defined in Section 3.2.
	* Zero or more <org:status> elements that contain the role		* Zero or more <org:status> elements that contain the role
	statuses. The values of the role status are defined in		statuses. The values of the role status are defined in
	Section 3.5.		Section 3.5.
	* An OPTIONAL <org:roleID> element that contains a third-party-		* An OPTIONAL <org:roleID> element that contains a third-party-
	assigned identifier, such as IANA ID for registrars, as defined		assigned identifier, such as IANA ID for registrars, as defined
	in Section 3.2.3.		in Section 3.2.3.
	o Zero of more <org:status> element that contain the operational		o Zero or more <org:status> elements that contain the operational
	status of the organization, as defined in Section 3.4.		status of the organization, as defined in Section 3.4.
	o An OPTIONAL <org:parentId> element that contains the identifier of		o An OPTIONAL <org:parentId> element that contains the identifier of
	the parent object, as defined in Section 3.6.		the parent object, as defined in Section 3.6.
	o Zero to two <org:postalInfo> elements that contain postal-address		o Zero to two <org:postalInfo> elements that contain postal-address
	information. Two elements are provided so that address		information. Two elements are provided so that address
	information can be provided in both internationalized and		information can be provided in both internationalized and
	localized forms; a "type" attribute is used to identify the two		localized forms; a "type" attribute is used to identify the two
	forms. If an internationalized form (type="int") is provided,		forms. If an internationalized form (type="int") is provided,
	skipping to change at page 16, line 37 ¶		skipping to change at page 17, line 37 ¶
	8. The <org:postalInfo> element contains the following child		8. The <org:postalInfo> element contains the following child
	elements:		elements:
	* An <org:name> element that contains the name of the		* An <org:name> element that contains the name of the
	organization.		organization.
	* An OPTIONAL <org:addr> element that contains address		* An OPTIONAL <org:addr> element that contains address
	information associated with the organization. A <org:addr>		information associated with the organization. A <org:addr>
	element contains the following child elements:		element contains the following child elements:
	+ One, two, or three OPTIONAL <org:street> elements that		+ One, two, or three <org:street> elements that contain the
	contain the organization's street address.		organization's street address.
	+ An <org:city> element that contains the organization's city.		+ An <org:city> element that contains the organization's city.
	+ An OPTIONAL <org:sp> element that contains the		+ An OPTIONAL <org:sp> element that contains the
	organization's state or province.		organization's state or province.
	+ An OPTIONAL <org:pc> element that contains the		+ An OPTIONAL <org:pc> element that contains the
	organization's postal code.		organization's postal code.
	+ An <org:cc> element that contains the organization's country		+ An <org:cc> element that contains the alpha-2 organization's
	code.		country code. The detailed format of this element is
			described in section 2.4.3 of [RFC5733].
	o An OPTIONAL <org:voice> element that contains the organization's		o An OPTIONAL <org:voice> element that contains the organization's
	voice telephone number.		voice telephone number. The detailed format of this element is
			described in Section 2.5 of [RFC5733]
	o An OPTIONAL <org:fax> element that contains the organization's		o An OPTIONAL <org:fax> element that contains the organization's
	facsimile telephone number.		facsimile telephone number.
	o An OPTIONAL <org:email> element that contains the organization's		o An OPTIONAL <org:email> element that contains the organization's
	email address.		email address. The detailed format of this element is described
			in section 2.6 of [RFC5733].
	o An OPTIONAL <org:url> element that contains the URL to the website		o An OPTIONAL <org:url> element that contains the URL to the website
	of the organization.		of the organization. The detailed format of this element is
			described in [RFC3986].
	o Zero or more OPTIONAL <org:contact> elements that contain		o Zero or more <org:contact> elements that contain identifiers for
	identifiers for the contact objects associated with the		the contact objects associated with the organization object.
	organization object.
	Example <create> command:		Example <create> 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: <create>		C: <create>
	C: <org:create		C: <org:create
	C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">		C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
	C: <org:id>res1523</org:id>		C: <org:id>res1523</org:id>
	skipping to change at page 18, line 42 ¶		skipping to change at page 19, line 42 ¶
	C: <org:contact type="billing">sh8013</org:contact>		C: <org:contact type="billing">sh8013</org:contact>
	C: </org:create>		C: </org:create>
	C: </create>		C: </create>
	C: <clTRID>ABC-12345</clTRID>		C: <clTRID>ABC-12345</clTRID>
	C: </command>		C: </command>
	C:</epp>		C:</epp>
	When a <create> command has been processed successfully, the EPP		When a <create> command has been processed successfully, the EPP
	<resData> element MUST contain a child <org:creData> element. This		<resData> element MUST contain a child <org:creData> element. This
	element or its ancestor element MUST identify the organization		element or its ancestor element MUST identify the organization
	namespace. The <org:creData> element contains the following child		namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:creData>
	elements:		element contains the following child elements:
	o An <org:id> element that contains the server-unique identifier for		o An <org:id> element that contains the server-unique identifier for
	the created organization, as defined in Section 3.1.		the created organization, as defined in Section 3.1.
	o An <org:crDate> element that contains the date and time of		o An <org:crDate> element that contains the date and time of
	organization-object creation.		organization-object creation.
	Example <create> response:		Example <create> response:
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>		S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	skipping to change at page 19, line 34 ¶		skipping to change at page 20, line 34 ¶
	An EPP error response MUST be returned if a <create> command cannot		An EPP error response MUST be returned if a <create> command cannot
	be processed for any reason.		be processed for any reason.
	4.2.2. EPP <delete> Command		4.2.2. EPP <delete> Command
	The EPP <delete> command provides a transform operation that allows a		The EPP <delete> command provides a transform operation that allows a
	client to delete an organization object. In addition to the standard		client to delete an organization object. In addition to the standard
	EPP command elements, the <delete> command MUST contain an		EPP command elements, the <delete> command MUST contain an
	<org:delete> element. This element or its ancestor element MUST		<org:delete> element. This element or its ancestor element MUST
	identify the organization namespace. The <org:delete> element MUST		identify the organization namespace "urn:ietf:params:xml:ns:epp:org-
	contain the following child element:		1.0". The <org:delete> element MUST contain the following child
			element:
	o An <org:id> element that contains the server-unique identifier of		o An <org:id> element that contains the server-unique identifier of
	the organization object to be deleted, as defined in Section 3.1.		the organization object to be deleted, as defined in Section 3.1.
	An organization object MUST NOT be deleted if it is associated with		An organization object MUST NOT be deleted if it is associated with
	other known objects. An associated organization MUST NOT be deleted		other known objects. An associated organization MUST NOT be deleted
	until associations with other known objects have been broken. A		until associations with other known objects have been broken. A
	server MUST notify clients that object relationships exist by sending		server MUST notify clients that object relationships exist by sending
	a 2305 error response code when a <delete> command is attempted and		a 2305 error response code when a <delete> command is attempted and
	fails due to existing object relationships.		fails due to existing object relationships.
	skipping to change at page 21, line 11 ¶		skipping to change at page 22, line 11 ¶
	Transfer semantics do not apply to organization objects, so there is		Transfer semantics do not apply to organization objects, so there is
	no mapping defined for the EPP <transfer> command.		no mapping defined for the EPP <transfer> command.
	4.2.5. EPP <update> Command		4.2.5. EPP <update> Command
	The EPP <update> command provides a transform operation that allows a		The EPP <update> command provides a transform operation that allows a
	client to modify the attributes of an organization object. In		client to modify the attributes of an organization object. In
	addition to the standard EPP command elements, the <update> command		addition to the standard EPP command elements, the <update> command
	MUST contain a <org:update> element. This element or its ancestor		MUST contain a <org:update> element. This element or its ancestor
	element MUST identify the organization namespace. The <org:update>		element MUST identify the organization namespace
	element contains the following child elements:		"urn:ietf:params:xml:ns:epp:org-1.0". The <org:update> element
			contains the following child elements:
	o An <org:id> element that contains the server-unique identifier of		o An <org:id> element that contains the server-unique identifier of
	the organization object to be updated, as defined in Section 3.1.		the organization object to be updated, as defined in Section 3.1.
	o An OPTIONAL <org:add> element that contains attribute values to be		o An OPTIONAL <org:add> element that contains attribute values to be
	added to the object.		added to the object.
	o An OPTIONAL <org:rem> element that contains attribute values to be		o An OPTIONAL <org:rem> element that contains attribute values to be
	removed from the object.		removed from the object.
	skipping to change at page 22, line 5 ¶		skipping to change at page 23, line 5 ¶
	uniquely identifies the role to update.		uniquely identifies the role to update.
	* Zero or more <org:status> elements that contain the role		* Zero or more <org:status> elements that contain the role
	statuses. The values of the role status are defined in		statuses. The values of the role status are defined in
	Section 3.5.		Section 3.5.
	* An OPTIONAL <org:roleID> element that contains a third-party-		* An OPTIONAL <org:roleID> element that contains a third-party-
	assigned identifier, such as IANA ID for registrars, as defined		assigned identifier, such as IANA ID for registrars, as defined
	in Section 3.2.3.		in Section 3.2.3.
	o Zero or more <org:status> element that contain the operational		o Zero or more <org:status> elements that contain the operational
	status of the organization.		status of the organization.
	An OPTIONAL <org:chg> element contains the following child elements,		An OPTIONAL <org:chg> element contains the following child elements,
	where at least one child element MUST be present:		where at least one child element MUST be present:
	o An OPTIONAL <org:parentId> element that contains the identifier of		o An OPTIONAL <org:parentId> element that contains the identifier of
	the parent object.		the parent object.
	o Zero to two <org:postalInfo> elements that contain postal-address		o Zero to two <org:postalInfo> elements that contain postal-address
	information. Two elements are provided so that address		information. Two elements are provided so that address
	skipping to change at page 22, line 35 ¶		skipping to change at page 23, line 35 ¶
	is supported to allow a type of postal info to be removed. The		is supported to allow a type of postal info to be removed. The
	<org:postalInfo> element contains the following child elements:		<org:postalInfo> element contains the following child elements:
	* An <org:name> element that contains the name of the		* An <org:name> element that contains the name of the
	organization.		organization.
	* An OPTIONAL <org:addr> element that contains address		* An OPTIONAL <org:addr> element that contains address
	information associated with the organization. A <org:addr>		information associated with the organization. A <org:addr>
	element contains the following child elements:		element contains the following child elements:
	+ One, two, or three OPTIONAL <org:street> elements that		+ One, two, or three <org:street> elements that contain the
	contain the organization's street address.		organization's street address.
	+ An <org:city> element that contains the organization's city.		+ An <org:city> element that contains the organization's city.
	+ An OPTIONAL <org:sp> element that contains the		+ An OPTIONAL <org:sp> element that contains the
	organization's state or province.		organization's state or province.
	+ An OPTIONAL <org:pc> element that contains the		+ An OPTIONAL <org:pc> element that contains the
	organization's postal code.		organization's postal code.
	+ An <org:cc> element that contains the organization's country		+ An <org:cc> element that contains the alpha-2 organization's
	code.		country code. The detailed format of this element is
			described in section 2.4.3 of [RFC5733].
	o An OPTIONAL <org:voice> element that contains the organization's		o An OPTIONAL <org:voice> element that contains the organization's
	voice telephone number.		voice telephone number. The detailed format of this element is
			described in Section 2.5 of [RFC5733]
	o An OPTIONAL <org:fax> element that contains the organization's		o An OPTIONAL <org:fax> element that contains the organization's
	facsimile telephone number.		facsimile telephone number.
	o An OPTIONAL <org:email> element that contains the organization's		o An OPTIONAL <org:email> element that contains the organization's
	email address.		email address. The detailed format of this element is described
			in section 2.6 of [RFC5733].
	o An OPTIONAL <org:url> element that contains the URL to the website		o An OPTIONAL <org:url> element that contains the URL to the website
	of the organization.		of the organization. The detailed format of this element is
			described in [RFC3986]
	Example <update> command:		Example <update> 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: <update>		C: <update>
	C: <org:update		C: <org:update
	C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">		C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
	C: <org:id>res1523</org:id>		C: <org:id>res1523</org:id>
	skipping to change at page 25, line 30 ¶		skipping to change at page 26, line 30 ¶
	4.3. Offline Review of Requested Actions		4.3. Offline Review of Requested Actions
	Commands are processed by a server in the order they are received		Commands are processed by a server in the order they are received
	from a client. Though an immediate response confirming receipt and		from a client. Though an immediate response confirming receipt and
	processing of the command is produced by the server, a server		processing of the command is produced by the server, a server
	operator MAY perform an offline review of requested transform		operator MAY perform an offline review of requested transform
	commands before completing the requested action. In such situations,		commands before completing the requested action. In such situations,
	the response from the server MUST clearly note that the transform		the response from the server MUST clearly note that the transform
	command has been received and processed, but the requested action is		command has been received and processed, but the requested action is
	pending. The status of the corresponding object MUST clearly reflect		pending. The status in the response of the corresponding object MUST
	processing of the pending action. The server MUST notify the client		clearly reflect processing of the pending action. The server MUST
	when offline processing of the action has been completed.		notify the client when offline processing of the action has been
			completed.
	Examples describing a <create> command that requires offline review		Examples describing a <create> command that requires offline review
	are included here. Note the result code and message returned in		are included here. Note the result code and message returned in
	response to the <create> command.		response to the <create> command.
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>		S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">		S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>		S: <response>
	S: <result code="1001">		S: <result code="1001">
	S: <msg lang="en">Command completed successfully;		S: <msg lang="en">Command completed successfully;
	skipping to change at page 26, line 29 ¶		skipping to change at page 27, line 29 ¶
	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 status of the organization object after returning this response		The status of the organization object after returning this response
	MUST include "pendingCreate". The server operator reviews the		MUST include "pendingCreate". The server operator reviews the
	request offline, and informs the client of the outcome of the review		request offline, and informs the client of the outcome of the review
	either by queuing a service message for retrieval via the <poll>		by queuing a service message for retrieval via the <poll> command; it
	command or by using an out-of-band mechanism to inform the client of		MAY additionally use an out-of-band mechanism to inform the client of
	the request.		the outcome.
	The service message MUST contain text that describes the notification		The service message MUST contain text that describes the notification
	in the child <msg> element of the response <msgQ> element. In		in the child <msg> element of the response <msgQ> element. In
	addition, the EPP <resData> element MUST contain a child		addition, the EPP <resData> element MUST contain a child
	<org:panData> element. This element or its ancestor element MUST		<org:panData> element. This element or its ancestor element MUST
	identify the organization namespace. The <org:panData> element		identify the organization namespace "urn:ietf:params:xml:ns:epp:org-
	contains the following child elements:		1.0". The <org:panData> element contains the following child
			elements:
	o An <org:id> element that contains the server-unique identifier of		o An <org:id> element that contains the server-unique identifier of
	the organization object. The <org:id> element contains a REQUIRED		the organization object. The <org:id> element contains a REQUIRED
	"paResult" attribute. A positive boolean value indicates that the		"paResult" attribute. A positive boolean value indicates that the
	request has been approved and completed. A negative boolean value		request has been approved and completed. A negative boolean value
	indicates that the request has been denied and the requested		indicates that the request has been denied and the requested
	action has not been taken.		action has not been taken.
	o An <org:paTRID> element that contains the client transaction		o An <org:paTRID> element that contains the client transaction
	identifier and server transaction identifier returned with the		identifier and server transaction identifier returned with the
	skipping to change at page 37, line 14 ¶		skipping to change at page 38, line 14 ¶
	7.2. EPP Extension Registry		7.2. EPP Extension Registry
	The EPP extension described in this document should be registered by		The EPP extension described in this document should be registered by
	the IANA in the EPP Extension Registry described in [RFC7451]. The		the IANA in the EPP Extension Registry described in [RFC7451]. The
	details of the registration are as follows:		details of the registration are as follows:
	Name of Extension: Extensible Provisioning Protocol (EPP)		Name of Extension: Extensible Provisioning Protocol (EPP)
	Organization Mapping		Organization Mapping
			Document status: Standards Track
			Reference: RFCXXXX (please replace "XXXX" with the RFC number for
			this document after a number is assigned by the RFC Editor)
	Registrant Name and Email Address: IESG, iesg@ietf.org		Registrant Name and Email Address: IESG, iesg@ietf.org
	TLDs: Any		TLDs: Any
	IPR Disclosure: None		IPR Disclosure: None
	Status: Active		Status: Active
	Notes: None		Notes: None
	skipping to change at page 37, line 37 ¶		skipping to change at page 38, line 42 ¶
	the organization roles. The name of this registry is "EPP		the organization roles. The name of this registry is "EPP
	Organization Role Values". The registration policy for this registry		Organization Role Values". The registration policy for this registry
	is "Expert Review" [RFC8126].		is "Expert Review" [RFC8126].
	7.3.1. Registration Template		7.3.1. Registration Template
	Value: the string value being registered.		Value: the string value being registered.
	Description: Brief description of the organization role values.		Description: Brief description of the organization role values.
	Registrant Name: For Standards Track RFCs, state "IESG". For others,		Registrant Name: For IETF RFCs, state "IESG". For others, give the
	give the name of the responsible party.		name of the responsible party.
	Registrant Contact Information: an email address, postal address, or		Registrant Contact Information: an email address, postal address, or
	some other information to be used to contact the registrant.		some other information to be used to contact the registrant.
	7.3.2. Initial Registry Contents		7.3.2. Initial Registry Contents
	Followings are the initial registry contents:		Followings are the initial registry contents:
	Value: registrar		Value: registrar
	Description: The entity object instance represents the authority		Description: The entity object instance represents the authority
	responsible for the registration in the registry.		responsible for the registration in the registry.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: reseller		Value: reseller
	Description: The entity object instance represents a third party		Description: The entity object instance represents a third party
	through which the registration was conducted (i.e., not the		through which the registration was conducted (i.e., not the
	registry or registrar).		registry or registrar).
	Registrant Name: IESG		Registrant Name: IESG
	skipping to change at page 39, line 50 ¶		skipping to change at page 41, line 7 ¶
	previous reseller mapping according to this document.		previous reseller mapping according to this document.
	Level of maturity: Development		Level of maturity: Development
	Coverage: EPP organization mapping		Coverage: EPP organization mapping
	Contact: zhouguiqing@cnnic.cn		Contact: zhouguiqing@cnnic.cn
	9. Security Considerations		9. Security Considerations
	The object mapping extension described in this document does not		The organization object may have personally identifiable information,
	provide any other security services or introduce any additional		such as <org:contact>. This information is not a required element in
	considerations beyond those described by [RFC5730] or those caused by		this document which can be provided on a voluntary basis. If it is
	the protocol layers used by EPP. The security considerations		provided, both client and server MUST ensure that authorization
	described in these other specifications apply to this specification		information is stored and exchanged with high-grade encryption
	as well.		mechanisms to provide privacy services, which is specified in
			[RFC5733]. The security considerations described in [RFC5730] or
			those caused by the protocol layers used by EPP will apply to this
			specification as well.
	10. Acknowledgment		10. Acknowledgment
	The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick		The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick
	Mevzek, Antoin Verschuren and Scott Hollenbeck for their careful		Mevzek, Antoin Verschuren and Scott Hollenbeck for their careful
	review and valuable comments.		review and valuable comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at page 40, line 31 ¶		skipping to change at page 41, line 40 ¶
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <https://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66,
			RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
			[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
			Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
			September 2009, <https://www.rfc-editor.org/info/rfc5646>.
	[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",		[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
	STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,		STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
	<https://www.rfc-editor.org/info/rfc5730>.		<https://www.rfc-editor.org/info/rfc5730>.
	[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)		[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
	Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,		Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
	August 2009, <https://www.rfc-editor.org/info/rfc5733>.		August 2009, <https://www.rfc-editor.org/info/rfc5733>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	skipping to change at page 44, line 40 ¶		skipping to change at page 46, line 10 ¶
	* Removed the maxOccurs value of "reason" element.		* Removed the maxOccurs value of "reason" element.
	Organization WG document-11:		Organization WG document-11:
	* Typo of RFC2781 and moved this reference in "Informative		* Typo of RFC2781 and moved this reference in "Informative
	References".		References".
	* "Loops MUST be prohibited." in section 3.6.		* "Loops MUST be prohibited." in section 3.6.
			Organization WG document-12:
			* Removed "OPTIONAL" when "zero or more" or "zero to two"
			appears.
			* Updated the "Organization Status Values" text.
			* Updated the full xml namespace.
			* Updated the text in "Offline review".
			* Updated the text in "Security Considerations".
			* Added "Document satus" and "Reference" in section "EPP
			Extension Registry".
			* Added references of RFC3688,RFC3986 and RFC5646.
	Authors' Addresses		Authors' Addresses
	Linlin Zhou		Linlin Zhou
	CNNIC		CNNIC
	4 South 4th Street, Zhongguancun, Haidian District		4 South 4th Street, Zhongguancun, Haidian District
	Beijing, Beijing 100190		Beijing, Beijing 100190
	China		China
	Email: zhoulinlin@cnnic.cn		Email: zhoulinlin@cnnic.cn
	Ning Kong		Ning Kong
	Consultant		Consultant
	Email: ietfing@gmail.com		Email: ietfing@gmail.com
	Guiqing Zhou		Guiqing Zhou
	CNNIC		CNNIC
	4 South 4th Street, Zhongguancun, Haidian District		4 South 4th Street, Zhongguancun, Haidian District
	Beijing, Beijing 100190		Beijing, Beijing 100190
	China		China
End of changes. 59 change blocks.
	135 lines changed or deleted		207 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/