draft-ietf-regext-org-08.txt   draft-ietf-regext-org-09.txt 
Internet Engineering Task Force L. Zhou Internet Engineering Task Force L. Zhou
Internet-Draft N. Kong Internet-Draft CNNIC
Intended status: Standards Track G. Zhou Intended status: Standards Track N. Kong
Expires: January 3, 2019 X. Lee Expires: February 21, 2019 Consultant
G. Zhou
J. Yao
CNNIC CNNIC
J. Gould J. Gould
Verisign, Inc. Verisign, Inc.
July 2, 2018 August 20, 2018
Extensible Provisioning Protocol (EPP) Organization Mapping Extensible Provisioning Protocol (EPP) Organization Mapping
draft-ietf-regext-org-08 draft-ietf-regext-org-09
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 38 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 January 3, 2019. This Internet-Draft will expire on February 21, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 7
4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7
4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 8 4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 8
4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 10 4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 9
4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 15 4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 15
4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15
4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 15 4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 15
4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 19 4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 19
4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 20 4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 20
4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 20 4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 20
4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 21 4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 21
4.3. Offline Review of Requested Actions . . . . . . . . . . . 25 4.3. Offline Review of Requested Actions . . . . . . . . . . . 25
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Internationalization Considerations . . . . . . . . . . . . . 36 6. Internationalization Considerations . . . . . . . . . . . . . 36
skipping to change at page 3, line 18 skipping to change at page 3, line 8
7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 37 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 37
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 38 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 38
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 39 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 39
8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 39 8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 an object in EPP which will be specified as "organization" in this
document. document.
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 Extensible Provisioning Protocol (EPP) [RFC5730]. This
mapping is specified using the XML 1.0 as described in mapping is specified using the XML 1.0 as described in
[W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xml-20040204] and XML Schema notation as described in
[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. [W3C.REC-xmlschema-1-20041028] and [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 [RFC2119]. document are to be interpreted as described in BCP 14
[RFC2119][RFC8174] when, and only when, they appear in all capitals,
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 to develop a conforming implementation.
"org-1.0" in is used as an abbreviation for The XML namespace prefix "org" is used, but implementations MUST NOT
"urn:ietf:params:xml:ns:org-1.0". The XML namespace prefix "org" is depend on it and instead employ a proper namespace-aware XML parser
used, but implementations MUST NOT depend on it and instead employ a and serializer to interpret and output the XML documents.
proper namespace-aware XML parser 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
normative references. normative references.
skipping to change at page 4, line 35 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 support a list of values. An organization role MUST have a type which supports a list of
An organization could have multiple roles with a different role type. values. An organization could have multiple roles with a different
See Section 7.3 for a list of values. Its corresponding element is role type. See Section 7.3 for a list of values. Its corresponding
<org:type>. element 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
for registrars. Its corresponding element is <org:roleid>. for registrars. Its corresponding element is <org:roleID>.
Example of organization role identifier: Example of organization role identifier:
<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 a server-unique identifier.
Contact identifiers are character strings with a specific 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. The default value is "ok". status value.
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 status values that can be added or
removed by a server are prefixed with "server". The "hold" and 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.
Status Value Descriptions: Status Value Descriptions:
skipping to change at page 5, line 47 skipping to change at page 5, line 40
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
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 organization MUST be rejected. links to the organization MUST be rejected.
o clientUpdateProhibited, serverUpdateProhibited: Requests to update o clientUpdateProhibited, serverUpdateProhibited: Requests to update
the object (other than to remove this status) MUST be rejected. the object (other than to remove this status) MUST be rejected.
o clientDeleteProhibited, serverDeleteProhibited: Requests to delete o clientDeleteProhibited, serverDeleteProhibited: Requests to delete
the object MUST be rejected. the object MUST be rejected.
skipping to change at page 6, line 39 skipping to change at page 6, line 33
"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.
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". The default value is "ok". "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 pending operations or prohibitions. This value is set and removed
by the server as other status values are added or 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
skipping to change at page 7, line 15 skipping to change at page 7, line 12
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 Take a reseller organization, for example, the parent identifier is
not defined for the top level reseller, namely the registrar of the not defined for the top level reseller, namely the registrar of the
registry. An N-tier reseller has a parent reseller and at least one registry. An N-tier reseller has a parent reseller and at least one
child reseller. A reseller customer has a parent reseller and no child reseller. A reseller customer has a parent reseller and no
child resellers. child resellers.
Loops SHOULD be prohibited. If organization A has B as parent Loops SHOULD be prohibited. For example: if organization A has B as
identifier, organization B must not have organization A as parent its parent identifier, organization B should not have organization A
identifier. as its parent identifier. The same is true for larger loops
involving 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 16 skipping to change at page 8, line 14
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 a <org:check> element that identifies the organization MUST contain an <org:check> element. This element or its ancestor
namespace. The <org:check> element contains the following child element MUST identify the organization namespace. The <org:check>
elements: ement 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 8, line 39
C: <org:id>res1523</org:id> C: <org:id>res1523</org:id>
C: <org:id>re1523</org:id> C: <org:id>re1523</org:id>
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 that <resData> element MUST contain a child <org:chkData> element. This
identifies the organization namespace. The <org:chkData> element element or its ancestor element MUST identify the organization
contains one or more <org:cd> elements that contain the following namespace. The <org:chkData> element contains one or more <org:cd>
child elements: elements that contain the following child elements:
o A <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 MAY be present to identify the language if the
negotiated value is something other than the default value of negotiated value is something other than the default value of
"en"(English). "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>Command completed successfully</msg> S: <msg lang="en">Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <org:chkData S: <org:chkData
S: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> S: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
S: <org:cd> S: <org:cd>
S: <org:id avail="1">res1523</org:id> S: <org:id avail="1">res1523</org:id>
S: </org:cd> S: </org:cd>
S: <org:cd> S: <org:cd>
S: <org:id avail="0">re1523</org:id> S: <org:id avail="0">re1523</org:id>
S: <org:reason>In use</org:reason> S: <org:reason lang="en">In use</org:reason>
S: </org:cd> S: </org:cd>
S: <org:cd> S: <org:cd>
S: <org:id avail="1">1523res</org:id> S: <org:id avail="1">1523res</org:id>
S: </org:cd> S: </org:cd>
S: </org:chkData> S: </org:chkData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
skipping to change at page 10, line 11 skipping to change at page 10, line 5
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. It is up to the server policy to decide
what attributes will be returned of an organization object. In what attributes will be returned of an organization object. In
addition to the standard EPP command elements, the <info> command addition to the standard EPP command elements, the <info> command
MUST contain a <org:info> element that identifies the organization MUST contain a <org:info> element. This element or its ancestor
namespace. The <org:info> element contains the following child element MUST identify the organization namespace. The <org:info>
elements: element contains the following child elements:
o A <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>
C: <info> C: <info>
C: <org:info C: <org:info
C: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> C: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
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 that <resData> element MUST contain a child <org:infData> element. This
identifies the organization namespace. The <org:infData> element element or its ancestor element MUST identify the organization
contains the following child elements: namespace. The <org:infData> element contains the following child
elements:
o A <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 A <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 contains 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.
* A <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.
* One or more <org:status> elements that contains the role * One 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 One or more <org:status> elements that contains the operational o One 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,
element content MUST be represented in a subset of UTF-8 that can element content MUST be represented in a subset of Unicode in the
be represented in the 7-bit US-ASCII character set. If a range U+0020 - U+007E. If a localized form (type="loc") is
localized form (type="loc") is provided, element content MAY be provided, element content MAY be represented in unrestricted UTF-
represented in unrestricted UTF-8. The <org:postalInfo> element 8. The <org:postalInfo> element contains the following child
contains the following child elements: elements:
* A <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 OPTIONAL <org:street> elements that
contain the organization's street address. contain the organization's street address.
+ A <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.
+ A <org:cc> element that contains the organization's country + An <org:cc> element that contains the organization's country
code. code.
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.
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.
skipping to change at page 12, line 27 skipping to change at page 12, line 24
the server before the contact object can be associated with the the server before the contact object can be associated with the
organization object. The required "type" is used to represent organization object. The required "type" is used to represent
contact types. The type values include "admin", "tech", contact types. The type values include "admin", "tech",
"billing", "abuse", and "custom". The OPTIONAL "typeName" "billing", "abuse", and "custom". The OPTIONAL "typeName"
attribute is used to define the name of a "custom" type. 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 A <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 A <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.
o A <org:upID> element that contains the identifier of the client o An <org:upID> element that contains the identifier of the client
that last updated the organization object. This element MUST NOT that last updated the organization object. This element MUST NOT
be present if the organization has never been modified. be present if the organization has never been modified.
o A <org:upDate> element that contains the date and time of the most o An <org:upDate> element that contains the date and time of the
recent organization object modification. This element MUST NOT be most recent organization object modification. This element MUST
present if the organization object has never been modified. NOT be present if the organization object has never been modified.
Example <info> response for "Example Registrar Inc." organization Example <info> response for "Example Registrar Inc." organization
organization object with identifier "registrar1362": organization object with identifier "registrar1362":
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>Command completed successfully</msg> S: <msg lang="en">Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <org:infData S: <org:infData
S: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> S: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
S: <org:id>registrar1362</org:id> S: <org:id>registrar1362</org:id>
S: <org:roid>registrar1362-REP</org:roid> S: <org:roid>registrar1362-REP</org:roid>
S: <org:role> S: <org:role>
S: <org:type>registrar</org:type> S: <org:type>registrar</org:type>
S: <org:status>ok</org:status> S: <org:status>ok</org:status>
S: <org:status>linked</org:status> S: <org:status>linked</org:status>
S: <org:roleid>1362</org:roleid> S: <org:roleID>1362</org:roleID>
S: </org:role> S: </org:role>
S: <org:status>ok</org:status> S: <org:status>ok</org:status>
S: <org:postalInfo type="int"> S: <org:postalInfo type="int">
S: <org:name>Example Registrar Inc.</org:name> S: <org:name>Example Registrar Inc.</org:name>
S: <org:addr> S: <org:addr>
S: <org:street>123 Example Dr.</org:street> S: <org:street>123 Example Dr.</org:street>
S: <org:street>Suite 100</org:street> S: <org:street>Suite 100</org:street>
S: <org:city>Dulles</org:city> S: <org:city>Dulles</org:city>
S: <org:sp>VA</org:sp> S: <org:sp>VA</org:sp>
S: <org:pc>20166-6503</org:pc> S: <org:pc>20166-6503</org:pc>
S: <org:cc>US</org:cc> S: <org:cc>US</org:cc>
S: </org:addr> S: </org:addr>
S: </org:postalInfo> S: </org:postalInfo>
S: <org:voice x="1234">+1.7035555555</org:voice> S: <org:voice x="1234">+1.7035555555</org:voice>
S: <org:fax>+1.7035555556</org:fax> S: <org:fax>+1.7035555556</org:fax>
S: <org:email>contact@organization.example</org:email> S: <org:email>contact@organization.example</org:email>
S: <org:url>http://organization.example</org:url> S: <org:url>https://organization.example</org:url>
S: <org:contact type="admin">sh8013</org:contact> S: <org:contact type="admin">sh8013</org:contact>
S: <org:contact type="billing">sh8013</org:contact> S: <org:contact type="billing">sh8013</org:contact>
S: <org:contact type="custom" S: <org:contact type="custom"
S: typeName="legal">sh8013</org:contact> S: typeName="legal">sh8013</org:contact>
S: <org:crID>ClientX</org:crID> S: <org:crID>ClientX</org:crID>
S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate> S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate>
S: <org:upID>ClientX</org:upID> S: <org:upID>ClientX</org:upID>
S: <org:upDate>1999-12-03T09:00:00.0Z</org:upDate> S: <org:upDate>1999-12-03T09:00:00.0Z</org:upDate>
S: </org:infData> S: </org:infData>
S: </resData> S: </resData>
skipping to change at page 14, line 9 skipping to change at page 14, line 9
S: </response> S: </response>
S:</epp> S:</epp>
Example <info> response for "Example Reseller Inc." organization Example <info> response for "Example Reseller Inc." organization
object of reseller type managed by identifier "registrar1362": object of reseller type managed by identifier "registrar1362":
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>Command completed successfully</msg> S: <msg lang="en">Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <org:infData S: <org:infData
S: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> S: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
S: <org:id>reseller1523</org:id> S: <org:id>reseller1523</org:id>
S: <org:roid>reseller1523-REP</org:roid> S: <org:roid>reseller1523-REP</org:roid>
S: <org:role> S: <org:role>
S: <org:type>reseller</org:type> S: <org:type>reseller</org:type>
S: <org:status>ok</org:status> S: <org:status>ok</org:status>
S: <org:status>linked</org:status> S: <org:status>linked</org:status>
skipping to change at page 14, line 35 skipping to change at page 14, line 35
S: <org:addr> S: <org:addr>
S: <org:street>123 Example Dr.</org:street> S: <org:street>123 Example Dr.</org:street>
S: <org:street>Suite 100</org:street> S: <org:street>Suite 100</org:street>
S: <org:city>Dulles</org:city> S: <org:city>Dulles</org:city>
S: <org:sp>VA</org:sp> S: <org:sp>VA</org:sp>
S: <org:pc>20166-6503</org:pc> S: <org:pc>20166-6503</org:pc>
S: <org:cc>US</org:cc> S: <org:cc>US</org:cc>
S: </org:addr> S: </org:addr>
S: </org:postalInfo> S: </org:postalInfo>
S: <org:fax>+1.7035555556</org:fax> S: <org:fax>+1.7035555556</org:fax>
S: <org:url>http://organization.example</org:url> S: <org:url>https://organization.example</org:url>
S: <org:contact type="admin">sh8013</org:contact> S: <org:contact type="admin">sh8013</org:contact>
S: <org:clID>1362</org:clID> S: <org:clID>1362</org:clID>
S: <org:crID>ClientX</org:crID> S: <org:crID>ClientX</org:crID>
S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate> S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate>
S: <org:upID>ClientX</org:upID> S: <org:upID>ClientX</org:upID>
S: <org:upDate>1999-12-03T09:00:00.0Z</org:upDate> S: <org:upDate>1999-12-03T09:00:00.0Z</org:upDate>
S: </org:infData> S: </org:infData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
skipping to change at page 15, line 44 skipping to change at page 15, line 44
perform a transform command on a given object. Any attempt to perform a transform command on a given object. Any attempt to
transform an object by an unauthorized client MUST be rejected, and transform an object by an unauthorized client MUST be rejected, and
the server MUST return a 2201 response code to the client to note the server MUST return a 2201 response code to the client to note
that the client lacks privileges to execute the requested command. that the client lacks privileges to execute the requested command.
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 that identifies the organization namespace. The <org:create> element. This element or its ancestor element MUST
<org:create> element contains the following child elements: identify the organization namespace. The <org:create> element
contains the following child elements:
o A <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 contains 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.
* A <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 contains 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 contains the operational o Zero of more <org:status> element 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,
element content MUST be represented in a subset of UTF-8 that can element content MUST be represented in a subset of Unicode in the
be represented in the 7-bit US-ASCII character set. If a range U+0020 - U+007E. If a localized form (type="loc") is
localized form (type="loc") is provided, element content MAY be provided, element content MAY be represented in unrestricted UTF-
represented in unrestricted UTF-8. The <org:postalInfo> element 8. The <org:postalInfo> element contains the following child
contains the following child elements: elements:
* A <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 OPTIONAL <org:street> elements that
contain the organization's street address. contain the organization's street address.
+ A <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.
+ A <org:cc> element that contains the organization's country + An <org:cc> element that contains the organization's country
code. code.
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.
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.
skipping to change at page 18, line 30 skipping to change at page 18, line 30
C: <org:street>Suite 100</org:street> C: <org:street>Suite 100</org:street>
C: <org:city>Dulles</org:city> C: <org:city>Dulles</org:city>
C: <org:sp>VA</org:sp> C: <org:sp>VA</org:sp>
C: <org:pc>20166-6503</org:pc> C: <org:pc>20166-6503</org:pc>
C: <org:cc>US</org:cc> C: <org:cc>US</org:cc>
C: </org:addr> C: </org:addr>
C: </org:postalInfo> C: </org:postalInfo>
C: <org:voice x="1234">+1.7035555555</org:voice> C: <org:voice x="1234">+1.7035555555</org:voice>
C: <org:fax>+1.7035555556</org:fax> C: <org:fax>+1.7035555556</org:fax>
C: <org:email>contact@organization.example</org:email> C: <org:email>contact@organization.example</org:email>
C: <org:url>http://organization.example</org:url> C: <org:url>https://organization.example</org:url>
C: <org:contact type="admin">sh8013</org:contact> C: <org:contact type="admin">sh8013</org:contact>
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 that <resData> element MUST contain a child <org:creData> element. This
identifies the organization namespace. The <org:creData> element element or its ancestor element MUST identify the organization
contains the following child elements: namespace. The <org:creData> element contains the following child
elements:
o A <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 A <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"?>
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>Command completed successfully</msg> S: <msg lang="en">Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <org:creData S: <org:creData
S: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> S: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
S: <org:id>res1523</org:id> S: <org:id>res1523</org:id>
S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate> S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate>
S: </org:creData> S: </org:creData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
skipping to change at page 19, line 32 skipping to change at page 19, line 32
S: </response> S: </response>
S:</epp> S:</epp>
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 a EPP command elements, the <delete> command MUST contain an
<org:delete> element that identifies the organization namespace. The <org:delete> element. This element or its ancestor element MUST
<org:delete> element MUST contain the following child element: identify the organization namespace. The <org:delete> element MUST
contain the following child element:
o A <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.
Example <delete> command: Example <delete> command:
skipping to change at page 20, line 27 skipping to change at page 20, line 27
When a <delete> command has been processed successfully, a server When a <delete> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element. MUST respond with an EPP response with no <resData> element.
Example <delete> response: Example <delete> 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>Command completed successfully</msg> S: <msg lang="en">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>
An EPP error response MUST be returned if a <delete> command cannot An EPP error response MUST be returned if a <delete> command cannot
be processed for any reason. be processed for any reason.
skipping to change at page 21, line 10 skipping to change at page 21, line 10
4.2.4. EPP <transfer> Command 4.2.4. EPP <transfer> Command
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 that identifies the organization MUST contain a <org:update> element. This element or its ancestor
namespace. The <org:update> element contains the following child element MUST identify the organization namespace. The <org:update>
elements: element contains the following child elements:
o A <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.
o An OPTIONAL <org:chg> element that contains attribute values to be o An OPTIONAL <org:chg> element that contains attribute values to be
changed. changed.
At least one <org:add>, <org:rem> or <org:chg> element MUST be At least one <org:add>, <org:rem> or <org:chg> element MUST be
provided if the command is not being extended. All of these elements provided if the command is not being extended. All of these elements
MAY be omitted if an <update> extension is present. The OPTIONAL MAY be omitted if an <update> extension is present. The OPTIONAL
<org:add> and <org:rem> elements contain the following child element: <org:add> and <org:rem> elements contain the following child
elements:
o Zero or more <org:contact> elements that contain the identifiers o Zero or more <org:contact> elements that contain the identifiers
for contact objects to be associated with or removed from the for contact objects to be associated with or removed from the
organization object. Contact object identifiers MUST be known to organization object. Contact object identifiers MUST be known to
the server before the contact object can be associated with the the server before the contact object can be associated with the
organization object. organization object.
o Zero or more <org:role> elements that contains the role type, role o Zero 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.
* A <org:type> element that contains the role type of the * An <org:type> element that contains the role type of the
organization, as defined in Section 3.2. The role type organization, as defined in Section 3.2. The role type
uniquely identifies the role to update. uniquely identifies the role to update.
* Zero or more <org:status> elements that contains 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 contains the operational o Zero or more <org:status> element 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
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,
element content MUST be represented in a subset of UTF-8 that can element content MUST be represented in a subset of Unicode in the
be represented in the 7-bit US-ASCII character set. If a range U+0020 - U+007E. If a localized form (type="loc") is
localized form (type="loc") is provided, element content MAY be provided, element content MAY be represented in unrestricted UTF-
represented in unrestricted UTF-8. The change of the postal info 8. The change of the postal info is defined as a replacement of
is defined as a replacement of that postal info element with the that postal info element with the contents of the sub-elements
contents of the sub-elements included in the update command. An included in the update command. An empty <org:postalInfo> element
empty <org:postalInfo> element is supported to allow a type of is supported to allow a type of postal info to be removed. The
postal info to be removed. The <org:postalInfo> element contains <org:postalInfo> element contains the following child elements:
the following child elements:
* A <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 OPTIONAL <org:street> elements that
contain the organization's street address. contain the organization's street address.
+ A <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.
+ A <org:cc> element that contains the organization's country + An <org:cc> element that contains the organization's country
code. code.
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.
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.
skipping to change at page 25, line 9 skipping to change at page 25, line 9
When an <update> command has been processed successfully, a server When an <update> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element. MUST respond with an EPP response with no <resData> element.
Example <update> response: Example <update> 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>Command completed successfully</msg> S: <msg lang="en">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>
An EPP error response MUST be returned if an <update> command cannot An EPP error response MUST be returned if an <update> command cannot
be processed for any reason. be processed for any reason.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
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 of the corresponding object MUST clearly reflect
processing of the pending action. The server MUST notify the client processing of the pending action. The server MUST notify the client
when offline processing of the action has been completed. 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>Command completed successfully; action pending</msg> S: <msg lang="en">Command completed successfully; action pending</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <org:creData S: <org:creData
S: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> S: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
S: <org:id>res1523</org:id> S: <org:id>res1523</org:id>
S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate> S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate>
S: </org:creData> S: </org:creData>
S: </resData> S: </resData>
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> either by queuing a service message for retrieval via the <poll>
command or by using an out-of-band mechanism to inform the client of command or by using an out-of-band mechanism to inform the client of
the request. the request.
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 that identifies the organization namespace. <org:panData> element. This element or its ancestor element MUST
The <org:panData> element contains the following child elements: identify the organization namespace. The <org:panData> element
contains the following child elements:
o A <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 A <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
original response to process the command. The client transaction original response to process the command. The client transaction
identifier is OPTIONAL and will only be returned if the client identifier is OPTIONAL and will only be returned if the client
provided an identifier with the original <create> command. provided an identifier with the original <create> command.
o A <org:paDate> element that contains the date and time describing o An <org:paDate> element that contains the date and time describing
when review of the requested action was completed. when review of the requested action was completed.
Example "review completed" service message: Example "review completed" service message:
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="1301"> S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg> S: <msg lang="en">Command completed successfully; ack to dequeue</msg>
S: </result> S: </result>
S: <msgQ count="5" id="12345"> S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate> S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Pending action completed successfully.</msg> S: <msg>Pending action completed successfully.</msg>
S: </msgQ> S: </msgQ>
S: <resData> S: <resData>
S: <org:panData S: <org:panData
S: xmlns:org="urn:ietf:params:xml:ns:org-1.0"> S: xmlns:org="urn:ietf:params:xml:ns:org-1.0">
S: <org:id paResult="1">res1523</org:id> S: <org:id paResult="1">res1523</org:id>
S: <org:paTRID> S: <org:paTRID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID> S: <svTRID>54321-XYZ</svTRID>
S: </org:paTRID> S: </org:paTRID>
S: <org:paDate>1999-04-04T22:00:00.0Z</org:paDate> S: <org:paDate>1999-04-04T22:00:00.0Z</org:paDate>
S: </org:panData> S: </org:panData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>BCD-23456</clTRID> S: <clTRID>BCD-23456</clTRID>
S: <svTRID>65432-WXY</svTRID> S: <svTRID>65432-WXY</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
5. Formal Syntax 5. Formal Syntax
An EPP object mapping is specified in XML Schema notation. The An EPP object mapping is specified in XML Schema notation. The
formal syntax presented here is a complete schema representation of formal syntax presented here is a complete schema representation of
the object mapping suitable for automated validation of EPP XML the object mapping suitable for automated validation of EPP XML
instances. The BEGIN and END tags are not part of the schema; they instances. The BEGIN and END tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI are used to note the beginning and ending of the schema for URI
registration purposes. registration purposes.
skipping to change at page 29, line 22 skipping to change at page 29, line 22
<enumeration value="linked"/> <enumeration value="linked"/>
<enumeration value="serverLinkProhibited"/> <enumeration value="serverLinkProhibited"/>
</restriction> </restriction>
</simpleType> </simpleType>
<complexType name="roleType"> <complexType name="roleType">
<sequence> <sequence>
<element name="type" type="token"/> <element name="type" type="token"/>
<element name="status" type="org:roleStatusType" <element name="status" type="org:roleStatusType"
minOccurs="0" maxOccurs="3"/> minOccurs="0" maxOccurs="3"/>
<element name="roleid" type="token" minOccurs="0"/> <element name="roleID" type="token" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="postalInfoType"> <complexType name="postalInfoType">
<sequence> <sequence>
<element name="name" <element name="name"
type="org:postalLineType"/> type="org:postalLineType"/>
<element name="addr" <element name="addr"
type="org:addrType" minOccurs="0"/> type="org:addrType" minOccurs="0"/>
</sequence> </sequence>
skipping to change at page 31, line 40 skipping to change at page 31, line 40
<!-- <!--
Child element of commands that accept multiple identifiers. Child element of commands that accept multiple identifiers.
--> -->
<complexType name="mIDType"> <complexType name="mIDType">
<sequence> <sequence>
<element name="id" <element name="id"
type="eppcom:clIDType" maxOccurs="unbounded"/> type="eppcom:clIDType" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
<!-- <!--
Pending action notification response elements. Pending action notification response elements.
--> -->
<complexType name="panDataType"> <complexType name="panDataType">
<sequence> <sequence>
<element name="id" type="org:paCLIDType"/> <element name="id" type="org:paCLIDType"/>
<element name="paTRID" type="epp:trIDType"/> <element name="paTRID" type="epp:trIDType"/>
<element name="paDate" type="dateTime"/> <element name="paDate" type="dateTime"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="paCLIDType"> <complexType name="paCLIDType">
skipping to change at page 34, line 39 skipping to change at page 34, line 39
<sequence> <sequence>
<element name="cd" type="org:checkType" <element name="cd" type="org:checkType"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
</sequence> </sequence>
</complexType> </complexType>
<complexType name="checkType"> <complexType name="checkType">
<sequence> <sequence>
<element name="id" type="org:checkIDType" /> <element name="id" type="org:checkIDType" />
<element name="reason" type="eppcom:reasonType" <element name="reason" type="eppcom:reasonType"
minOccurs="0" /> minOccurs="0" maxOccurs="5" />
</sequence> </sequence>
</complexType> </complexType>
<complexType name="checkIDType"> <complexType name="checkIDType">
<simpleContent> <simpleContent>
<extension base="eppcom:clIDType"> <extension base="eppcom:clIDType">
<attribute name="avail" type="boolean" <attribute name="avail" type="boolean"
use="required" /> use="required" />
</extension> </extension>
</simpleContent> </simpleContent>
skipping to change at page 36, line 16 skipping to change at page 36, line 16
End of schema. End of schema.
--> -->
</schema> </schema>
END END
6. Internationalization Considerations 6. 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 recognize representations including UTF-8. Conformant XML processors recognize
both UTF-8 and UTF-16. Though XML includes provisions to identify both UTF-8 [RFC3629] and UTF-16 [RFC2718]. Though XML includes
and use other character encodings through use of an "encoding" provisions to identify and use other character encodings through use
attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED. of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED.
As an extension of the EPP organization object mapping, the elements As an extension of the EPP organization object mapping, the elements
and element content described in this document MUST inherit the and element content described in this document MUST inherit the
internationalization conventions used to represent higher-layer internationalization conventions used to represent higher-layer
domain and core protocol structures present in an XML instance that domain and core protocol structures present in an XML instance that
includes this extension. includes this extension.
7. IANA Considerations 7. IANA Considerations
7.1. XML Namespace 7.1. XML Namespace
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. IANA is conforming to a registry mechanism described in [RFC3688]. IANA is
requested to assignment the following URI. requested to assignment the following URI.
Registration request for the organization namespace: Registration request for the organization namespace:
URI: urn:ietf:params:xml:ns:org-1.0 URI: urn:ietf:params:xml:ns:epp:org-1.0
Registrant Contact: IESG Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the organization XML schema: Registration request for the organization XML schema:
URI: urn:ietf:params:xml:ns:org-1.0 URI: urn:ietf:params:xml:schema:epp:org-1.0
Registrant Contact: IESG Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document. XML: See the "Formal Syntax" section of this document.
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:
skipping to change at page 37, line 26 skipping to change at page 37, line 26
TLDs: Any TLDs: Any
IPR Disclosure: None IPR Disclosure: None
Status: Active Status: Active
Notes: None Notes: None
7.3. Role Type Values Registry 7.3. Role Type Values Registry
The following values should be registered by the IANA in the "EPP IANA has created a new category of protocol registry for values of
Organization Role Values" registry. The registration policy for this the organization roles. The name of this registry is "EPP
registry is "Expert Review" [RFC8126]. Organization Role Values". The registration policy for this registry
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 Standards Track RFCs, state "IESG". For others,
give the name of the responsible party. give the name of the responsible party.
skipping to change at page 40, line 23 skipping to change at page 40, line 23
11. References 11. References
11.1. Normative References 11.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718,
DOI 10.17487/RFC2718, November 1999,
<https://www.rfc-editor.org/info/rfc2718>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
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>.
[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)
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/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,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-xml-20040204] [W3C.REC-xml-20040204]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third F. Yergeau, ""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., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
""XML Schema Part 1: Structures Second Edition", World ""XML Schema Part 1: Structures Second Edition", World
skipping to change at page 43, line 40 skipping to change at page 44, line 9
* Updated typos. * Updated typos.
* Added dns-operator in section 7.1. * Added dns-operator in section 7.1.
* Added "OPTIONAL" for <org:addr> * Added "OPTIONAL" for <org:addr>
Organization WG document-08: Organization WG document-08:
* Updated "Offline Review of Requested Actions". * Updated "Offline Review of Requested Actions".
Organization WG document-09:
* Updated "This element or its ancestor element MUST identify the
organization namespace." in section 4.1.1 and other parts of
this document.
* Updated text in section 2 match RFC 8174.
* Modified "roleid" to "roleID".
* Updated text about loops in section 3.6.
* Referred section 2.5 of RFC5733 for voice format.
* Updated XML schema for the maxOccurs value of "reason" element.
* Updated section 7.3.
* Replaced "http" with "https" in the examples.
* Updated writing typos.
* Modified XML namespace and schema.
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
Phone: +86 10 5881 2677
Email: zhoulinlin@cnnic.cn Email: zhoulinlin@cnnic.cn
Ning Kong
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3147 Ning Kong
Email: nkong@cnnic.cn Consultant
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
Phone: +86 10 5881 2692
Email: zhouguiqing@cnnic.cn Email: zhouguiqing@cnnic.cn
Xiaodong Lee Jiankang Yao
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: xl@cnnic.cn Email: yaojk@cnnic.cn
James Gould James Gould
Verisign, Inc. Verisign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US US
Email: jgould@verisign.com Email: jgould@verisign.com
 End of changes. 106 change blocks. 
213 lines changed or deleted 247 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/