< draft-hollenbeck-epp-rfc3730bis-03.txt   draft-hollenbeck-epp-rfc3730bis-04.txt >
Network Working Group S. Hollenbeck Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Obsoletes: 3730 (if approved) September 19, 2006 Obsoletes: 3730 (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) Extensible Provisioning Protocol (EPP)
draft-hollenbeck-epp-rfc3730bis-03.txt draft-hollenbeck-epp-rfc3730bis-04.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 application layer client-server protocol This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared for the provisioning and management of objects stored in a shared
central repository. Specified in XML, the protocol defines generic central repository. Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps object management operations and an extensible framework that maps
protocol operations to objects. This document includes a protocol protocol operations to objects. This document includes a protocol
specification, an object mapping template, and an XML media type specification, an object mapping template, and an XML media type
registration. This document obsoletes RFC 3730 if approved. registration. This document obsoletes RFC 3730 if approved.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1. Conventions Used In This Document . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3
2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
2.1. Transport Mapping Considerations . . . . . . . . . . . . . 7 2.1. Transport Mapping Considerations . . . . . . . . . . . . . 7
2.2. Protocol Identification . . . . . . . . . . . . . . . . . 8 2.2. Protocol Identification . . . . . . . . . . . . . . . . . 8
2.3. Hello Format . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Hello Format . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Greeting Format . . . . . . . . . . . . . . . . . . . . . 8 2.4. Greeting Format . . . . . . . . . . . . . . . . . . . . . 8
2.5. Command Format . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Command Format . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Response Format . . . . . . . . . . . . . . . . . . . . . 13 2.6. Response Format . . . . . . . . . . . . . . . . . . . . . 13
2.7. Protocol Extension Framework . . . . . . . . . . . . . . . 18 2.7. Protocol Extension Framework . . . . . . . . . . . . . . . 18
2.7.1. Protocol Extension . . . . . . . . . . . . . . . . . . 18 2.7.1. Protocol Extension . . . . . . . . . . . . . . . . . . 18
2.7.2. Object Extension . . . . . . . . . . . . . . . . . . . 19 2.7.2. Object Extension . . . . . . . . . . . . . . . . . . . 18
2.7.3. Command-Response Extension . . . . . . . . . . . . . . 19 2.7.3. Command-Response Extension . . . . . . . . . . . . . . 19
2.8. Object Identification . . . . . . . . . . . . . . . . . . 20 2.8. Object Identification . . . . . . . . . . . . . . . . . . 20
2.9. Protocol Commands . . . . . . . . . . . . . . . . . . . . 21 2.9. Protocol Commands . . . . . . . . . . . . . . . . . . . . 21
2.9.1. Session Management Commands . . . . . . . . . . . . . 21 2.9.1. Session Management Commands . . . . . . . . . . . . . 21
2.9.1.1. EPP <login> Command . . . . . . . . . . . . . . . 21 2.9.1.1. EPP <login> Command . . . . . . . . . . . . . . . 21
2.9.1.2. EPP <logout> Command . . . . . . . . . . . . . . . 24 2.9.1.2. EPP <logout> Command . . . . . . . . . . . . . . . 24
2.9.2. Query Commands . . . . . . . . . . . . . . . . . . . . 25 2.9.2. Query Commands . . . . . . . . . . . . . . . . . . . . 25
2.9.2.1. EPP <check> Command . . . . . . . . . . . . . . . 25 2.9.2.1. EPP <check> Command . . . . . . . . . . . . . . . 25
2.9.2.2. EPP <info> Command . . . . . . . . . . . . . . . . 28 2.9.2.2. EPP <info> Command . . . . . . . . . . . . . . . . 27
2.9.2.3. EPP <poll> Command . . . . . . . . . . . . . . . . 29 2.9.2.3. EPP <poll> Command . . . . . . . . . . . . . . . . 28
2.9.2.4. EPP <transfer> Query Command . . . . . . . . . . . 34 2.9.2.4. EPP <transfer> Query Command . . . . . . . . . . . 32
2.9.3. Object Transform Commands . . . . . . . . . . . . . . 35 2.9.3. Object Transform Commands . . . . . . . . . . . . . . 34
2.9.3.1. EPP <create> Command . . . . . . . . . . . . . . . 36 2.9.3.1. EPP <create> Command . . . . . . . . . . . . . . . 34
2.9.3.2. EPP <delete> Command . . . . . . . . . . . . . . . 37 2.9.3.2. EPP <delete> Command . . . . . . . . . . . . . . . 36
2.9.3.3. EPP <renew> Command . . . . . . . . . . . . . . . 39 2.9.3.3. EPP <renew> Command . . . . . . . . . . . . . . . 37
2.9.3.4. EPP <transfer> Command . . . . . . . . . . . . . . 40 2.9.3.4. EPP <transfer> Command . . . . . . . . . . . . . . 39
2.9.3.5. EPP <update> Command . . . . . . . . . . . . . . . 43 2.9.3.5. EPP <update> Command . . . . . . . . . . . . . . . 41
3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . 45 3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 50 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1. Base Schema . . . . . . . . . . . . . . . . . . . . . . . 51 4.1. Base Schema . . . . . . . . . . . . . . . . . . . . . . . 48
4.2. Shared Structure Schema . . . . . . . . . . . . . . . . . 60 4.2. Shared Structure Schema . . . . . . . . . . . . . . . . . 58
5. Internationalization Considerations . . . . . . . . . . . . . 62 5. Internationalization Considerations . . . . . . . . . . . . . 60
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
7. Security Considerations . . . . . . . . . . . . . . . . . . . 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 61
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.1. Normative References . . . . . . . . . . . . . . . . . . . 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63
9.2. Informative References . . . . . . . . . . . . . . . . . . 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Object Mapping Template . . . . . . . . . . . . . . . 67 Appendix A. Object Mapping Template . . . . . . . . . . . . . . . 64
Appendix B. Media Type Registration: application/epp+xml . . . . 68 Appendix B. Media Type Registration: application/epp+xml . . . . 66
Appendix C. Changes from RFC 3730 . . . . . . . . . . . . . . . . 69 Appendix C. Changes from RFC 3730 . . . . . . . . . . . . . . . . 67
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 72 Intellectual Property and Copyright Statements . . . . . . . . . . 71
1. Introduction 1. Introduction
This document describes specifications for the Extensible This document describes specifications for the Extensible
Provisioning Protocol (EPP) version 1.0, an XML text protocol that Provisioning Protocol (EPP) version 1.0, an XML text protocol that
permits multiple service providers to perform object provisioning permits multiple service providers to perform object provisioning
operations using a shared central object repository. EPP is operations using a shared central object repository. EPP 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].
skipping to change at page 8, line 8 skipping to change at page 8, line 8
- The transport mapping MUST describe how an error in processing a - The transport mapping MUST describe how an error in processing a
command affects continued operation of the session. command affects continued operation of the session.
A transport mapping MUST explain how all of these requirements are A transport mapping MUST explain how all of these requirements are
met given the transport protocol being used to exchange data. met given the transport protocol being used to exchange data.
2.2. Protocol Identification 2.2. Protocol Identification
All EPP XML instances MUST begin with an <epp> element. This element All EPP XML instances MUST begin with an <epp> element. This element
identifies the start of an EPP protocol element, the namespace used identifies the start of an EPP protocol element and the namespace
within the protocol, and the location of the protocol schema. The used within the protocol. The <epp> start element and the associated
<epp> start element and the associated </epp> ending element MUST be </epp> ending element MUST be applied to all structures sent by both
applied to all structures sent by both clients and servers. clients and servers.
Example "start" and "end" EPP elements: Example "start" and "end" EPP elements:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd">
</epp> </epp>
2.3. Hello Format 2.3. Hello Format
EPP MAY be carried over both connection-oriented and connection-less EPP MAY be carried over both connection-oriented and connection-less
transport protocols. An EPP client MAY request a <greeting> from an transport protocols. An EPP client MAY request a <greeting> from an
EPP server at any time by sending a <hello> to a server. Use of this EPP server at any time by sending a <hello> to a server. Use of this
element is essential in a connection-less environment where a server element is essential in a connection-less environment where a server
can not return a <greeting> in response to a client-initiated can not return a <greeting> in response to a client-initiated
connection. An EPP <hello> MUST be an empty element with no child connection. An EPP <hello> MUST be an empty element with no child
elements. elements.
Example <hello>: Example <hello>:
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: <hello/> C: <hello/>
C:</epp> C:</epp>
2.4. Greeting Format 2.4. Greeting Format
An EPP server responds to a successful connection and <hello> element An EPP server responds to a successful connection and <hello> element
by returning a <greeting> element to the client. An EPP greeting by returning a <greeting> element to the client. An EPP greeting
contains the following elements: contains the following elements:
- An <svID> element that contains the name of the server. - An <svID> element that contains the name of the server.
skipping to change at page 12, line 8 skipping to change at page 12, line 8
- <relative/>: The policy is valid from the current date - <relative/>: The policy is valid from the current date
and time until the end of the specified duration. and time until the end of the specified duration.
Data collection policy elements are based on work described in the Data collection policy elements are based on work described in the
World Wide Web Consortium's Platform for Privacy Preferences World Wide Web Consortium's Platform for Privacy Preferences
[W3C.REC-P3P-20020416] specification. [W3C.REC-P3P-20020416] specification.
Example greeting: Example greeting:
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: <greeting> S: <greeting>
S: <svID>Example EPP server epp.example.com</svID> S: <svID>Example EPP server epp.example.com</svID>
S: <svDate>2000-06-08T22:00:00.0Z</svDate> S: <svDate>2000-06-08T22:00:00.0Z</svDate>
S: <svcMenu> S: <svcMenu>
S: <version>1.0</version> S: <version>1.0</version>
S: <lang>en</lang> S: <lang>en</lang>
S: <lang>fr</lang> S: <lang>fr</lang>
S: <objURI>urn:ietf:params:xml:ns:obj1</objURI> S: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj2</objURI> S: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj3</objURI> S: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
skipping to change at page 13, line 16 skipping to change at page 13, line 13
defined command extensions. defined command extensions.
- An OPTIONAL <clTRID> (client transaction identifier) element that - An OPTIONAL <clTRID> (client transaction identifier) element that
MAY be used to uniquely identify the command to the client. MAY be used to uniquely identify the command to the client.
Clients are responsible for maintaining their own transaction Clients are responsible for maintaining their own transaction
identifier space to ensure uniqueness. identifier space to ensure uniqueness.
Example command with object-specified child elements: Example command with object-specified child elements:
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: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <obj:name>example</obj:name> C: <obj:name>example</obj:name>
C: </obj:info> C: </obj:info>
C: </info> C: </info>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
2.6. Response Format 2.6. Response Format
An EPP server responds to a client command by returning a response to An EPP server responds to a client command by returning a response to
skipping to change at page 15, line 33 skipping to change at page 15, line 23
identifier) that is assigned by and unique to the server. identifier) that is assigned by and unique to the server.
Transaction identifiers provide command-response synchronization Transaction identifiers provide command-response synchronization
integrity. They SHOULD be logged, retained, and protected to ensure integrity. They SHOULD be logged, retained, and protected to ensure
that both the client and the server have consistent temporal and that both the client and the server have consistent temporal and
state management records. state management records.
Example response without <value> or <resData>: Example response without <value> or <resData>:
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 lang="en">Command completed successfully</msg> S: <msg lang="en">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>
Example response with <resData>: Example response with <resData>:
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: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:name>example</obj:name> S: <obj:name>example</obj:name>
S: </obj:creData> S: </obj: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>
Example response with error value elements: Example response with error value elements:
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="2004"> S: <result code="2004">
S: <msg>Parameter value range error</msg> S: <msg>Parameter value range error</msg>
S: <value xmlns:obj="urn:ietf:params:xml:ns:obj"> S: <value xmlns:obj="urn:ietf:params:xml:ns:obj">
S: <obj:elem1>2525</obj:elem1> S: <obj:elem1>2525</obj:elem1>
S: </value> S: </value>
S: </result> S: </result>
S: <result code="2005"> S: <result code="2005">
S: <msg>Parameter value syntax error</msg> S: <msg>Parameter value syntax error</msg>
S: <value xmlns:obj="urn:ietf:params:xml:ns:obj"> S: <value xmlns:obj="urn:ietf:params:xml:ns:obj">
skipping to change at page 18, line 4 skipping to change at page 17, line 33
S: </value> S: </value>
S: <reason>Invalid character found.</reason> S: <reason>Invalid character found.</reason>
S: </extValue> S: </extValue>
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>
Example response with notice of waiting server messages: Example response with notice of waiting server messages:
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: <msgQ count="5" id="12345"/> S: <msgQ count="5" id="12345"/>
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 18, line 46 skipping to change at page 18, line 25
elements identified using XML namespace notation with a reference to elements identified using XML namespace notation with a reference to
an XML schema that defines the namespace. The <epp> element that an XML schema that defines the namespace. The <epp> element that
identifies the beginning of a protocol instance includes multiple identifies the beginning of a protocol instance includes multiple
child element choices, one of which is an <extension> element whose child element choices, one of which is an <extension> element whose
children define the extension. For example, a protocol extension children define the extension. For example, a protocol extension
element would be described in generic terms as follows: element would be described in generic terms as follows:
C:<epp> C:<epp>
C: <extension> C: <extension>
C: <!-- One or more extension elements. --> C: <!-- One or more extension elements. -->
C: <ext:foo xmlns:ext="urn:ietf:params:xml:ns:ext" C: <ext:foo xmlns:ext="urn:ietf:params:xml:ns:ext">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:ext ext.xsd">
C: <!-- One or more extension child elements. --> C: <!-- One or more extension child elements. -->
C: </ext:foo> C: </ext:foo>
C: </extension> C: </extension>
C:</epp> C:</epp>
This document does not define mappings for specific extensions. This document does not define mappings for specific extensions.
Extension specifications MUST be described in separate documents that Extension specifications MUST be described in separate documents that
define the objects and operations subject to the extension. define the objects and operations subject to the extension.
2.7.2. Object Extension 2.7.2. Object Extension
EPP provides an extensible object management framework that defines EPP provides an extensible object management framework that defines
the syntax and semantics of protocol operations applied to a managed the syntax and semantics of protocol operations applied to a managed
object. This framework pushes the definition of each protocol object. This framework pushes the definition of each protocol
operation into the context of a specific object, providing the operation into the context of a specific object, providing the
skipping to change at page 19, line 25 skipping to change at page 19, line 6
base protocol. base protocol.
Protocol elements that contain data specific to objects are Protocol elements that contain data specific to objects are
identified using XML namespace notation with a reference to an XML identified using XML namespace notation with a reference to an XML
schema that defines the namespace. The schema for EPP supports use schema that defines the namespace. The schema for EPP supports use
of dynamic object schemas on a per-command and per-response basis. of dynamic object schemas on a per-command and per-response basis.
For example, the start of an object-specific command element would be For example, the start of an object-specific command element would be
described in generic terms as follows: described in generic terms as follows:
C:<EPPCommandName> C:<EPPCommandName>
C: <object:command xmlns:object="urn:ietf:params:xml:ns:object" C: <object:command xmlns:object="urn:ietf:params:xml:ns:object">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:object object.xsd">
C: <!-- One or more object-specific command elements. --> C: <!-- One or more object-specific command elements. -->
C: </object:command> C: </object:command>
C:</EPPCommandName> C:</EPPCommandName>
An object-specific response element would be described similarly: An object-specific response element would be described similarly:
S:<resData> S:<resData>
S: <object:resData xmlns:object="urn:ietf:params:xml:ns:object" S: <object:resData xmlns:object="urn:ietf:params:xml:ns:object">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:object object.xsd">
S: <!-- One or more object-specific response elements. --> S: <!-- One or more object-specific response elements. -->
S: </object:resData> S: </object:resData>
S:</resData> S:</resData>
This document does not define mappings for specific objects. The This document does not define mappings for specific objects. The
mapping of EPP to an object MUST be described in separate documents mapping of EPP to an object MUST be described in separate documents
that specifically address each command and response in the context of that specifically address each command and response in the context of
the object. A suggested object mapping outline is included as an the object. A suggested object mapping outline is included as an
appendix to this document. appendix to this document.
skipping to change at page 20, line 12 skipping to change at page 19, line 39
element that contains additional elements whose syntax and semantics element that contains additional elements whose syntax and semantics
are not explicitly defined by EPP or an EPP object mapping. This are not explicitly defined by EPP or an EPP object mapping. This
element is OPTIONAL. Extensions are typically defined by agreement element is OPTIONAL. Extensions are typically defined by agreement
between client and server and MAY be used to extend EPP for unique between client and server and MAY be used to extend EPP for unique
operational needs. A server-extended command element would be operational needs. A server-extended command element would be
described in generic terms as follows: described in generic terms as follows:
C:<command> C:<command>
C: <!-- EPPCommandName can be "create", "update", etc. --> C: <!-- EPPCommandName can be "create", "update", etc. -->
C: <EPPCommandName> C: <EPPCommandName>
C: <object:command xmlns:object="urn:ietf:params:xml:ns:object" C: <object:command xmlns:object="urn:ietf:params:xml:ns:object">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:object object.xsd">
C: <!-- One or more object-specific command elements. --> C: <!-- One or more object-specific command elements. -->
C: </object:command> C: </object:command>
C: </EPPCommandName> C: </EPPCommandName>
C: <extension> C: <extension>
C: <!-- One or more server-defined elements. --> C: <!-- One or more server-defined elements. -->
C: </extension> C: </extension>
C:</command> C:</command>
An server-extended response element would be described similarly: An server-extended response element would be described similarly:
skipping to change at page 23, line 8 skipping to change at page 23, line 8
password as part of a single plain text string. The EPP password as part of a single plain text string. The EPP
authentication mechanism is similar, though EPP does not require a authentication mechanism is similar, though EPP does not require a
session-level authorization identifier and the user identifier and session-level authorization identifier and the user identifier and
password are separated into distinct XML elements. Additional password are separated into distinct XML elements. Additional
identification and authorization schemes MUST be provided at other identification and authorization schemes MUST be provided at other
protocol layers to provide more robust security services. protocol layers to provide more robust security services.
Example <login> command: Example <login> 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: <login> C: <login>
C: <clID>ClientX</clID> C: <clID>ClientX</clID>
C: <pw>foo-BAR2</pw> C: <pw>foo-BAR2</pw>
C: <newPW>bar-FOO2</newPW> C: <newPW>bar-FOO2</newPW>
C: <options> C: <options>
C: <version>1.0</version> C: <version>1.0</version>
C: <lang>en</lang> C: <lang>en</lang>
C: </options> C: </options>
C: <svcs> C: <svcs>
skipping to change at page 24, line 8 skipping to change at page 23, line 39
C:</epp> C:</epp>
When a <login> command has been processed successfully, a server MUST When a <login> command has been processed successfully, a server MUST
respond with an EPP response with no <resData> element. If respond with an EPP response with no <resData> element. If
successful, the server will respond by creating and maintaining a new successful, the server will respond by creating and maintaining a new
session that SHOULD be terminated by a future <logout> command. session that SHOULD be terminated by a future <logout> command.
Example <login> response: Example <login> 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 25, line 8 skipping to change at page 24, line 25
client inactivity or session longevity are a matter of server policy client inactivity or session longevity are a matter of server policy
and are not specified by this protocol. and are not specified by this protocol.
Transport mappings MUST explicitly describe any connection-oriented Transport mappings MUST explicitly describe any connection-oriented
processing that takes place after processing a <logout> command and processing that takes place after processing a <logout> command and
ending a session. ending a session.
Example <logout> command: Example <logout> 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: <logout/> C: <logout/>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <logout> command has been processed successfully, a server When a <logout> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element. If MUST respond with an EPP response with no <resData> element. If
successful, the server MUST also end the current session. successful, the server MUST also end the current session.
Example <logout> response: Example <logout> 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="1500"> S: <result code="1500">
S: <msg>Command completed successfully; ending session</msg> S: <msg>Command completed successfully; ending session</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 26, line 18 skipping to change at page 25, line 31
extension framework. In addition to the standard EPP command extension framework. In addition to the standard EPP command
elements, the <check> command contains the following child elements: elements, the <check> command contains the following child elements:
- An object-specific <obj:check> element that identify the objects - An object-specific <obj:check> element that identify the objects
to be queried. Multiple objects of the same type MAY be queried to be queried. Multiple objects of the same type MAY be queried
within a single <check> command. within a single <check> command.
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: <obj:check xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:check xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <obj:name>example1</obj:name> C: <obj:name>example1</obj:name>
C: <obj:name>example2</obj:name> C: <obj:name>example2</obj:name>
C: <obj:name>example3</obj:name> C: <obj:name>example3</obj:name>
C: </obj:check> C: </obj:check>
C: </check> C: </check>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <check> command has been processed successfully, a server MUST When a <check> command has been processed successfully, a server MUST
respond with an EPP <resData> element that MUST contain a child respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace. The child elements of
object schema. The child elements of the <resData> element are the <resData> element are object-specific, though the EPP <resData>
object-specific, though the EPP <resData> element MUST contain a element MUST contain a child <obj:chkData> element that contains one
child <obj:chkData> element that contains one or more <obj:cd> (check or more <obj:cd> (check data) elements. Each <obj:cd> element
data) elements. Each <obj:cd> elements contains the following child contains the following child elements:
elements:
- An object-specific element that identifies the queried object. - An object-specific element that identifies the queried object.
This element MUST contain an "avail" attribute whose value This element MUST contain an "avail" attribute whose value
indicates object availability (can it be provisioned or not) at indicates object availability (can it be provisioned or not) at
the moment the <check> command was completed. A value of "1" or the moment the <check> command was completed. A value of "1" or
"true" means that the object can be provisioned. A value of "0" "true" means that the object can be provisioned. A value of "0"
or "false" means that the object can not be provisioned. or "false" means that the object can not be provisioned.
- An OPTIONAL <obj:reason> element that MAY be provided when an - An OPTIONAL <obj:reason> element that MAY be provided when an
object can not be provisioned. If present, this element contains object can not be provisioned. If present, this element contains
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: <obj:chkData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:chkData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:cd> S: <obj:cd>
S: <obj:name avail="1">example1</obj:name> S: <obj:name avail="1">example1</obj:name>
S: </obj:cd> S: </obj:cd>
S: <obj:cd> S: <obj:cd>
S: <obj:name avail="0">example2</obj:name> S: <obj:name avail="0">example2</obj:name>
S: <obj:reason>In use</obj:reason> S: <obj:reason>In use</obj:reason>
S: </obj:cd> S: </obj:cd>
S: <obj:cd> S: <obj:cd>
S: <obj:name avail="1">example3</obj:name> S: <obj:name avail="1">example3</obj:name>
S: </obj:cd> S: </obj:cd>
skipping to change at page 28, line 21 skipping to change at page 27, line 21
specified using the EPP extension framework. In addition to the specified using the EPP extension framework. In addition to the
standard EPP command elements, the <info> command contains the standard EPP command elements, the <info> command contains the
following child elements: following child elements:
- An object-specific <obj:info> element that identifies the object - An object-specific <obj:info> element that identifies the object
to be queried. to be queried.
Example <info> command: Example <info> 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: <info> C: <info>
C: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:info> C: </obj:info>
C: </info> C: </info>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When an <info> command has been processed successfully, a server MUST When an <info> command has been processed successfully, a server MUST
respond with an EPP <resData> element that MUST contain a child respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace and the Repository
object schema and the Repository Object Identifier (ROID) that was Object Identifier (ROID) that was assigned to the object when the
assigned to the object when the object was created. Other child object was created. Other child elements of the <resData> element
elements of the <resData> element are object-specific. are object-specific.
Example <info> response: Example <info> 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: <obj:infData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:infData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:roid>EXAMPLE1-REP</obj:roid> S: <obj:roid>EXAMPLE1-REP</obj:roid>
S: <!-- Object-specific elements. --> S: <!-- Object-specific elements. -->
S: </obj:infData> S: </obj:infData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12346</clTRID> S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
skipping to change at page 30, line 39 skipping to change at page 29, line 35
MUST be represented as an empty element with no child elements. An MUST be represented as an empty element with no child elements. An
"op" attribute with value "req" is REQUIRED to retrieve the first "op" attribute with value "req" is REQUIRED to retrieve the first
message from the server message queue. An "op" attribute (with value message from the server message queue. An "op" attribute (with value
"ack") and a "msgID" attribute (whose value corresponds to the value "ack") and a "msgID" attribute (whose value corresponds to the value
of the "id" attribute copied from the <msg> element in the message of the "id" attribute copied from the <msg> element in the message
being acknowledged) are REQUIRED to acknowledge receipt of a message. being acknowledged) are REQUIRED to acknowledge receipt of a message.
Example <poll> command: Example <poll> 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: <poll op="req"/> C: <poll op="req"/>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
The returned result code notes that a message has been dequeued and The returned result code notes that a message has been dequeued and
returned in response to a <poll> command. returned in response to a <poll> command.
Example <poll> response with object-specific information: Example <poll> response with object-specific information:
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>2000-06-08T22:00:00.0Z</qDate> S: <qDate>2000-06-08T22:00:00.0Z</qDate>
S: <msg>Transfer requested.</msg> S: <msg>Transfer requested.</msg>
S: </msgQ> S: </msgQ>
S: <resData> S: <resData>
S: <obj:trnData S: <obj:trnData
S: xmlns:obj="urn:ietf:params:xml:ns:obj-1.0" S: xmlns:obj="urn:ietf:params:xml:ns:obj-1.0">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj-1.0
S: obj-1.0.xsd">
S: <obj:name>example.com</obj:name> S: <obj:name>example.com</obj:name>
S: <obj:trStatus>pending</obj:trStatus> S: <obj:trStatus>pending</obj:trStatus>
S: <obj:reID>ClientX</obj:reID> S: <obj:reID>ClientX</obj:reID>
S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate> S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
S: <obj:acID>ClientY</obj:acID> S: <obj:acID>ClientY</obj:acID>
S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate> S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate> S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
S: </obj:trnData> S: </obj:trnData>
S: </resData> S: </resData>
S: <trID> S: <trID>
skipping to change at page 32, line 8 skipping to change at page 30, line 42
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
A client MUST acknowledge each response to dequeue the message and A client MUST acknowledge each response to dequeue the message and
make subsequent messages available for retrieval. make subsequent messages available for retrieval.
Example <poll> acknowledgement command: Example <poll> acknowledgement 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: <poll op="ack" msgID="12345"/> C: <poll op="ack" msgID="12345"/>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
A <poll> acknowledgement response notes the ID of the message that A <poll> acknowledgement response notes the ID of the message that
has been acknowledged and the number of messages remaining in the has been acknowledged and the number of messages remaining in the
queue. queue.
Example <poll> acknowledgement response: Example <poll> acknowledgement 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: <msgQ count="4" id="12345"/> S: <msgQ count="4" id="12345"/>
S: <trID> S: <trID>
S: <clTRID>ABC-12346</clTRID> S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
Service messages can also be returned without object information. Service messages can also be returned without object information.
Example <poll> response with mixed message content and without Example <poll> response with mixed message content and without
object-specific information: object-specific information:
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="4" id="12346"> S: <msgQ count="4" id="12346">
S: <qDate>2000-06-08T22:10:00.0Z</qDate> S: <qDate>2000-06-08T22:10:00.0Z</qDate>
S: <msg lang="en">Credit balance low. S: <msg lang="en">Credit balance low.
S: <limit>100</limit><bal>5</bal> S: <limit>100</limit><bal>5</bal>
S: </msg> S: </msg>
S: </msgQ> S: </msgQ>
skipping to change at page 33, line 36 skipping to change at page 32, line 8
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
The returned result code and message is used to note an empty server The returned result code and message is used to note an empty server
message queue. message queue.
Example <poll> response to note an empty message queue: Example <poll> response to note an empty message queue:
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="1300"> S: <result code="1300">
S: <msg>Command completed successfully; no messages</msg> S: <msg>Command completed successfully; no messages</msg>
S: </result> S: </result>
S: <trID> S: <trID>
S: <clTRID>ABC-12346</clTRID> S: <clTRID>ABC-12346</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 29 skipping to change at page 33, line 8
object whose transfer status is requested. object whose transfer status is requested.
Transfer status is typically considered sensitive information by the Transfer status is typically considered sensitive information by the
clients involved in the operation. Object mappings MUST provide clients involved in the operation. Object mappings MUST provide
features to restrict transfer queries to authorized clients, such as features to restrict transfer queries to authorized clients, such as
by requiring authorization information as part of the request. by requiring authorization information as part of the request.
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: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:transfer> C: </obj:transfer>
C: </transfer> C: </transfer>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <transfer> query command has been processed successfully, a When a <transfer> query command has been processed successfully, a
server MUST respond with an EPP <resData> element that MUST contain a server MUST respond with an EPP <resData> element that MUST contain a
child element that identifies the object namespace and the location child element that identifies the object namespace. The child
of the object schema. The child elements of the <resData> element elements of the <resData> element are object-specific, but they MUST
are object-specific, but they MUST include elements that identify the include elements that identify the object, the status of the
object, the status of the transfer, the identifier of the client that transfer, the identifier of the client that requested the transfer,
requested the transfer, the date and time that the request was made, the date and time that the request was made, the identifier of the
the identifier of the client that is authorized to act on the client that is authorized to act on the request, the date and time by
request, the date and time by which an action is expected, and an which an action is expected, and an OPTIONAL date and time noting
OPTIONAL date and time noting changes in the object's validity period changes in the object's validity period (if applicable) that occur as
(if applicable) that occur as a result of the transfer. a result of the transfer.
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: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:name>example</obj:name> S: <obj:name>example</obj:name>
S: <obj:trStatus>pending</obj:trStatus> S: <obj:trStatus>pending</obj:trStatus>
S: <obj:reID>ClientX</obj:reID> S: <obj:reID>ClientX</obj:reID>
S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate> S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
S: <obj:acID>ClientY</obj:acID> S: <obj:acID>ClientY</obj:acID>
S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate> S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate> S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
S: </obj:trnData> S: </obj:trnData>
S: </resData> S: </resData>
S: <trID> S: <trID>
skipping to change at page 36, line 28 skipping to change at page 35, line 20
standard EPP command elements, the <create> command contains the standard EPP command elements, the <create> command contains the
following child elements: following child elements:
- An object-specific <obj:create> element that identifies the object - An object-specific <obj:create> element that identifies the object
to be created and the elements that are required to create the to be created and the elements that are required to create the
object. object.
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: <obj:create xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:create xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:create> C: </obj: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, a server MAY When a <create> command has been processed successfully, a server MAY
respond with an EPP <resData> element that MUST contain a child respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace. The child elements of
object schema. The child elements of the <resData> element are the <resData> element are object-specific.
object-specific.
Example <create> response with <resData>: Example <create> response with <resData>:
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: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <!-- Object-specific elements. --> S: <!-- Object-specific elements. -->
S: </obj:creData> S: </obj: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>
skipping to change at page 38, line 8 skipping to change at page 37, line 8
using the EPP extension framework. In addition to the standard EPP using the EPP extension framework. In addition to the standard EPP
command elements, the <delete> command contains the following child command elements, the <delete> command contains the following child
elements: elements:
- An object-specific <obj:delete> element that identifies the object - An object-specific <obj:delete> element that identifies the object
to be deleted. to be deleted.
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: <obj:delete xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:delete xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:delete> C: </obj:delete>
C: </delete> C: </delete>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <delete> command has been processed successfully, a server MAY When a <delete> command has been processed successfully, a server MAY
respond with an EPP <resData> element that MUST contain a child respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace. The child elements of
object schema. The child elements of the <resData> element are the <resData> element are object-specific.
object-specific.
Example <delete> response without <resData>: Example <delete> response without <resData>:
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-12346</clTRID> S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
skipping to change at page 39, line 21 skipping to change at page 38, line 12
framework. In addition to the standard EPP command elements, the framework. In addition to the standard EPP command elements, the
<renew> command contains the following child elements: <renew> command contains the following child elements:
- An object-specific <obj:renew> element that identifies the object - An object-specific <obj:renew> element that identifies the object
to be renewed and the elements that are required to extend the to be renewed and the elements that are required to extend the
validity period of the object. validity period of the object.
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: <obj:renew xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:renew xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:renew> C: </obj:renew>
C: </renew> C: </renew>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <renew> command has been processed successfully, a server MAY When a <renew> command has been processed successfully, a server MAY
respond with an EPP <resData> element that MUST contain a child respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace. The child elements of
object schema. The child elements of the <resData> element are the <resData> element are object-specific.
object-specific.
Example <renew> response with <resData>: Example <renew> response with <resData>:
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: <obj:renData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:renData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <!-- Object-specific elements. --> S: <!-- Object-specific elements. -->
S: </obj:renData> S: </obj:renData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12346</clTRID> S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
skipping to change at page 42, line 8 skipping to change at page 40, line 15
to the standard EPP command elements, the <transfer> command contains to the standard EPP command elements, the <transfer> command contains
the following child elements: the following child elements:
- An object-specific <obj:transfer> element that identifies the - An object-specific <obj:transfer> element that identifies the
object to be transferred and the elements that are required to object to be transferred and the elements that are required to
process the transfer command. process the transfer command.
Example <transfer> command: Example <transfer> 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: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:transfer> C: </obj:transfer>
C: </transfer> C: </transfer>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When a <transfer> command has been processed successfully, a server When a <transfer> command has been processed successfully, a server
MUST respond with an EPP <resData> element that MUST contain a child MUST respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace. The child elements of
object schema. The child elements of the <resData> element are the <resData> element are object-specific, but they MUST include
object-specific, but they MUST include elements that identify the elements that identify the object, the status of the transfer, the
object, the status of the transfer, the identifier of the client that identifier of the client that requested the transfer, the date and
requested the transfer, the date and time that the request was made, time that the request was made, the identifier of the client that is
the identifier of the client that is authorized to act on the authorized to act on the request, the date and time by which an
request, the date and time by which an action is expected, and an action is expected, and an OPTIONAL date and time noting changes in
OPTIONAL date and time noting changes in the object's validity period the object's validity period (if applicable) that occur as a result
(if applicable) that occur as a result of the transfer. of the transfer.
Example <transfer> response with <resData>: Example <transfer> response with <resData>:
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: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj" S: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj">
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:name>example</obj:name> S: <obj:name>example</obj:name>
S: <obj:trStatus>pending</obj:trStatus> S: <obj:trStatus>pending</obj:trStatus>
S: <obj:reID>ClientX</obj:reID> S: <obj:reID>ClientX</obj:reID>
S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate> S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
S: <obj:acID>ClientY</obj:acID> S: <obj:acID>ClientY</obj:acID>
S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate> S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate> S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
S: </obj:trnData> S: </obj:trnData>
S: </resData> S: </resData>
S: <trID> S: <trID>
skipping to change at page 44, line 13 skipping to change at page 42, line 8
the following child elements: the following child elements:
- An object-specific <obj:update> element that identifies the object - An object-specific <obj:update> element that identifies the object
to be updated and the elements that are required to modify the to be updated and the elements that are required to modify the
object. Object-specific elements MUST identify values to be object. Object-specific elements MUST identify values to be
added, values to be removed, or values to be changed. added, values to be removed, or values to be changed.
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: <obj:update xmlns:obj="urn:ietf:params:xml:ns:obj" C: <obj:update xmlns:obj="urn:ietf:params:xml:ns:obj">
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. --> C: <!-- Object-specific elements. -->
C: </obj:update> C: </obj:update>
C: </update> C: </update>
C: <clTRID>ABC-12346</clTRID> C: <clTRID>ABC-12346</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
MAY respond with an EPP <resData> element that MUST contain a child MAY respond with an EPP <resData> element that MUST contain a child
element that identifies the object namespace and the location of the element that identifies the object namespace. The child elements of
object schema. The child elements of the <resData> element are the <resData> element are object-specific.
object-specific.
Example <update> response without <resData>: Example <update> response without <resData>:
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-12346</clTRID> S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
skipping to change at page 51, line 18 skipping to change at page 49, line 4
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:epp-1.0" <schema targetNamespace="urn:ietf:params:xml:ns:epp-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"/>
<annotation> <annotation>
<documentation> <documentation>
Extensible Provisioning Protocol v1.0 schema. Extensible Provisioning Protocol v1.0 schema.
</documentation> </documentation>
</annotation> </annotation>
<!-- <!--
Every EPP XML instance must begin with this element. Every EPP XML instance must begin with this element.
--> -->
skipping to change at page 63, line 10 skipping to change at page 60, line 43
but the actual text returned with a result MAY be provided in a but the actual text returned with a result MAY be provided in a
language negotiated when a session is established. Languages other language negotiated when a session is established. Languages other
than English MUST be noted through specification of a "lang" than English MUST be noted through specification of a "lang"
attribute for each message. Valid values for the "lang" attribute attribute for each message. Valid values for the "lang" attribute
and "lang" negotiation elements are described in [RFC3066]. and "lang" negotiation elements are described in [RFC3066].
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.
6. IANA Considerations 6. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. Four URI conforming to a registry mechanism described in [RFC3688]. Four URI
assignments have been registered by the IANA. assignments have been registered by the IANA.
Registration request for the EPP namespace: Registration request for the EPP namespace:
URI: urn:ietf:params:xml:ns:epp-1.0 URI: urn:ietf:params:xml:ns:epp-1.0
skipping to change at page 64, line 4 skipping to change at page 61, line 41
URI: urn:ietf:params:xml:ns:eppcom-1.0 URI: urn:ietf:params:xml:ns:eppcom-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the EPP shared structure XML schema: Registration request for the EPP shared structure XML schema:
URI: urn:ietf:params:xml:schema:eppcom-1.0 URI: urn:ietf:params:xml:schema:eppcom-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: See the "Shared Structure Schema" section of this document. XML: See the "Shared Structure Schema" section of this document.
7. Security Considerations 7. Security Considerations
EPP provides only simple client authentication services. A passive EPP provides only simple client authentication services. A passive
attack is sufficient to recover client identifiers and passwords, attack is sufficient to recover client identifiers and passwords,
allowing trivial command forgery. Protection against most common allowing trivial command forgery. Protection against most common
attacks and more robust security services MUST be provided by other attacks and more robust security services MUST be provided by other
protocol layers. Specifically, EPP instances MUST be protected using protocol layers. Specifically, EPP instances MUST be protected using
a transport mechanism or application protocol that provides integrity a transport mechanism or application protocol that provides
and confidentiality. integrity, confidentiality, and mutual strong client-server
authentication.
EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595]
to provide a simple application-layer authentication service that to provide a simple application-layer authentication service that
augments or supplements authentication and identification services augments or supplements authentication and identification services
that might be available at other protocol layers. Where the PLAIN that might be available at other protocol layers. Where the PLAIN
SASL mechanism specifies provision of an authorization identifier, SASL mechanism specifies provision of an authorization identifier,
authentication identifier, and password as a single string separated authentication identifier, and password as a single string separated
by ASCII NUL characters, EPP specifies use of a combined by ASCII NUL characters, EPP specifies use of a combined
authorization and authentication identifier and a password provided authorization and authentication identifier and a password provided
as distinct XML elements. as distinct XML elements.
skipping to change at page 64, line 43 skipping to change at page 62, line 34
an invalid password, or both an invalid client identifier and an an invalid password, or both an invalid client identifier and an
invalid password. invalid password.
EPP uses authentication information associated with objects to EPP uses authentication information associated with objects to
confirm object transfer authority. Authentication information confirm object transfer authority. Authentication information
exchanged between EPP clients and third party entities MUST be exchanged between EPP clients and third party entities MUST be
exchanged using a facility that provides privacy and integrity exchanged using a facility that provides privacy and integrity
services to protect against unintended disclosure and modification services to protect against unintended disclosure and modification
while in transit. while in transit.
EPP instances SHOULD be protected using a transport mechanism or
application protocol that provides anti-replay protection. EPP
provides some protection against replay attacks through command
idempotency and client-initiated transaction identification.
Consecutive command replays will not change the state of an object in
any way. There is, however, a chance of unintended or malicious
consequence if a command is replayed after intervening commands have
changed the object state and client identifiers are not used to
detect replays. For example, a replayed <create> command that
follows a <delete> command might succeed without additional
facilities to prevent or detect the replay.
8. Acknowledgements 8. Acknowledgements
This document was originally written as an individual submission This document was originally written as an individual submission
Internet-Draft. The provreg working group later adopted it as a Internet-Draft. The provreg working group later adopted it as a
working group document and provided many invaluable comments and working group document and provided many invaluable comments and
suggested improvements. The author wishes to acknowledge the efforts suggested improvements. The author wishes to acknowledge the efforts
of WG chairs Edward Lewis and Jaap Akkerhuis for their process and of WG chairs Edward Lewis and Jaap Akkerhuis for their process and
editorial contributions. editorial contributions.
Specific suggestions that have been incorporated into this document Specific suggestions that have been incorporated into this document
skipping to change at page 65, line 27 skipping to change at page 63, line 29
[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.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", RFC 3066, January 2001. Languages", RFC 3066, January 2001.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[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 66, line 34 skipping to change at page 64, line 30
10646", RFC 2781, February 2000. 10646", RFC 2781, February 2000.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001. RFC 3080, March 2001.
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol
Requirements", RFC 3375, September 2002. Requirements", RFC 3375, September 2002.
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 3730, March 2004. RFC 3730, March 2004.
[W3C.REC-P3P-20020416] [W3C.REC-P3P-20020416]
skipping to change at page 71, line 12 skipping to change at page 69, line 12
"A <poll> acknowledgement response notes the number of messages "A <poll> acknowledgement response notes the number of messages
remaining in the queue and the ID of the next message available remaining in the queue and the ID of the next message available
for retrieval." for retrieval."
to this: to this:
"A <poll> acknowledgement response notes the ID of the message "A <poll> acknowledgement response notes the ID of the message
that has been acknowledged and the number of messages remaining that has been acknowledged and the number of messages remaining
in the queue." in the queue."
Fixed the example to note the correct message ID. Fixed the example to note the correct message ID. This was done
because the msgID isn't needed to retrieve a message, only to
ack and dequeue it, so it doesn't need to be returned in the
response. Implementations are known to implement this feature
as updated.
8. Changed text in Section 2.9.3.4 from this: 8. Changed text in Section 2.9.3.4 from this:
"Once a transfer request has been received by the server, the "Once a transfer request has been received by the server, the
server MUST notify the current sponsoring client of the server MUST notify the current sponsoring client of the
requested transfer by queuing a service message for retrieval requested transfer by queuing a service message for retrieval
via the <poll> command." via the <poll> command."
to this: to this:
"Once a transfer request has been received by the server, the "Once a transfer request has been received by the server, the
server MUST notify the current sponsoring client of the server MUST notify the current sponsoring client of the
requested transfer by either queuing a service message for requested transfer by either queuing a service message for
retrieval via the <poll> command or by using an out-of-band retrieval via the <poll> command or by using an out-of-band
mechanism to inform the client of the request." mechanism to inform the client of the request."
9. Updated XML references. Updated reference from RFC 2279 to RFC 9. Updated Security Considerations to note implemented required
practices for authentication and replay protection.
10. Updated XML references. Updated reference from RFC 2279 to RFC
3629. 3629.
10. Moved RFCs 2781 and 3375 (Informational RFCs) from the normative 11. 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.
12. Moved RFCs 2781 and 3375 (Informational RFCs) from the normative
reference section to the informative reference section. reference section to the informative reference section.
13. Moved RFC 3023 from the normative reference section to the
informative reference section. This reference is used only in
an informative appendix.
14. Removed references to RFC 3339 and replaced them with references
to the W3C XML Schema specification.
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. 90 change blocks. 
279 lines changed or deleted 181 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/