| < draft-hollenbeck-rfc4931bis-00.txt | draft-hollenbeck-rfc4931bis-01.txt > | |||
|---|---|---|---|---|
| Network Working Group S. Hollenbeck | Network Working Group S. Hollenbeck | |||
| Internet-Draft VeriSign, Inc. | Internet-Draft VeriSign, Inc. | |||
| Obsoletes: 4931 (if approved) April 6, 2009 | Obsoletes: 4931 (if approved) May 14, 2009 | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: October 8, 2009 | Expires: November 15, 2009 | |||
| Extensible Provisioning Protocol (EPP) Domain Name Mapping | Extensible Provisioning Protocol (EPP) Domain Name Mapping | |||
| draft-hollenbeck-rfc4931bis-00 | draft-hollenbeck-rfc4931bis-01 | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on October 8, 2009. | This Internet-Draft will expire on November 15, 2009. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
| publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 4, line 35 ¶ | skipping to change at page 4, line 35 ¶ | |||
| contain an "ip" attribute to identify the IP address format. | contain an "ip" attribute to identify the IP address format. | |||
| Attribute value "v4" is used to note IPv4 address format. | Attribute value "v4" is used to note IPv4 address format. | |||
| Attribute value "v6" is used to note IPv6 address format. If the | Attribute value "v6" is used to note IPv6 address format. If the | |||
| "ip" attribute is not specified, "v4" is the default attribute | "ip" attribute is not specified, "v4" is the default attribute | |||
| value. IP address syntax requirements are described in Section | value. IP address syntax requirements are described in Section | |||
| 2.5 of the EPP host mapping [I-D.hollenbeck-rfc4932bis]. | 2.5 of the EPP host mapping [I-D.hollenbeck-rfc4932bis]. | |||
| Example host object name server elements for domain example.com: | Example host object name server elements for domain example.com: | |||
| <domain:ns> | <domain:ns> | |||
| <domain:hostObj>ns1.example.com</domain:hostObj> | ||||
| <domain:hostObj>ns1.example.net</domain:hostObj> | <domain:hostObj>ns1.example.net</domain:hostObj> | |||
| <domain:hostObj>ns2.example.net</domain:hostObj> | ||||
| </domain:ns> | </domain:ns> | |||
| Example host attribute name server elements for domain example.com: | Example host attribute name server elements for domain example.com: | |||
| <domain:ns> | <domain:ns> | |||
| <domain:hostAttr> | <domain:hostAttr> | |||
| <domain:hostName>ns1.example.com</domain:hostName> | <domain:hostName>ns1.example.net</domain:hostName> | |||
| <domain:hostAddr | <domain:hostAddr | |||
| ip="v4">192.0.2.2</domain:hostAddr> | ip="v4">192.0.2.2</domain:hostAddr> | |||
| <domain:hostAddr | <domain:hostAddr | |||
| ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr> | ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr> | |||
| </domain:hostAttr> | </domain:hostAttr> | |||
| <domain:hostAttr> | <domain:hostAttr> | |||
| <domain:hostName>ns1.example.net</domain:hostName> | <domain:hostName>ns2.example.net</domain:hostName> | |||
| </domain:hostAttr> | </domain:hostAttr> | |||
| </domain:ns> | </domain:ns> | |||
| 1.2. Conventions Used in This Document | 1.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 [RFC2119]. | |||
| In examples, "C:" represents lines sent by a protocol client and "S:" | In examples, "C:" represents lines sent by a protocol client and "S:" | |||
| skipping to change at page 7, line 13 ¶ | skipping to change at page 7, line 13 ¶ | |||
| Requests to transfer the object MUST be rejected. | Requests to transfer the object MUST be rejected. | |||
| - clientUpdateProhibited, serverUpdateProhibited | - clientUpdateProhibited, serverUpdateProhibited | |||
| Requests to update the object (other than to remove this status) | Requests to update the object (other than to remove this status) | |||
| MUST be rejected. | MUST be rejected. | |||
| - inactive | - inactive | |||
| Delegation information has not been associated with the object. | Delegation information has not been associated with the object. | |||
| This is the default status when a domain object is first created | ||||
| and there are no associated host objects for the DNS delegation. | ||||
| This status can also be set by the server when all host object | ||||
| associations are removed. | ||||
| - ok | - ok | |||
| This is the normal status value for an object that has no pending | This is the normal status value for an object that has no pending | |||
| operations or prohibitions. This value is set and removed by the | operations or prohibitions. This value is set and removed by the | |||
| server as other status values are added or removed. | server as other status values are added or removed. | |||
| - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, | - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, | |||
| pendingUpdate | pendingUpdate | |||
| skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 8 ¶ | |||
| describe resource records used for domain delegation and resolution. | describe resource records used for domain delegation and resolution. | |||
| Facilities to provision other domain-related resource record types | Facilities to provision other domain-related resource record types | |||
| can be developed by extending this mapping. | can be developed by extending this mapping. | |||
| The provisioning method described in this mapping separates discrete | The provisioning method described in this mapping separates discrete | |||
| data elements by data type. This method of data definition allows | data elements by data type. This method of data definition allows | |||
| XML Schema processors to perform basic syntax validation tasks, | XML Schema processors to perform basic syntax validation tasks, | |||
| reducing ambiguity and the amount of parsing and syntax-checking work | reducing ambiguity and the amount of parsing and syntax-checking work | |||
| required of protocol processors. Provisioning and extension methods | required of protocol processors. Provisioning and extension methods | |||
| that aggregate data into opaque strings are possible, but such | that aggregate data into opaque strings are possible, but such | |||
| methods SHOULD NOT be used because they impose additional parsing, | methods should not be used because they impose additional parsing, | |||
| interpretation, and validation requirements on protocol processors. | interpretation, and validation requirements on protocol processors. | |||
| 3. EPP Command Mapping | 3. EPP Command Mapping | |||
| A detailed description of the EPP syntax and semantics can be found | A detailed description of the EPP syntax and semantics can be found | |||
| in [I-D.hollenbeck-rfc4930bis]. The command mappings described here | in [I-D.hollenbeck-rfc4930bis]. The command mappings described here | |||
| are specifically for use in provisioning and managing Internet domain | are specifically for use in provisioning and managing Internet domain | |||
| names via EPP. | names via EPP. | |||
| 3.1. EPP Query Commands | 3.1. EPP Query Commands | |||
| skipping to change at page 19, line 9 ¶ | skipping to change at page 19, line 9 ¶ | |||
| time. Server operators MAY receive and process transform commands, | time. Server operators MAY receive and process transform commands, | |||
| but defer completing the requested action if human or third-party | but defer completing the requested action if human or third-party | |||
| review is required before the requested action can be completed. In | review is required before the requested action can be completed. In | |||
| such situations the server MUST return a 1001 response code to the | such situations the server MUST return a 1001 response code to the | |||
| client to note that the command has been received and processed, but | client to note that the command has been received and processed, but | |||
| the requested action is pending. The server MUST also manage the | the requested action is pending. The server MUST also manage the | |||
| status of the object that is the subject of the command to reflect | status of the object that is the subject of the command to reflect | |||
| the initiation and completion of the requested action. Once the | the initiation and completion of the requested action. Once the | |||
| action has been completed, all clients involved in the transaction | action has been completed, all clients involved in the transaction | |||
| MUST be notified using a service message that the action has been | MUST be notified using a service message that the action has been | |||
| completed and that the status of the object has changed. | completed and that the status of the object has changed. Other | |||
| notification methods MAY be used in addition to the required service | ||||
| message. | ||||
| Server operators SHOULD confirm that a client is authorized to | ||||
| perform a transform command on a given object. Any attempt to | ||||
| transform an object by an unauthorized client MUST be rejected, and | ||||
| the server MUST return a 2201 response code to the client to note | ||||
| that the client lacks privileges to execute the requested command. | ||||
| 3.2.1. EPP <create> Command | 3.2.1. EPP <create> Command | |||
| The EPP <create> command provides a transform operation that allows a | The EPP <create> command provides a transform operation that allows a | |||
| client to create a domain object. In addition to the standard EPP | client to create a domain object. In addition to the standard EPP | |||
| command elements, the <create> command MUST contain a <domain:create> | command elements, the <create> command MUST contain a <domain:create> | |||
| element that identifies the domain namespace. The <domain:create> | element that identifies the domain namespace. The <domain:create> | |||
| element contains the following child elements: | element contains the following child elements: | |||
| - A <domain:name> element that contains the fully qualified name of | - A <domain:name> element that contains the fully qualified name of | |||
| skipping to change at page 20, line 21 ¶ | skipping to change at page 20, line 27 ¶ | |||
| 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: <domain:create | C: <domain:create | |||
| C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> | C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> | |||
| C: <domain:name>example.com</domain:name> | C: <domain:name>example.com</domain:name> | |||
| C: <domain:period unit="y">2</domain:period> | C: <domain:period unit="y">2</domain:period> | |||
| C: <domain:ns> | C: <domain:ns> | |||
| C: <domain:hostObj>ns1.example.com</domain:hostObj> | ||||
| C: <domain:hostObj>ns1.example.net</domain:hostObj> | C: <domain:hostObj>ns1.example.net</domain:hostObj> | |||
| C: <domain:hostObj>ns2.example.net</domain:hostObj> | ||||
| C: </domain:ns> | C: </domain:ns> | |||
| C: <domain:registrant>jd1234</domain:registrant> | C: <domain:registrant>jd1234</domain:registrant> | |||
| C: <domain:contact type="admin">sh8013</domain:contact> | C: <domain:contact type="admin">sh8013</domain:contact> | |||
| C: <domain:contact type="tech">sh8013</domain:contact> | C: <domain:contact type="tech">sh8013</domain:contact> | |||
| C: <domain:authInfo> | C: <domain:authInfo> | |||
| C: <domain:pw>2fooBAR</domain:pw> | C: <domain:pw>2fooBAR</domain:pw> | |||
| C: </domain:authInfo> | C: </domain:authInfo> | |||
| C: </domain:create> | C: </domain:create> | |||
| C: </create> | C: </create> | |||
| C: <clTRID>ABC-12345</clTRID> | C: <clTRID>ABC-12345</clTRID> | |||
| skipping to change at page 43, line 11 ¶ | skipping to change at page 43, line 11 ¶ | |||
| Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer | Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer | |||
| El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick | El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick | |||
| Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson. | Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [I-D.hollenbeck-rfc4930bis] | [I-D.hollenbeck-rfc4930bis] | |||
| Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", | Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", | |||
| draft-hollenbeck-rfc4930bis-00 (work in progress), | draft-hollenbeck-rfc4930bis-01 (work in progress), | |||
| April 2009. | May 2009. | |||
| [I-D.hollenbeck-rfc4932bis] | [I-D.hollenbeck-rfc4932bis] | |||
| Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | |||
| Host Mapping", draft-hollenbeck-rfc4932bis-00 (work in | Host Mapping", draft-hollenbeck-rfc4932bis-01 (work in | |||
| progress), April 2009. | progress), May 2009. | |||
| [I-D.hollenbeck-rfc4933bis] | [I-D.hollenbeck-rfc4933bis] | |||
| Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | |||
| Contact Mapping", draft-hollenbeck-rfc4933bis-00 (work in | Contact Mapping", draft-hollenbeck-rfc4933bis-01 (work in | |||
| progress), April 2009. | progress), May 2009. | |||
| [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet | [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet | |||
| host table specification", RFC 952, October 1985. | host table specification", RFC 952, October 1985. | |||
| [RFC1123] Braden, R., "Requirements for Internet Hosts - Application | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application | |||
| and Support", STD 3, RFC 1123, October 1989. | and Support", STD 3, RFC 1123, October 1989. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
| January 2004. | January 2004. | |||
| [W3C.REC-xml-20040204] | [W3C.REC-xml-20040204] | |||
| Maler, E., Sperberg-McQueen, C., Paoli, J., Yergeau, F., | Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., | |||
| and T. Bray, "Extensible Markup Language (XML) 1.0 (Third | and T. Bray, "Extensible Markup Language (XML) 1.0 (Third | |||
| Edition)", World Wide Web Consortium FirstEdition REC-xml- | Edition)", World Wide Web Consortium FirstEdition REC-xml- | |||
| 20040204, February 2004, | 20040204, February 2004, | |||
| <http://www.w3.org/TR/2004/REC-xml-20040204>. | <http://www.w3.org/TR/2004/REC-xml-20040204>. | |||
| [W3C.REC-xmlschema-1-20041028] | [W3C.REC-xmlschema-1-20041028] | |||
| Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, | Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, | |||
| "XML Schema Part 1: Structures Second Edition", World Wide | "XML Schema Part 1: Structures Second Edition", World Wide | |||
| Web Consortium Recommendation REC-xmlschema-1-20041028, | Web Consortium Recommendation REC-xmlschema-1-20041028, | |||
| October 2004, | October 2004, | |||
| <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. | <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. | |||
| [W3C.REC-xmlschema-2-20041028] | [W3C.REC-xmlschema-2-20041028] | |||
| Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes | Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes | |||
| Second Edition", World Wide Web Consortium | Second Edition", World Wide Web Consortium | |||
| Recommendation REC-xmlschema-2-20041028, October 2004, | Recommendation REC-xmlschema-2-20041028, October 2004, | |||
| <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. | <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. | |||
| skipping to change at page 44, line 21 ¶ | skipping to change at page 44, line 21 ¶ | |||
| [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | |||
| "Internationalizing Domain Names in Applications (IDNA)", | "Internationalizing Domain Names in Applications (IDNA)", | |||
| RFC 3490, March 2003. | RFC 3490, March 2003. | |||
| [RFC4931] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | [RFC4931] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | |||
| Domain Name Mapping", RFC 4931, May 2007. | Domain Name Mapping", RFC 4931, May 2007. | |||
| Appendix A. Changes from RFC 4931 | Appendix A. Changes from RFC 4931 | |||
| 1. Changed "This document obsoletes RFC 3731" to "This document is | 1. Changed "This document obsoletes RFC 3731" to "This document is | |||
| intended to obsolete RFC 4931". | intended to obsolete RFC 4931". | |||
| 2. Replaced references to RFC 3731 with references to 4931. | 2. Replaced references to RFC 3731 with references to 4931. | |||
| 3. Replaced references to RFC 4930 with references to 4930bis. | 3. Replaced references to RFC 4930 with references to 4930bis. | |||
| 4. Replaced references to RFC 4932 with references to 4932bis. | 4. Replaced references to RFC 4932 with references to 4932bis. | |||
| 5. Replaced references to RFC 4933 with references to 4933bis. | 5. Replaced references to RFC 4933 with references to 4933bis. | |||
| 6. Updated description of inactive status in Section 2.3. | ||||
| 7. Fixed example host names in the Section 1.1 and Section 3.2.1 | ||||
| examples. | ||||
| 8. Changed "but such methods SHOULD NOT be used" to "but such | ||||
| methods should not be used" in Section 2.7. | ||||
| 9. Added "Other notification methods MAY be used in addition to the | ||||
| required service message" in Section 3.2. | ||||
| 10. Added 2201 response code text in Section 3.2. | ||||
| Author's Address | Author's Address | |||
| Scott Hollenbeck | Scott Hollenbeck | |||
| VeriSign, Inc. | VeriSign, Inc. | |||
| 21345 Ridgetop Circle | 21345 Ridgetop Circle | |||
| Dulles, VA 20166-6503 | Dulles, VA 20166-6503 | |||
| US | US | |||
| EMail: shollenbeck@verisign.com | EMail: shollenbeck@verisign.com | |||
| End of changes. 19 change blocks. | ||||
| 24 lines changed or deleted | 44 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||