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/