< draft-hollenbeck-epp-rfc3731bis-04.txt   draft-hollenbeck-epp-rfc3731bis-05.txt >
Network Working Group S. Hollenbeck Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Obsoletes: 3731 (if approved) September 19, 2006 Obsoletes: 3731 (if approved) November 17, 2006
Intended status: Standards Track Intended status: Standards Track
Expires: March 23, 2007 Expires: May 21, 2007
Extensible Provisioning Protocol (EPP) Domain Name Mapping Extensible Provisioning Protocol (EPP) Domain Name Mapping
draft-hollenbeck-epp-rfc3731bis-04.txt draft-hollenbeck-epp-rfc3731bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 23, 2007. This Internet-Draft will expire on May 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
Abstract Abstract
This document describes an Extensible Provisioning Protocol (EPP) This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet domain names mapping for the provisioning and management of Internet domain names
stored in a shared central repository. Specified in XML, the mapping stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names. defines EPP command syntax and semantics as applied to domain names.
This document obsoletes RFC 3731 if approved. This document obsoletes RFC 3731 if approved.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.2. Contact and Client Identifiers . . . . . . . . . . . . . . 6 2.2. Contact and Client Identifiers . . . . . . . . . . . . . . 6
2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 8 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 8
2.5. Validity Periods . . . . . . . . . . . . . . . . . . . . . 8 2.5. Validity Periods . . . . . . . . . . . . . . . . . . . . . 8
2.6. Authorization Information . . . . . . . . . . . . . . . . 8 2.6. Authorization Information . . . . . . . . . . . . . . . . 8
2.7. Other DNS Resource Record Attributes . . . . . . . . . . . 8 2.7. Other DNS Resource Record Attributes . . . . . . . . . . . 8
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9 3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 11 3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 11
3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . . 17 3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . . 16
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 20 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 18
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 21 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 19
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 23 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 21
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 25 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 22
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 27 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 24
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 30 3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 26
3.3. Offline Review of Requested Actions . . . . . . . . . . . 33 3.3. Offline Review of Requested Actions . . . . . . . . . . . 29
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Internationalization Considerations . . . . . . . . . . . . . 45 5. Internationalization Considerations . . . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Normative References . . . . . . . . . . . . . . . . . . . 47 9.1. Normative References . . . . . . . . . . . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . . 48 9.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Changes from RFC 3731 . . . . . . . . . . . . . . . . 48 Appendix A. Changes from RFC 3731 . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 46
1. Introduction 1. Introduction
This document describes an Internet domain name mapping for version This document describes an Internet domain name mapping for version
1.0 of the Extensible Provisioning Protocol (EPP). This mapping is 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is
specified using the Extensible Markup Language (XML) 1.0 as described specified using the Extensible Markup Language (XML) 1.0 as described
in [W3C.REC-xml-20040204] and XML Schema notation as described in in [W3C.REC-xml-20040204] and XML Schema notation as described in
[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
This document obsoletes RFC 3731 [RFC3731] if approved. This document obsoletes RFC 3731 [RFC3731] if approved.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and
pendingUpdate status values MUST NOT be combined with each other. pendingUpdate status values MUST NOT be combined with each other.
Other status combinations not expressly prohibited MAY be used. Other status combinations not expressly prohibited MAY be used.
2.4. Dates and Times 2.4. 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
date-time form using upper case "T" and "Z" characters defined in date-time form using upper case "T" and "Z" characters defined in
[RFC3339] MUST be used to represent date-time values as XML Schema [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
does not support truncated date-time forms or lower case "T" and "Z" values as XML Schema does not support truncated date-time forms or
characters. lower case "T" and "Z" characters.
2.5. Validity Periods 2.5. Validity Periods
A domain name object MAY have a specified validity period. If server A domain name object MAY have a specified validity period. If server
policy supports domain object validity periods, the validity period policy supports domain object validity periods, the validity period
is defined when a domain object is created, and it MAY be extended by is defined when a domain object is created, and it MAY be extended by
the EPP <renew> or <transfer> commands. As a matter of server the EPP <renew> or <transfer> commands. As a matter of server
policy, this specification does not define actions to be taken upon policy, this specification does not define actions to be taken upon
expiration of a domain object's validity period. expiration of a domain object's validity period.
skipping to change at page 9, line 36 skipping to change at page 9, line 36
3.1.1. EPP <check> Command 3.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 a <domain:check> element that identifies the domain MUST contain a <domain:check> element that identifies the domain
namespace and the location of the domain schema. The <domain:check> namespace. The <domain:check> element contains the following child
element contains the following child elements: elements:
- One or more <domain:name> elements that contain the fully - One or more <domain:name> elements that contain the fully
qualified names of the domain objects to be queried. qualified names of the domain 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <check> C: <check>
C: <domain:check C: <domain:check
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:name>example.net</domain:name> C: <domain:name>example.net</domain:name>
C: <domain:name>example.org</domain:name> C: <domain:name>example.org</domain:name>
C: </domain:check> C: </domain: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 <domain:chkData> element that <resData> element MUST contain a child <domain:chkData> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. The <domain:chkData> element
schema. The <domain:chkData> element contains one or more contains one or more <domain:cd> elements that contain the following
<domain:cd> elements that contain the following child elements: child elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the queried domain object. This element MUST contain an "avail" the queried domain object. This element MUST contain an "avail"
attribute whose value indicates object availability (can it be attribute whose value indicates object availability (can it be
provisioned or not) at the moment the <check> command was provisioned or not) at the moment the <check> command was
completed. A value of "1" or "true" means that the object can be completed. A value of "1" or "true" means that the object can be
provisioned. A value of "0" or "false" means that the object can provisioned. A value of "0" or "false" means that the object can
not be provisioned. not be provisioned.
- An OPTIONAL <domain:reason> element that MAY be provided when an - An OPTIONAL <domain:reason> element that MAY be provided when an
skipping to change at page 11, line 8 skipping to change at page 11, line 8
server-specific text to help explain why the object can not be server-specific text to help explain why the object can not 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 MAY be present to identify the language if the
negotiated value is something other than the default value of "en" negotiated value is something other than the default value of "en"
(English). (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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:chkData S: <domain:chkData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:cd> S: <domain:cd>
S: <domain:name avail="1">example.com</domain:name> S: <domain:name avail="1">example.com</domain:name>
S: </domain:cd> S: </domain:cd>
S: <domain:cd> S: <domain:cd>
S: <domain:name avail="0">example.net</domain:name> S: <domain:name avail="0">example.net</domain:name>
S: <domain:reason>In use</domain:reason> S: <domain:reason>In use</domain:reason>
S: </domain:cd> S: </domain:cd>
S: <domain:cd> S: <domain:cd>
S: <domain:name avail="1">example.org</domain:name> S: <domain:name avail="1">example.org</domain:name>
S: </domain:cd> S: </domain:cd>
skipping to change at page 12, line 10 skipping to change at page 12, line 5
clients. If the querying client is the sponsoring client, all clients. If the querying client is the sponsoring client, all
available information MUST be returned. If the querying client is available information MUST be returned. If the querying client is
not the sponsoring client, but the client provides valid not the sponsoring client, but the client provides valid
authorization information, all available information MUST be authorization information, all available information MUST be
returned. If the querying client is not the sponsoring client, and returned. If the querying client is not the sponsoring client, and
the client does not provide valid authorization information, server the client does not provide valid authorization information, server
policy determines which OPTIONAL elements are returned. policy determines which OPTIONAL elements are returned.
In addition to the standard EPP command elements, the <info> command In addition to the standard EPP command elements, the <info> command
MUST contain a <domain:info> element that identifies the domain MUST contain a <domain:info> element that identifies the domain
namespace and the location of the domain schema. The <domain:info> namespace. The <domain:info> element contains the following child
element contains the following child elements: elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object to be queried. An OPTIONAL "hosts" attribute is the domain object to be queried. An OPTIONAL "hosts" attribute is
available to control return of information describing hosts available to control return of information describing hosts
related to the domain object. A value of "all" (the default, related to the domain object. A value of "all" (the default,
which MAY be absent) returns information describing both which MAY be absent) returns information describing both
subordinate and delegated hosts. A value of "del" returns subordinate and delegated hosts. A value of "del" returns
information describing only delegated hosts. A value of "sub" information describing only delegated hosts. A value of "sub"
returns information describing only subordinate hosts. A value of returns information describing only subordinate hosts. A value of
"none" returns no information describing delegated or subordinate "none" returns no information describing delegated or subordinate
skipping to change at page 13, line 8 skipping to change at page 12, line 33
identify the registrant or contact object if and only if the given identify the registrant or contact object if and only if the given
authInfo is associated with a registrant or contact object, and authInfo is associated with a registrant or contact object, and
not the domain object itself. If this element is not provided or not the domain object itself. If this element is not provided or
if the authorization information is invalid, server policy if the authorization information is invalid, server policy
determines if the command is rejected or if response information determines if the command is rejected or if response information
will be returned to the client. will be returned to the client.
Example <info> command without authorization information: Example <info> command without authorization information:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <info> C: <info>
C: <domain:info C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name hosts="all">example.com</domain:name> C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info> C: </domain:info>
C: </info> C: </info>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
Example <info> command with authorization information: Example <info> command with authorization information:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <info> C: <info>
C: <domain:info C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name hosts="all">example.com</domain:name> C: <domain:name hosts="all">example.com</domain:name>
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:info> C: </domain: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 <domain:infData> element that <resData> element MUST contain a child <domain:infData> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. Elements that are not OPTIONAL MUST
schema. Elements that are not OPTIONAL MUST be returned; OPTIONAL be returned; OPTIONAL elements are returned based on client
elements are returned based on client authorization and server authorization and server policy. The <domain:infData> element
policy. The <domain:infData> element contains the following child contains the following child elements:
elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object. the domain object.
- A <domain:roid> element that contains the Repository Object - A <domain:roid> element that contains the Repository Object
IDentifier assigned to the domain object when the object was IDentifier assigned to the domain object when the object was
created. created.
- Zero or more OPTIONAL <domain:status> elements that contain the - Zero or more OPTIONAL <domain:status> elements that contain the
current status descriptors associated with the domain. current status descriptors associated with the domain.
skipping to change at page 16, line 8 skipping to change at page 15, line 8
- An OPTIONAL <domain:authInfo> element that contains authorization - An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain object. This element MUST information associated with the domain object. This element MUST
only be returned if the querying client is the current sponsoring only be returned if the querying client is the current sponsoring
client, or if the client supplied valid authorization information client, or if the client supplied valid authorization information
with the command. with the command.
Example <info> response for an authorized client: Example <info> response for an authorized client:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:infData S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/> S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant> S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns> S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns1.example.net</domain:hostObj> S: <domain:hostObj>ns1.example.net</domain:hostObj>
S: </domain:ns> S: </domain:ns>
skipping to change at page 17, line 9 skipping to change at page 16, line 8
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
A server with a different information return policy MAY provide less A server with a different information return policy MAY provide less
information in a response. information in a response.
Example <info> response for an unauthorized client: Example <info> response for an unauthorized client:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:infData S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:clID>ClientX</domain:clID> S: <domain:clID>ClientX</domain:clID>
S: </domain:infData> S: </domain:infData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
skipping to change at page 17, line 44 skipping to change at page 16, line 38
An EPP error response MUST be returned if an <info> command can not An EPP error response MUST be returned if an <info> command can not
be processed for any reason. be processed for any reason.
3.1.3. EPP <transfer> Query Command 3.1.3. EPP <transfer> Query Command
The EPP <transfer> command provides a query operation that allows a The EPP <transfer> command provides a query operation that allows a
client to determine real-time status of pending and completed client to determine real-time status of pending and completed
transfer requests. In addition to the standard EPP command elements, transfer requests. In addition to the standard EPP command elements,
the <transfer> command MUST contain an "op" attribute with value the <transfer> command MUST contain an "op" attribute with value
"query", and a <domain:transfer> element that identifies the domain "query", and a <domain:transfer> element that identifies the domain
namespace and the location of the domain schema. The <domain: namespace. The <domain:transfer> element contains the following
transfer> element contains the following child elements: child elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object to be queried. the domain object to be queried.
- An OPTIONAL <domain:authInfo> element that contains authorization - An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain object or authorization information associated with the domain object or authorization
information associated with the domain object's registrant or information associated with the domain object's registrant or
associated contacts. An OPTIONAL "roid" attribute MUST be used to associated contacts. An OPTIONAL "roid" attribute MUST be used to
identify the registrant or contact object if and only if the given identify the registrant or contact object if and only if the given
authInfo is associated with a registrant or contact object, and authInfo is associated with a registrant or contact object, and
not the domain object itself. If this element is not provided or not the domain object itself. If this element is not provided or
if the authorization information is invalid, server policy if the authorization information is invalid, server policy
determines if the command is rejected or if response information determines if the command is rejected or if response information
will be returned to the client. will be returned to the client.
Example <transfer> query command: Example <transfer> query 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <transfer op="query"> C: <transfer op="query">
C: <domain:transfer C: <domain:transfer
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw> C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:transfer> C: </domain:transfer>
C: </transfer> C: </transfer>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <transfer> query command has been processed successfully, the When a <transfer> query command has been processed successfully, the
EPP <resData> element MUST contain a child <domain:trnData> element EPP <resData> element MUST contain a child <domain:trnData> element
that identifies the domain namespace and the location of the domain that identifies the domain namespace. The <domain:trnData> element
schema. The <domain:trnData> element contains the following child contains the following child elements:
elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object. the domain object.
- A <domain:trStatus> element that contains the state of the most - A <domain:trStatus> element that contains the state of the most
recent transfer request. recent transfer request.
- A <domain:reID> element that contains the identifier of the client - A <domain:reID> element that contains the identifier of the client
that requested the object transfer. that requested the object transfer.
skipping to change at page 20, line 8 skipping to change at page 18, line 12
For all other status types, the value identifies the date and time For all other status types, the value identifies the date and time
when the request was completed. when the request was completed.
- An OPTIONAL <domain:exDate> element that contains the end of the - An OPTIONAL <domain:exDate> element that contains the end of the
domain object's validity period if the <transfer> command caused domain object's validity period if the <transfer> command caused
or causes a change in the validity period. or causes a change in the validity period.
Example <transfer> query response: Example <transfer> query 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:trnData S: <domain:trnData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:trStatus>pending</domain:trStatus> S: <domain:trStatus>pending</domain:trStatus>
S: <domain:reID>ClientX</domain:reID> S: <domain:reID>ClientX</domain:reID>
S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate> S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>
S: <domain:acID>ClientY</domain:acID> S: <domain:acID>ClientY</domain:acID>
S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate> S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>
S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S: </domain:trnData> S: </domain:trnData>
S: </resData> S: </resData>
S: <trID> S: <trID>
skipping to change at page 21, line 17 skipping to change at page 19, line 16
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.
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 and the location of the element that identifies the domain namespace. The <domain:create>
domain schema. The <domain:create> element contains the following element contains the following child elements:
child elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object to be created. the domain object to be created.
- An OPTIONAL <domain:period> element that contains the initial - An OPTIONAL <domain:period> element that contains the initial
registration period of the domain object. A server MAY define a registration period of the domain object. A server MAY define a
default initial registration period if not specified by the default initial registration period if not specified by the
client. client.
- An OPTIONAL <domain:ns> element that contains the fully qualified - An OPTIONAL <domain:ns> element that contains the fully qualified
skipping to change at page 22, line 13 skipping to change at page 20, line 13
object. object.
- A <domain:authInfo> element that contains authorization - A <domain:authInfo> element that contains authorization
information to be associated with the domain object. This mapping information to be associated with the domain object. This mapping
includes a password-based authentication mechanism, but the schema includes a password-based authentication mechanism, but the schema
allows new mechanisms to be defined in new schemas. allows new mechanisms to be defined in new schemas.
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
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: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
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.com</domain:hostObj>
C: <domain:hostObj>ns1.example.net</domain:hostObj> C: <domain:hostObj>ns1.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>
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 <domain:creData> element that <resData> element MUST contain a child <domain:creData> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. The <domain:creData> element
schema. The <domain:creData> element contains the following child contains the following child elements:
elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object. the domain object.
- A <domain:crDate> element that contains the date and time of - A <domain:crDate> element that contains the date and time of
domain object creation. domain object creation.
- An OPTIONAL <domain:exDate> element that contains the date and - An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration time identifying the end of the domain object's registration
period. period.
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"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:creData S: <domain:creData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
S: </domain:creData> S: </domain:creData>
S: </resData> S: </resData>
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>
An EPP error response MUST be returned if a <create> command can not An EPP error response MUST be returned if a <create> command can not
be processed for any reason. be processed for any reason.
3.2.2. EPP <delete> Command 3.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 a domain object. In addition to the standard EPP client to delete a domain object. In addition to the standard EPP
command elements, the <delete> command MUST contain a <domain:delete> command elements, the <delete> command MUST contain a <domain:delete>
element that identifies the domain namespace and the location of the element that identifies the domain namespace. The <domain:delete>
domain schema. The <domain:delete> element contains the following element contains the following child elements:
child elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object to be deleted. the domain object to be deleted.
A domain object SHOULD NOT be deleted if subordinate host objects are A domain object SHOULD NOT be deleted if subordinate host objects are
associated with the domain object. For example, if domain associated with the domain object. For example, if domain
"example.com" exists, and host object "ns1.example.com" also exists, "example.com" exists, and host object "ns1.example.com" also exists,
then domain "example.com" SHOULD NOT be deleted until host then domain "example.com" SHOULD NOT be deleted until host
"ns1.example.com" has been either deleted or renamed to exist in a "ns1.example.com" has been either deleted or renamed to exist in a
different superordinate domain. A server SHOULD notify clients that different superordinate domain. A server SHOULD notify clients that
object relationships exist by sending a 2305 error response code when object relationships exist by sending a 2305 error response code when
a <delete> command is attempted and fails due to existing object a <delete> command is attempted and fails due to existing object
relationships. Delegated and subordinate host objects associated relationships. Delegated and subordinate host objects associated
with a domain object can be determined using the <info> query command with a domain object can be determined using the <info> query command
for the domain object. for the domain object.
Example <delete> command: Example <delete> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <delete> C: <delete>
C: <domain:delete C: <domain:delete
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: </domain:delete> C: </domain:delete>
C: </delete> C: </delete>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <delete> command has been processed successfully, a server When a <delete> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element. MUST respond with an EPP response with no <resData> element.
Example <delete> response: Example <delete> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
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>
An EPP error response MUST be returned if a <delete> command can not An EPP error response MUST be returned if a <delete> command can not
be processed for any reason. be processed for any reason.
3.2.3. EPP <renew> Command 3.2.3. EPP <renew> Command
The EPP <renew> command provides a transform operation that allows a The EPP <renew> command provides a transform operation that allows a
client to extend the validity period of a domain object. In addition client to extend the validity period of a domain object. In addition
to the standard EPP command elements, the <renew> command MUST to the standard EPP command elements, the <renew> command MUST
contain a <domain:renew> element that identifies the domain namespace contain a <domain:renew> element that identifies the domain
and the location of the domain schema. The <domain:renew> element namespace. The <domain:renew> element contains the following child
contains the following child elements: elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object whose validity period is to be extended. the domain object whose validity period is to be extended.
- A <domain:curExpDate> element that contains the date on which the - A <domain:curExpDate> element that contains the date on which the
current validity period ends. This value ensures that repeated current validity period ends. This value ensures that repeated
<renew> commands do not result in multiple unanticipated <renew> commands do not result in multiple unanticipated
successful renewals. successful renewals.
- An OPTIONAL <domain:period> element that contains the number of - An OPTIONAL <domain:period> element that contains the number of
units to be added to the registration period of the domain object. units to be added to the registration period of the domain object.
The number of units available MAY be subject to limits imposed by The number of units available MAY be subject to limits imposed by
the server. the server.
Example <renew> command: Example <renew> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <renew> C: <renew>
C: <domain:renew C: <domain:renew
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:curExpDate>2000-04-03</domain:curExpDate> C: <domain:curExpDate>2000-04-03</domain:curExpDate>
C: <domain:period unit="y">5</domain:period> C: <domain:period unit="y">5</domain:period>
C: </domain:renew> C: </domain:renew>
C: </renew> C: </renew>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <renew> command has been processed successfully, the EPP When a <renew> command has been processed successfully, the EPP
<resData> element MUST contain a child <domain:renData> element that <resData> element MUST contain a child <domain:renData> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. The <domain:renData> element
schema. The <domain:renData> element contains the following child contains the following child elements:
elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object. the domain object.
- An OPTIONAL <domain:exDate> element that contains the date and - An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration time identifying the end of the domain object's registration
period. period.
Example <renew> response: Example <renew> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:renData S: <domain:renData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: </domain:renData> S: </domain:renData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
An EPP error response MUST be returned if a <renew> command can not An EPP error response MUST be returned if a <renew> command can not
be processed for any reason. be processed for any reason.
3.2.4. EPP <transfer> Command 3.2.4. EPP <transfer> Command
The EPP <transfer> command provides a transform operation that allows The EPP <transfer> command provides a transform operation that allows
a client to manage requests to transfer the sponsorship of a domain a client to manage requests to transfer the sponsorship of a domain
object. In addition to the standard EPP command elements, the object. In addition to the standard EPP command elements, the
<transfer> command MUST contain a <domain:transfer> element that <transfer> command MUST contain a <domain:transfer> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. The <domain:transfer> element
schema. The <domain:transfer> element contains the following child contains the following child elements:
elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object for which a transfer request is to be created, the domain object for which a transfer request is to be created,
approved, rejected, or cancelled. approved, rejected, or cancelled.
- An OPTIONAL <domain:period> element that contains the number of - An OPTIONAL <domain:period> element that contains the number of
units to be added to the registration period of the domain object units to be added to the registration period of the domain object
at completion of the transfer process. This element can only be at completion of the transfer process. This element can only be
used when a transfer is requested, and it MUST be ignored if used used when a transfer is requested, and it MUST be ignored if used
otherwise. The number of units available MAY be subject to limits otherwise. The number of units available MAY be subject to limits
skipping to change at page 29, line 8 skipping to change at page 25, line 29
that are subordinate to the domain object. For example, if domain that are subordinate to the domain object. For example, if domain
object "example.com" is transferred and host object "ns1.example.com" object "example.com" is transferred and host object "ns1.example.com"
exists, the host object MUST be transferred as part of the exists, the host object MUST be transferred as part of the
"example.com" transfer process. Host objects that are subject to "example.com" transfer process. Host objects that are subject to
transfer when transferring a domain object are listed in the response transfer when transferring a domain object are listed in the response
to an EPP <info> command performed on the domain object. to an EPP <info> command performed on the domain object.
Example <transfer> request command: Example <transfer> request 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <transfer op="request"> C: <transfer op="request">
C: <domain:transfer C: <domain:transfer
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">1</domain:period> C: <domain:period unit="y">1</domain:period>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw> C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:transfer> C: </domain:transfer>
C: </transfer> C: </transfer>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <transfer> command has been processed successfully, the EPP When a <transfer> command has been processed successfully, the EPP
<resData> element MUST contain a child <domain:trnData> element that <resData> element MUST contain a child <domain:trnData> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. The <domain:trnData> element
schema. The <domain:trnData> element contains the same child contains the same child elements defined for a transfer query
elements defined for a transfer query response. response.
Example <transfer> response: Example <transfer> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1001"> S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg> S: <msg>Command completed successfully; action pending</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:trnData S: <domain:trnData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:trStatus>pending</domain:trStatus> S: <domain:trStatus>pending</domain:trStatus>
S: <domain:reID>ClientX</domain:reID> S: <domain:reID>ClientX</domain:reID>
S: <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate> S: <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>
S: <domain:acID>ClientY</domain:acID> S: <domain:acID>ClientY</domain:acID>
S: <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate> S: <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S: </domain:trnData> S: </domain:trnData>
S: </resData> S: </resData>
S: <trID> S: <trID>
skipping to change at page 30, line 45 skipping to change at page 26, line 40
S:</epp> S:</epp>
An EPP error response MUST be returned if a <transfer> command can An EPP error response MUST be returned if a <transfer> command can
not be processed for any reason. not be processed for any reason.
3.2.5. EPP <update> Command 3.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 a domain object. In addition to client to modify the attributes of a domain object. In addition to
the standard EPP command elements, the <update> command MUST contain the standard EPP command elements, the <update> command MUST contain
a <domain:update> element that identifies the domain namespace and a <domain:update> element that identifies the domain namespace. The
the location of the domain schema. The <domain:update> element <domain:update> element contains the following child elements:
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
the domain object to be updated. the domain object to be updated.
- An OPTIONAL <domain:add> element that contains attribute values to - An OPTIONAL <domain:add> element that contains attribute values to
be added to the object. be added to the object.
- An OPTIONAL <domain:rem> element that contains attribute values to - An OPTIONAL <domain:rem> element that contains attribute values to
be removed from the object. be removed from the object.
skipping to change at page 32, line 15 skipping to change at page 28, line 9
- A <domain:authInfo> element that contains authorization - A <domain:authInfo> element that contains authorization
information associated with the domain object. This mapping information associated with the domain object. This mapping
includes a password-based authentication mechanism, but the schema includes a password-based authentication mechanism, but the schema
allows new mechanisms to be defined in new schemas. A <domain: allows new mechanisms to be defined in new schemas. A <domain:
null> element can be used within the <domain:authInfo> element to null> element can be used within the <domain:authInfo> element to
remove authorization information. remove authorization information.
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command> C: <command>
C: <update> C: <update>
C: <domain:update C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:add> C: <domain:add>
C: <domain:ns> C: <domain:ns>
C: <domain:hostObj>ns2.example.com</domain:hostObj> C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns> C: </domain:ns>
C: <domain:contact type="tech">mak21</domain:contact> C: <domain:contact type="tech">mak21</domain:contact>
C: <domain:status s="clientHold" C: <domain:status s="clientHold"
C: lang="en">Payment overdue.</domain:status> C: lang="en">Payment overdue.</domain:status>
C: </domain:add> C: </domain:add>
C: <domain:rem> C: <domain:rem>
skipping to change at page 33, line 4 skipping to change at page 28, line 41
C: <domain:registrant>sh8013</domain:registrant> C: <domain:registrant>sh8013</domain:registrant>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>2BARfoo</domain:pw> C: <domain:pw>2BARfoo</domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:chg> C: </domain:chg>
C: </domain:update> C: </domain:update>
C: </update> C: </update>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When an <update> command has been processed successfully, a server When an <update> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element. MUST respond with an EPP response with no <resData> element.
Example <update> response: Example <update> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
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>
skipping to change at page 34, line 6 skipping to change at page 30, line 6
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1001"> S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg> S: <msg>Command completed successfully; action pending</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:creData S: <domain:creData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
S: </domain:creData> S: </domain:creData>
S: </resData> S: </resData>
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>
skipping to change at page 34, line 41 skipping to change at page 30, line 36
The status of the domain object after returning this response MUST The status of the domain object after returning this response MUST
include "pendingCreate". The server operator reviews the request include "pendingCreate". The server operator reviews the request
offline, and informs the client of the outcome of the review by offline, and informs the client of the outcome of the review by
either queuing a service message for retrieval via the <poll> command either queuing a service message for retrieval via the <poll> command
or by using an out-of-band mechanism to inform the client of the or by using an out-of-band mechanism to inform the client of the
request. request.
The service message MUST contain text in the <response>, <msgQ>, The service message MUST contain text in the <response>, <msgQ>,
<msg> element that describes the notification. In addition, the EPP <msg> element that describes the notification. In addition, the EPP
<resData> element MUST contain a child <domain:panData> element that <resData> element MUST contain a child <domain:panData> element that
identifies the domain namespace and the location of the domain identifies the domain namespace. The <domain:panData> element
schema. The <domain:panData> element contains the following child contains the following child elements:
elements:
- A <domain:name> element that contains the fully qualified name of - A <domain:name> element that contains the fully qualified name of
the domain object. The <domain:name> element contains a REQUIRED the domain object. The <domain:name> 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.
- A <domain:paTRID> element that contains the client transaction - A <domain:paTRID> element that contains the client transaction
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.
- A <domain:paDate> element that contains the date and time - A <domain:paDate> element that contains the date and time
describing when review of the requested action was completed. describing 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response> S: <response>
S: <result code="1301"> S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg> S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result> S: </result>
S: <msgQ count="5" id="12345"> S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate> S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Pending action completed successfully.</msg> S: <msg>Pending action completed successfully.</msg>
S: </msgQ> S: </msgQ>
S: <resData> S: <resData>
S: <domain:panData S: <domain:panData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name paResult="1">example.com</domain:name> S: <domain:name paResult="1">example.com</domain:name>
S: <domain:paTRID> S: <domain:paTRID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID> S: <svTRID>54321-XYZ</svTRID>
S: </domain:paTRID> S: </domain:paTRID>
S: <domain:paDate>1999-04-04T22:00:00.0Z</domain:paDate> S: <domain:paDate>1999-04-04T22:00:00.0Z</domain:paDate>
S: </domain:panData> S: </domain:panData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>BCD-23456</clTRID> S: <clTRID>BCD-23456</clTRID>
skipping to change at page 36, line 24 skipping to change at page 32, line 13
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:host="urn:ietf:params:xml:ns:host-1.0" xmlns:host="urn:ietf:params:xml:ns:host-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<!-- <!--
Import common element types. Import common element types.
--> -->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
schemaLocation="eppcom-1.0.xsd"/> <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0" <import namespace="urn:ietf:params:xml:ns:host-1.0"/>
schemaLocation="epp-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:host-1.0"
schemaLocation="host-1.0.xsd"/>
<annotation> <annotation>
<documentation> <documentation>
Extensible Provisioning Protocol v1.0 Extensible Provisioning Protocol v1.0
domain provisioning schema. domain provisioning schema.
</documentation> </documentation>
</annotation> </annotation>
<!-- <!--
Child elements found in EPP commands. Child elements found in EPP commands.
skipping to change at page 45, line 29 skipping to change at page 41, line 20
both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to
identify and use other character encodings through use of an identify and use other character encodings through use of an
"encoding" attribute in an <?xml?> declaration, use of UTF-8 is "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED in environments where parser encoding support RECOMMENDED in environments where parser encoding support
incompatibility exists. incompatibility exists.
All date-time values presented via EPP MUST be expressed in Universal All date-time values presented via EPP MUST be expressed in Universal
Coordinated Time using the Gregorian calendar. XML Schema allows use Coordinated Time using the Gregorian calendar. XML Schema allows use
of time zone identifiers to indicate offsets from the zero meridian, of time zone identifiers to indicate offsets from the zero meridian,
but this option MUST NOT be used with EPP. The extended date-time but this option MUST NOT be used with EPP. The extended date-time
form using upper case "T" and "Z" characters defined in [RFC3339] form using upper case "T" and "Z" characters defined in
MUST be used to represent date-time values as XML Schema does not [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
support truncated date-time forms or lower case "T" and "Z" values as XML Schema does not support truncated date-time forms or
characters. lower case "T" and "Z" characters.
This document requires domain and host name syntax as specified in This document requires domain and host name syntax as specified in
[RFC0952] as updated by [RFC1123]. At the time of this writing, RFC [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC
3490 [RFC3490] describes a standard to use certain ASCII name labels 3490 [RFC3490] describes a standard to use certain ASCII name labels
to represent non-ASCII name labels. These conformance requirements to represent non-ASCII name labels. These conformance requirements
might change as a result of progressing work in developing standards might change as a result of progressing work in developing standards
for internationalized domain names. for internationalized domain names.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 47, line 11 skipping to change at page 42, line 46
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-epp-rfc3730bis] [I-D.hollenbeck-epp-rfc3730bis]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
draft-hollenbeck-epp-rfc3730bis-03 (work in progress), draft-hollenbeck-epp-rfc3730bis-04 (work in progress),
September 2006. November 2006.
[I-D.hollenbeck-epp-rfc3732bis] [I-D.hollenbeck-epp-rfc3732bis]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", draft-hollenbeck-epp-rfc3732bis-03 (work in Host Mapping", draft-hollenbeck-epp-rfc3732bis-04 (work in
progress), September 2006. progress), November 2006.
[I-D.hollenbeck-epp-rfc3733bis] [I-D.hollenbeck-epp-rfc3733bis]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", draft-hollenbeck-epp-rfc3733bis-04 (work Contact Mapping", draft-hollenbeck-epp-rfc3733bis-05 (work
in progress), September 2006. in progress), November 2006.
[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.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[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., Bray, T., Yergeau, F., Sperberg-McQueen, C., Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., and
and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20040204, February 2004, xml-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., Beech, D., Mendelsohn, N., and M. Maloney, Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn,
"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]
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 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 49, line 20 skipping to change at page 45, line 5
client of the outcome of the review by queuing a service message client of the outcome of the review by queuing a service message
for retrieval via the <poll> command." for retrieval via the <poll> command."
to this: to this:
"The server operator reviews the request offline, and informs the "The server operator reviews the request offline, and informs the
client of the outcome of the review by either queuing a service client of the outcome of the review by either queuing a service
message for retrieval via the <poll> command or by using an out- message for retrieval via the <poll> command or by using an out-
of-band mechanism to inform the client of the request." of-band mechanism to inform the client of the request."
7. Updated EPP and XML references. 7. Removed text describing use of the XML Schema schemaLocation
attribute. This is an optional attribute that doesn't need to be
mandated for use in EPP.
8. Removed references to RFC 3339 and replaced them with references
to the W3C XML Schema specification.
9. Updated EPP and XML references.
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 75 change blocks. 
235 lines changed or deleted 131 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/