draft-ietf-regext-org-10.txt   draft-ietf-regext-org-11.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: February 25, 2019 Consultant Expires: April 13, 2019 Consultant
G. Zhou G. Zhou
J. Yao J. Yao
CNNIC CNNIC
J. Gould J. Gould
Verisign, Inc. Verisign, Inc.
August 24, 2018 October 10, 2018
Extensible Provisioning Protocol (EPP) Organization Mapping Extensible Provisioning Protocol (EPP) Organization Mapping
draft-ietf-regext-org-10 draft-ietf-regext-org-11
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 February 25, 2019. This Internet-Draft will expire on April 13, 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 7, line 18 skipping to change at page 7, line 18
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. 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 should not have organization A
as its parent identifier. The same is true for larger loops as its parent identifier. The same is true for larger loops
involving three or more organizations. 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
skipping to change at page 15, line 33 skipping to change at page 15, line 33
such situations, the server MUST return a 1001 response code to the such situations, the server MUST return a 1001 response code to the
client to note that the command has been received and processed but client to note that the command has been received and processed but
that the requested action is pending. The server MUST also manage that the requested action is pending. The server MUST also manage
the status of the object that is the subject of the command to the status of the object that is the subject of the command to
reflect the initiation and completion of the requested action. Once reflect the initiation and completion of the requested action. Once
the action has been completed, the client MUST be notified using a the action has been completed, the client MUST be notified using a
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.
Server operators SHOULD confirm that a client is authorized to
perform a transform command on a given object. Any attempt to
transform an object by an unauthorized client MUST be rejected, and
the server MUST return a 2201 response code to the client to note
that the client lacks privileges to execute the requested command.
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. The <org:create> element
contains the following child elements: 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
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 lang="en">Command completed successfully; action pending</msg> S: <msg lang="en">Command completed successfully;
S: </result> S: action pending</msg>
S: <resData> S: </result>
S: <org:creData S: <resData>
S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0"> S: <org:creData
S: <org:id>res1523</org:id> S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate> S: <org:id>res1523</org:id>
S: </org:creData> S: <org:crDate>1999-04-03T22:00:00.0Z</org:crDate>
S: </resData> S: </org:creData>
S: <trID> S: </resData>
S: <clTRID>ABC-12345</clTRID> S: <trID>
S: <svTRID>54321-XYZ</svTRID> S: <clTRID>ABC-12345</clTRID>
S: </trID> S: <svTRID>54321-XYZ</svTRID>
S: </response> S: </trID>
S:</epp> S: </response>
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
skipping to change at page 27, line 10 skipping to change at page 27, line 10
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 An <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 lang="en">Command completed successfully; ack to dequeue</msg> S: <msg lang="en">Command completed successfully;
S: </result> S: ack to dequeue</msg>
S: <msgQ count="5" id="12345"> S: </result>
S: <qDate>1999-04-04T22:01:00.0Z</qDate> S: <msgQ count="5" id="12345">
S: <msg>Pending action completed successfully.</msg> S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: </msgQ> S: <msg>Pending action completed successfully.</msg>
S: <resData> S: </msgQ>
S: <org:panData S: <resData>
S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0"> S: <org:panData
S: <org:id paResult="1">res1523</org:id> S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
S: <org:paTRID> S: <org:id paResult="1">res1523</org:id>
S: <clTRID>ABC-12345</clTRID> S: <org:paTRID>
S: <svTRID>54321-XYZ</svTRID> S: <clTRID>ABC-12345</clTRID>
S: </org:paTRID> S: <svTRID>54321-XYZ</svTRID>
S: <org:paDate>1999-04-04T22:00:00.0Z</org:paDate> S: </org:paTRID>
S: </org:panData> S: <org:paDate>1999-04-04T22:00:00.0Z</org:paDate>
S: </resData> S: </org:panData>
S: <trID> S: </resData>
S: <clTRID>BCD-23456</clTRID> S: <trID>
S: <svTRID>65432-WXY</svTRID> S: <clTRID>BCD-23456</clTRID>
S: </trID> S: <svTRID>65432-WXY</svTRID>
S: </response> S: </trID>
S:</epp> S: </response>
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 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 [RFC3629] and UTF-16 [RFC2718]. Though XML includes both UTF-8 [RFC3629] and UTF-16 [RFC2781]. Though XML includes
provisions to identify and use other character encodings through use provisions to identify and use other character encodings through use
of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED. 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.
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 [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>.
[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,
skipping to change at page 41, line 36 skipping to change at page 41, line 27
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028", October 2004, REC-xmlschema-2-20041028", October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
11.2. Informative References 11.2. Informative References
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
<https://www.rfc-editor.org/info/rfc2781>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>. February 2015, <https://www.rfc-editor.org/info/rfc7451>.
Appendix A. Change Log Appendix A. Change Log
Initial -00: Individual document submitted. Initial -00: Individual document submitted.
-01: -01:
skipping to change at page 44, line 39 skipping to change at page 44, line 33
* Updated writing typos. * Updated writing typos.
* Modified XML namespace and schema. * Modified XML namespace and schema.
Organization WG document-10: Organization WG document-10:
* Modified XML namespace and schema. * Modified XML namespace and schema.
* Removed the maxOccurs value of "reason" element. * Removed the maxOccurs value of "reason" element.
Organization WG document-11:
* Typo of RFC2781 and moved this reference in "Informative
References".
* "Loops MUST be prohibited." in section 3.6.
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
 End of changes. 12 change blocks. 
63 lines changed or deleted 65 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/