| < draft-hollenbeck-rfc4932bis-00.txt | draft-hollenbeck-rfc4932bis-01.txt > | |||
|---|---|---|---|---|
| Network Working Group S. Hollenbeck | Network Working Group S. Hollenbeck | |||
| Internet-Draft VeriSign, Inc. | Internet-Draft VeriSign, Inc. | |||
| Obsoletes: 4932 (if approved) April 6, 2009 | Obsoletes: 4932 (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) Host Mapping | Extensible Provisioning Protocol (EPP) Host Mapping | |||
| draft-hollenbeck-rfc4932bis-00 | draft-hollenbeck-rfc4932bis-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 12, line 16 ¶ | skipping to change at page 12, line 16 ¶ | |||
| 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 host object. In addition to the standard EPP | client to create a host object. In addition to the standard EPP | |||
| command elements, the <create> command MUST contain a <host:create> | command elements, the <create> command MUST contain a <host:create> | |||
| element that identifies the host namespace. The <host:create> | element that identifies the host namespace. The <host:create> | |||
| element contains the following child elements: | element contains the following child elements: | |||
| - A <host:name> element that contains the fully qualified name of | - A <host:name> element that contains the fully qualified name of | |||
| skipping to change at page 28, line 11 ¶ | skipping to change at page 28, line 11 ¶ | |||
| were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony | were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony | |||
| Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, | Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, | |||
| Patrick Mevzek, and Rick Wesson. | Patrick Mevzek, 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. | |||
| [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| September 1981. | September 1981. | |||
| [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. | |||
| [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
| STD 13, RFC 1034, November 1987. | STD 13, RFC 1034, November 1987. | |||
| skipping to change at page 28, line 39 ¶ | skipping to change at page 28, line 39 ¶ | |||
| [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. | |||
| [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
| Architecture", RFC 4291, February 2006. | Architecture", RFC 4291, February 2006. | |||
| [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 29, line 38 ¶ | skipping to change at page 29, line 38 ¶ | |||
| Appendix A. Changes from RFC 4932 | Appendix A. Changes from RFC 4932 | |||
| 1. Changed "This document obsoletes RFC 3732" to "This document is | 1. Changed "This document obsoletes RFC 3732" to "This document is | |||
| intended to obsolete RFC 4932". | intended to obsolete RFC 4932". | |||
| 2. Replaced references to RFC 1886 with references to 3596. | 2. Replaced references to RFC 1886 with references to 3596. | |||
| 3. Removed references to RFC 3152 since both it and 1886 have been | 3. Removed references to RFC 3152 since both it and 1886 have been | |||
| obsoleted by 3596. | obsoleted by 3596. | |||
| 4. Replaced references to RFC 3732 with references to 4932. | 4. Replaced references to RFC 3732 with references to 4932. | |||
| 5. Replaced references to RFC 4930 with references to 4930bis. | 5. Replaced references to RFC 4930 with references to 4930bis. | |||
| 6. Added "Other notification methods MAY be used in addition to the | ||||
| required service message" in Section 3.2. | ||||
| 7. 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. 9 change blocks. | ||||
| 9 lines changed or deleted | 20 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/ | ||||