< 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/