Application and TMCH drafts
Chris Wright <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <8CEF048B9EC83748B1517DC64EA130FB76DCB1A5AA@off-win2003-01.ausregistrygroup.local> |
All, Attached are the alternative drafts mentioned earlier. These drafts take a different approach to the Verisign draft, however it does pull together concepts from other documents, and previous feedback we have given to Verisign on their draft which has been incorporated (that is why there are similarities). Separating TMCH from launch activities is the first difference. Decoupling these, separation of concerns, is good software engineering practice. By separating the TMCH, and other 'data' from the actual application, this promotes the most reuse of the application draft - it allows the launch (application) draft to be used by registries that do not require TMCH integration (ccTLDs, IDN ccTLDs etc), or require different trademark field, for example, to the ones described in the Verisign draft. Features of the Application draft: * Application draft allows for submission of applications for domain names either during a sunrise, land rush or other periods * Applications can be used for sunrise, land-rush and even release of reserved names after go-live, during general availability * Application check command can be used to check availability of names during an application period (allows releases of sets of names during general availability) - this could be the launch of new IDN languages or release of previously held back names etc * We improve the use of status values by making them specific about what actions can and can't be taken, so that clients of not require external knowledge about the 'meaning' behind a particular 'state' which may also vary between registries, thus complicating Registrars lives further * Does not dictate phase requirements, allowing registries to decide own business models for launch * Does not mandate data that is to be passed with applications (like trademark data or other information)- different extensions should be used for describing data to be sent with applications, data that is sent with applications may be the same data that is to be sent with domain creates for example, the TMCH draft is an example of a draft that defines data that is to be sent with an application (or could also be sent with a domain create for someone running a first come, first server sunrise and thus not requiring 'applications' at all) - most registries already implement a 'key-value-pair' extension of sorts to facilitate the transfer of arbitrary data (from the protocol perspective) Features of the TMCH draft: * TMCH is isolated draft and doesn't tie supporting of applications to support of TMCH - this enables TMCH data to be passed with just a domain create command or a domain create that uses the application extension as well, allowing first come first servers, or applications, or any other thing that a registry may dream up - the TMCH is not coupled to an domain 'application process' * TMCH draft defines base64 transport for SMD only, reducing options, thus simplifying implementation - this allows the format of the SMD to be locked down independent of the this draft, and addresses issues with XML signature validation - it also allows non XML format SMDs to be used if deemed required (given TMCH specification is not locked down yet) We feel these documents are smaller, simplified and, in our opinion, easier to understand. Please note we are submitting these drafts through IETF processes at the moment. Thanks [cid:[email protected]] Chris Wright Chief Technology Officer ARI REGISTRY SERVICES Melbourne | Los Angeles P +61 3 9866 3710 M +61 401 873 798 E [email protected]<mailto:[email protected]> W www.ariservices.com<http://www.ariservices.com/> ARI Registry Services is an evolution of AusRegistry International. Follow us on Twitter<http://twitter.com/#!/ausregistryint> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg
image001.png
(image/png, 3.7 KB) - not displayed
draft-rbp-application-epp-mapping-01.txt
(text/plain, 28.9 KB)
Internet Engineering Task Force J. Mitchell
Internet-Draft C. Wright
Intended status: Informational ARI Registry Services
Expires: June 4, 2013 December 2012
Domain Name Application Extension Mapping for the Extensible
Provisioning Protocol (EPP)
draft-rbp-application-epp-mapping-01
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of applications
for domain names, suitable for periods such as a sunrise or landrush
during which servers do not offer first-come first-served
registrations.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Mitchell & Wright Expires June 4, 2013 [Page 1]
Internet-Draft EPP Domain Application Mapping December 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Application Identifier . . . . . . . . . . . . . . . . . . 3
2.2. Phase Identifier . . . . . . . . . . . . . . . . . . . . . 4
2.3. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Domain Attributes . . . . . . . . . . . . . . . . . . . . 6
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 6
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 6
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 7
3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 9
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 10
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 10
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 12
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 13
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 13
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 13
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Mitchell & Wright Expires June 4, 2013 [Page 2]
Internet-Draft EPP Domain Application Mapping December 2012
1. Introduction
The EPP Domain Name Mapping [RFC5731] describes mechanisms for the
provisioning and management of domain names. This works well for
domain name registries that use a first-come first-served allocation
method, however registries may define periods during which multiple
applications for a domain name are accepted.
This extension describes the commands and responses used for the
manipulation of domain name application objects. The authors
recognise that additional information is often required to support
applications for domain names, including but not limited to trademark
information or proof of eligibility. This extension does not provide
mechanisms for the collection of this information, instead other
documents should be published that describe the mechanisms for
transport and validation of supporting information.
Extension to the domain name mapping was preferred over re-defining
the domain object fields in a domain name application object mapping.
Implementers should be aware that this document places restrictions
on the use of certain domain object attributes for the period during
which the application is relevant.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
"application-1.0" is used as an abbreviation for
"urn:rbp:params:xml:ns:application-1.0". The XML namespace prefix
"app" is used, but implementations MUST NOT depend on it and instead
employ a proper namespace-aware XML parser and serializer to
interpret and output the XML documents.
2. Object Attributes
An application for a domain name results in an object EPP Domain Name
Mapping [RFC5731]. Those new elements, belonging exclusively to the
application, are described here, as well as the restrictions placed
on the information available in the domain object.
2.1. Application Identifier
Servers may allow multiple applications of a given domain name during
relevant registry-specific phases. On receiving a request to create
a domain name, the server creates an application object corresponding
Mitchell & Wright Expires June 4, 2013 [Page 3]
Internet-Draft EPP Domain Application Mapping December 2012
to the request, and assigns a unique application identifier. In
order to facilitate correlation, all subsequent operations on the
application object MUST be qualified by the previously assigned
application identifier.
Servers MAY use both the application identifier and domain name to
uniquely identify an application. Clients MUST ensure that commands
to query or transform an application, include the domain name and
application identifier associated with the original <create> command
and response.
Application identifiers SHOULD NOT be composed of characters that
cannot be represented in US-ASCII, and SHOULD NOT exceed the length
of a ROID. Servers SHOULD NOT allocate application identifiers that
differ only in the casing of the letters.
Clients MUST NOT assume any particular identifier syntax, and should
be able to handle identifiers consisting of numbers, letters and
punctuation.
2.2. Phase Identifier
The server may support multiple rounds of applications, either
sequentially or simultaneously, each with their own participation
requirements.
Clients are expected to know the relevant phase identifier in use for
a particular server. Out of band mechanisms should be used to
determine the available phases and the requirements for submission of
an application during those phases.
This document reserves the following two names for their specific
uses. Registries SHOULD accept these values during the relevant
phase to promote interoperability.
o tmch-sunrise - the phase where sunrise codes authorized by the
trademark clearinghouse are used to prove eligibility. This
refers to the least restrictive phase should two or more phases
use sunrise codes from the trademark clearinghouse.
o landrush - the phase immediately prior to first-come first-served
having no restrictions in addition to normal registration
policies.
Phase identifiers SHOULD NOT be composed of characters that cannot be
represented in US-ASCII, and SHOULD NOT exceed the length of a ROID.
Servers SHOULD NOT allocate phase identifiers that differ only in the
casing of the letters.
Mitchell & Wright Expires June 4, 2013 [Page 4]
Internet-Draft EPP Domain Application Mapping December 2012
Clients MUST NOT assume any particular identifier syntax, and should
be able to handle identifiers consisting of numbers, letters and
punctuation.
2.3. Status
All applications follow a predefined lifecycle as defined by the
server. This extension defines the following status values that
servers may use to represent the actions available to the client for
respective states.
o ok - This is the normal status value for an object that has no
pending operations or prohibitions.
o pendingAllocation - The application is pending allocation or
contention resolution. All operations are allowed unless the
relevant statuses are set by the server.
o pendingValidation - The application is pending non-mechanical
validation. All operations are allowed unless the relevant
statuses are set by the server.
o deleteProhibited - Requests to delete the application MUST be
rejected.
o updateAuthInfoProhibited - Requests to modify the authInfo MUST be
rejected.
o updateContactProhibited - Requests to modify the domain contacts
(admin, billing, tech) MUST be rejected. Requests to modify the
registrant contact are allowed.
o updateDelegationProhibited - Requests to modify delegation
information for the domain MUST be rejected. This includes name
server and DNSSEC material.
o updateRegistrantProhibited - Requests to modify the domain
registrant MUST be rejected. Requests to modify the other
contacts (admin, billing, tech) are allowed.
o updateOtherProhibited - Servers may require mechanisms to notify
clients of the restriction on updating additional data not covered
by this document. Servers should include text as a child of the
status element, describing the attributes that may not be
modified.
Mitchell & Wright Expires June 4, 2013 [Page 5]
Internet-Draft EPP Domain Application Mapping December 2012
2.4. Domain Attributes
An application must not have subordinate host objects. Host objects
may be registered following the allocation of the domain object.
The domain object must not have creation, update, expiration, or
transfer dates. The domain creation date will be set upon
allocation, of the application and the expiration date will be set
upon a multiple of periods from the aforementioned creation date.
The domain object will not have a last updated or transferred date.
The domain object must not have creating or updating client
information.
The domain object will have no status information. The application
status describes the state of the application until registration of
the domain object. Servers MAY provide the pendingCreate status,
however clients MUST NOT depend on it being included in response to
the <info> command.
3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730]. The command
mappings described here are specifically for use in the Domain Name
Application Extension.
3.1. EPP Query Commands
EPP provides three commands to retrieve object information: <check>
to determine if an object is known to the server, <info> to retrieve
detailed information associated with an object, and <transfer> to
retrieve object transfer status information.
3.1.1. EPP <check> Command
This extension defines additional elements for the EPP <check>
command described in the EPP Domain Name Mapping [RFC5731]. No
additional elements are defined for the EPP <check> response.
The EPP <check> command is used to determine if an object can be
provisioned within a repository. Domain names may be made available
only in unique application phases, whilst remaining unavailable for
registration in concurrent application or registration phases. In
addition to the elements expressed in the <domain:check>, the command
is extended with an <app:check> element that contains the following
child elements:
Mitchell & Wright Expires June 4, 2013 [Page 6]
Internet-Draft EPP Domain Application Mapping December 2012
o phase: the identifier of the phase to which domain name
availability should be determined.
Example <check> Command for an Application Phase
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<check>
<check xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>xn--somename.tld</name>
<name>xn--anothername.tld</name>
<name>abc.tld</name>
</check>
</check>
<extension>
<check xmlns="urn:rbp:params:xml:ns:application-1.0">
<phase>new-IDN-table-release</phase>
</check>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
3.1.2. EPP <info> Command
This extension defines additional elements for the EPP <info> command
and response described in the EPP Domain Name Mapping [RFC5731].
The EPP <info> command is used to retrieve information on an
application for a domain name. The application identifier returned
in the create response (Section 3.2.1) is used for retrieving
information for a launch application. In addition to the elements
expressed in the <domain:info>, the command is extended with an <app:
info> element that contains the following child elements:
o id - the identifier of the application
Mitchell & Wright Expires June 4, 2013 [Page 7]
Internet-Draft EPP Domain Application Mapping December 2012
Example <info> Command that identifies a specific Application
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<info xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
</info>
</info>
<extension>
<info xmlns="urn:rbp:params:xml:ns:application-1.0">
<id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
</info>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
When an <info> command has been successfully processed, the <resData>
element contains the <domain:infData> as described in RFC 5731,
however with restrictions on elements as described in the Domain
Attributes (Section 2.4) section. In addition, the response is
extended with an <app:infData> element containing the following child
elements (Note that <app:infData> element MAY be returned by a server
for a domain object that was created as the result of a successful
application as well):
o One <id> element containing the application identifier.
o One <phase> element containing the phase in which the application
is submitted.
o One or more <status> elements describing the status of the
application.
o One <crDate> element that contains the date of application
creation.
o One optional <upDate> element that contains the date and time of
the most recent application modification.
Mitchell & Wright Expires June 4, 2013 [Page 8]
Internet-Draft EPP Domain Application Mapping December 2012
Example <info> Response for an Application.
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<infData xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
<roid>EXAMPLE1-REP</roid>
<registrant>jd1234</registrant>
<contact type="admin">sh8013</contact>
<contact type="tech">sh8013</contact>
<ns>
<hostObj>ns1.example.com</hostObj>
<hostObj>ns1.example.net</hostObj>
</ns>
<clID>ClientX</clID>
<authInfo>
<pw>2fooBAR</pw>
</authInfo>
</infData>
</resData>
<extension>
<infData xmlns="urn:rbp:params:xml:ns:application-1.0">
<id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
<phase>landrush</phase>
<status s="updateRegistrantProhibited" />
<crDate>1999-04-03T22:00:00.0Z</crDate>
<upDate>1999-12-03T09:00:00.0Z</upDate>
</infData>
</extension>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54322-XYZ</svTRID>
</trID>
</response>
</epp>
3.1.3. EPP <transfer> Command
This extension does not define any extension to the EPP <transfer>
command or response described in the EPP Domain Name Mapping
[RFC5731].
Mitchell & Wright Expires June 4, 2013 [Page 9]
Internet-Draft EPP Domain Application Mapping December 2012
3.2. EPP Transform Commands
EPP provides five commands to transform objects: <create> to create
an instance of an object, <delete> to delete an instance of an
object, <renew> to extend the validity period of an object,
<transfer> to manage object sponsorship changes, and <update> to
change information associated with an object.
3.2.1. EPP <create> Command
This extension defines additional elements for the EPP <create>
command and response described in the EPP Domain Name Mapping
[RFC5731].
The EPP <create> command is used to provision an object within a
repository. A domain name application may be provisioned by
specifying the phase in which the application is to be processed.
In addition to the elements expressed in the <domain:create>, the
command is extended with an <app:create> element containing the
following child elements:
o phase: the identifier of the phase to which a domain name
application is being submitted.
Mitchell & Wright Expires June 4, 2013 [Page 10]
Internet-Draft EPP Domain Application Mapping December 2012
Example <create> Command for an Application
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<create xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
<ns>
<hostObj>ns1.example.net</hostObj>
<hostObj>ns2.example.net</hostObj>
</ns>
<registrant>jd1234</registrant>
<contact type="admin">sh8013</contact>
<contact type="tech">sh8013</contact>
<authInfo>
<pw>2fooBAR</pw>
</authInfo>
</create>
</create>
<extension>
<create xmlns="urn:rbp:params:xml:ns:application-1.0">
<phase>landrush</phase>
</create>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
When a <create> command has been processed successfully, the EPP
<resData> element MUST NOT include the <domain:creData> response
described in RFC5731. Instead the EPP <resData> element MUST contain
an <app:creData> element that contains the following child elements:
o An <id> element ..
o A <crDate> element that contains the date and time of application
object creation.
Mitchell & Wright Expires June 4, 2013 [Page 11]
Internet-Draft EPP Domain Application Mapping December 2012
Example <create> Response for an Application
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<creData xmlns="urn:rbp:params:xml:ns:application-1.0">
<id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
<crDate>1999-04-03T22:00:00.0Z</crDate>
</creData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
3.2.2. EPP <delete> Command
This extension defines additional elements for the EPP <delete>
command described in the EPP Domain Name Mapping [RFC5731]. No
additional elements are defined for the EPP <delete> response.
The delete command is extended to allow for the deletion of an
application. In addition to the elements expressed in the <domain:
delete>, the command is extended with a <app:delete> element that
contains the following child elements:
o id: the identifier of application to be deleted.
Mitchell & Wright Expires June 4, 2013 [Page 12]
Internet-Draft EPP Domain Application Mapping December 2012
Example <delete> Command to Delete an Application
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<delete>
<delete xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
</delete>
</delete>
<extension>
<delete xmlns="urn:rbp:params:xml:ns:application-1.0">
<id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
</delete>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
3.2.3. EPP <renew> Command
This extension does not define any extension to the EPP <renew>
command or response described in the EPP Domain Name Mapping
[RFC5731].
3.2.4. EPP <transfer> Command
This extension does not define any extension to the EPP <transfer>
command or response described in the EPP Domain Name Mapping
[RFC5731].
3.2.5. EPP <update> Command
This extension defines additional elements for the EPP <update>
command described in the EPP Domain Name Mapping [RFC5731]. No
additional elements are defined for the EPP <update> response.
The update command is extended to allow for the modification of an
application. In addition to the elements expressed in the <domain:
update>, the command is extended with a <app:update> element that
contains the following child elements:
o id: the identifier of application to be updated.
Mitchell & Wright Expires June 4, 2013 [Page 13]
Internet-Draft EPP Domain Application Mapping December 2012
Example <update> Command to change Administrative Contacts for an
Application
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<update>
<update xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
<add>
<contact type="admin">jd1234</contact>
</add>
<rem>
<contact type="admin">sh8013</contact>
</rem>
</update>
</update>
<extension>
<update xmlns="urn:rbp:params:xml:ns:application-1.0">
<id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
</update>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
4. Formal Syntax
An EPP object mapping is specified in XML Schema notation. The
formal syntax presented here is a complete schema representation of
the object mapping, suitable for automated validation of EPP XML
instances.
<?xml version="1.0"?>
<schema targetNamespace="urn:rbp:params:xml:ns:application-1.0"
xmlns:app="urn:rbp:params:xml:ns:application-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<!-- Child elements found in EPP commands. -->
<element name="check" type="app:phaseType" />
<element name="create" type="app:phaseType" />
<element name="delete" type="app:idType" />
<element name="info" type="app:idType" />
<element name="update" type="app:idType" />
<complexType name="phaseType">
Mitchell & Wright Expires June 4, 2013 [Page 14]
Internet-Draft EPP Domain Application Mapping December 2012
<sequence>
<element name="phase" type="token" />
</sequence>
</complexType>
<complexType name="idType">
<sequence>
<element name="id" type="token" />
</sequence>
</complexType>
<!-- Child elements found in EPP responses. -->
<element name="creData" type="app:creDataType" />
<element name="infData" type="app:infDataType" />
<complexType name="creDataType">
<sequence>
<element name="id" type="token" />
<element name="crDate" type="dateTime" minOccurs="0" />
</sequence>
</complexType>
<complexType name="infDataType">
<sequence>
<element name="id" type="token" />
<element name="phase" type="token" />
<element name="status" type="app:statusType"
maxOccurs="unbounded" />
<element name="crDate" type="dateTime" />
<element name="upDate" type="dateTime" minOccurs="0" />
</sequence>
</complexType>
<complexType name="statusType">
<simpleContent>
<extension base="normalizedString">
<attribute name="s" type="app:statusValueType"
use="required" />
</extension>
</simpleContent>
</complexType>
<simpleType name="statusValueType">
<restriction base="token">
<enumeration value="ok" />
<enumeration value="deleteProhibited" />
<enumeration value="pendingAllocation" />
<enumeration value="pendingValidation" />
Mitchell & Wright Expires June 4, 2013 [Page 15]
Internet-Draft EPP Domain Application Mapping December 2012
<enumeration value="updateAuthInfoProhibited" />
<enumeration value="updateContactProhibited" />
<enumeration value="updateDelegationProhibited" />
<enumeration value="updateRegistrantProhibited" />
<enumeration value="updateOtherProhibited" />
</restriction>
</simpleType>
</schema>
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
The mapping extensions described in this document do not provide any
security services beyond those described by EPP [RFC5730], the EPP
Domain Name Mapping [RFC5731], and protocol layers used by EPP. The
security considerations described in these other specifications also
apply to this specification.
Updates to and deletion of an application object, must be restricted
to clients authorized to perform the said operation on the object.
Because information contained within an application, or even the mere
fact that an application exists may be confidential; any attempt to
operate on an application object by an unauthorized client MUST be
rejected with an EPP 2303 (object does not exist) or an appropriate
auhorization error. Server policy may allow <info> operation with
filtered output by clients other than the sponsoring client, in which
case the <domain:infData> and <application:infData> response SHOULD
be filtered to include only fields that are publicly accessible.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, August 2009.
Mitchell & Wright Expires June 4, 2013 [Page 16]
Internet-Draft EPP Domain Application Mapping December 2012
Authors' Addresses
James Mitchell
ARI Registry Services
8/10 Queens Road
Melbourne, Victoria 3004
AU
Phone: +61 3 9866 3710
Email: [email protected]
URI: www.ariservices.com
Chris Wright
ARI Registry Services
8/10 Queens Road
Melbourne, Victoria 3004
AU
Phone: +61 3 9866 3710
Email: [email protected]
URI: www.ariservices.com
Mitchell & Wright Expires June 4, 2013 [Page 17]
draft-rbp-tmch-epp-mapping-01.txt
(text/plain, 26.4 KB)
Internet Engineering Task Force J. Mitchell
Internet-Draft C. Wright
Intended status: Informational ARI Registry Services
Expires: June 4, 2013 December 2012
Trademark Clearinghouse Extension Mapping for the Extensible
Provisioning Protocol (EPP)
draft-rbp-tmch-epp-mapping-01
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning of domain names during the
term of rights protection mechanism phases involving the trademark
clearinghouse.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Mitchell & Wright Expires June 4, 2013 [Page 1]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Trademark Clearinghouse . . . . . . . . . . . . . . . . . . . 3
2.1. Sunrise . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Trademark Claims . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Claims Check . . . . . . . . . . . . . . . . . . . . . 4
2.2.2. Claims Acknowledgment . . . . . . . . . . . . . . . . 4
2.3. Trademark Claims 2 . . . . . . . . . . . . . . . . . . . . 4
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Signed Mark Data . . . . . . . . . . . . . . . . . . . . . 5
3.2. Claims Key . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Notice Identifier . . . . . . . . . . . . . . . . . . . . 5
3.4. Source Address . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6
4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6
4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 6
4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 6
4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
4.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 9
4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 9
4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 9
4.2.1.1. Sunrise Domain Create . . . . . . . . . . . . . . 9
4.2.1.2. TM Claims Domain Create . . . . . . . . . . . . . 10
4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 11
4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 11
4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 11
4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 12
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Appendix A - TMCH Sunrise Domain Application
Example . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Mitchell & Wright Expires June 4, 2013 [Page 2]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
1. Introduction
This document describes extensions to the Extensible Provisioning
Protocol (EPP) for the operation of domain name registries for the
duration of the implementation of rights protection mechanisms that
integrate with the trademark clearinghouse.
This document decouples the sunrise and trademark claims processes
from the domain name allocation processes used by the registry. The
EPP Domain Application Mapping [RBP-APP-1.0] should be considered by
registries that require a process allowing multiple applications for
one domain name. An example illustrating its use is described in
Appendix A (Appendix A).
Readers should be familiar with trademark clearinghouse processes and
their implications on registries and the registration process. TODO:
Link to http://newgtlds.icann.org/en/about/trademark-clearinghouse.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
"tmch-1.0" is used as an abbreviation for
"urn:rbp:params:xml:ns:tmch-1.0". The XML namespace prefix "tmch" is
used, but implementations MUST NOT depend on it and instead employ a
proper namespace-aware XML parser and serializer to interpret and
output the XML documents.
2. Trademark Clearinghouse
The trademark clearinghouse provides several services required by
server operators during the launch phases of new TLD registries.
Eligible rights holders vetted by the trademark clearinghouse, are
given priority in applications for domain names during the sunrise
period, and potential registrants are notified of an eligible mark
matching their domain name during the trademark claims period.
2.1. Sunrise
Sunrise is the process by which new TLDs will enable rights holders
to have first access to names within a TLD. Only appropriately
qualified rights holders are allowed to participate in Sunrise. The
scope of qualification is defined in ICANN policy and outside this
specification. This specification simply details the mechanism by
which this qualification is communicated with the TLD operator using
Mitchell & Wright Expires June 4, 2013 [Page 3]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
the EPP protocol.
The TMCH is responsible for the generation of Signed Mark Data (SMD)
files for mark holders that meet the requirements to participate in a
sunrise as specified in the guidebook. This extension makes no
attempt to define the format of the SMD, instead provides only a
mechanism for its transport from registrars to registries. It is
expected that the trademark clearinghouse provider will publish the
format of the SMD.
This process requires extension to the <create> command as described
below. Requests for registration of a domain name without signed
mark data MUST be rejected during the sunrise period.
2.2. Trademark Claims
Trademark Claims refers to the period during which potential
registrants must acknowledge a notice describing one or more entities
that have trademarks for the domain names to be registered. Two
extensions are required to facilitate this process; the Claims Check
is used to determine existence of a claim, and Claims Acknowledgement
to provide evidence of acceptance of the claim on registration.
2.2.1. Claims Check
This process requires extension to the <check> command and response
as described below. A check response during this stage indicates
whether a claim exists, and includes the relevant claims key used by
the client for retrieval of claims information from the trademark
clearinghouse.
2.2.2. Claims Acknowledgment
This process requires extension to the <create> command as described
below. Registrations for domain names matching a claim MUST be
rejected unless the extension acknowledgement is provided.
2.3. Trademark Claims 2
Trademark Claims 2 is a variation to the Trademark Claims period
during which potential registrants are displayed a generic notice
describing existence of a trademark covering the given domain name.
This process requires extension to the <check> command as described
below. A check response during this stage will indicate a claim
exists, however no claim key will be provided.
Mitchell & Wright Expires June 4, 2013 [Page 4]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
3. Object Attributes
This extension adds additional elements to the EPP Domain Name
Mapping [RFC5731]. Only those new elements are described here.
3.1. Signed Mark Data
Signed mark data (SMD) is the information published by the trademark
clearinghouse as proof of validation and applicability for
participation in the sunrise phase, and signed to verify
authenticity.
This specification assumes the mark data will be provided by the
trademark clearinghouse will be an XML document with XML Signatures
for authenticity. This extension requires the SMD be transmitted to
the server encoded using Base64 for two reasons:
o XML Signature validation is sensitive to changes in whitespace and
formatting and a signed document may become invalid if treated as
text, such as in emails or log files.
o It is known that registry operators have implemented their EPP XML
processing using SAX parsers, however signature validation
libraries require a DOM parser. This specification should not
require server operators change their XML parser.
3.2. Claims Key
The claims key is an identifier returned by the server in response to
a <tmch:check> command and used for the lookup of claims information
in the trademark clearinghouse. Clients SHOULD NOT place any
restrictions on the form and syntax of the claims key.
3.3. Notice Identifier
The notice identifier is obtained by the client requesting the claims
notice from the trademark clearinghouse using the aforementioned
claims key. The notice identifier is a unique identifier assigned by
the TMCH to each Trademark Claims notice it generates. Severs and
clients SHOULD NOT place any restrictions on the form and syntax of
the claims key.
3.4. Source Address
Clients are required to provide the source address of the entity that
accepted the trademark claims notice. This information SHOULD take
the form of an internet address. The syntax for IPv4 addresses
SHOULD conform to [RFC0791]. The syntax for IPv6 addresses SHOULD
Mitchell & Wright Expires June 4, 2013 [Page 5]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
conform to [RFC5952].
3.5. Dates and Times
Date and time attribute values MUST be represented in Universal
Coordinated Time (UTC) using the Gregorian calendar. The extended
date-time form using upper case "T" and "Z" characters defined in
[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
values, as XML Schema does not support truncated date-time forms or
lower case "T" and "Z" characters.
4. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730]. The command
mappings described here are specifically for use in the Trademark
Clearinghouse Extension.
4.1. EPP Query Commands
EPP provides three commands to retrieve object information: <check>
to determine if an object is known to the server, <info> to retrieve
detailed information associated with an object, and <transfer> to
retrieve object transfer status information.
4.1.1. EPP <check> Command
This extension defines additional elements to extend the EPP <check>
command and response to be used in conjunction with the EPP Domain
Name Mapping [RFC5731].
To enable clients to identify domain names that are subject to claims
processing, the <domain:check> command is extended with a <tmch:
check> element, which signals a client's intention to retrieve claims
information.
Mitchell & Wright Expires June 4, 2013 [Page 6]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
Example <check> command requesting claims information
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<check>
<check xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
</check>
</check>
<extension>
<check xmlns="urn:rbp:params:xml:ns:tmch-1.0" />
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
When a <check> command containing the <tmch:check> element has been
processed successfully, the server MUST NOT respond with the <domain:
chkData> element described in the EPP Domain Name Mapping [RFC5731].
Instead, servers must respond with a <tmch:chkData> element that
contains one <tmch:cd> element for each domain name present in the
command. The <tmch:cd> element contains the following child
elements:
o A <tmch:name> element containing a domain name from the
corresponding command. The order and composition of domain names
in the response MUST be the same as the order and composition of
domain names provided in the command, with exception to
transformations required of validating XML parsers. A mandatory
"exists" attribute describes whether a claim exists for this name.
o A <tmch:key> element containing the claims key used for retrieval
of the claims data. This element MUST be present during the
Trademark Claims period where the <tmch:name> element's "exists"
attribute evaluates to true.
Mitchell & Wright Expires June 4, 2013 [Page 7]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
Example <check> response during the trademark claims period
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<chkData xmlns="urn:rbp:params:xml:ns:tmch-1.0">
<cd>
<name exists="1">example.tld</name>
<key>CLAIM_KEY</key>
</cd>
</chkData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
Example <check> response during the claims 2 period
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<chkData xmlns="urn:rbp:params:xml:ns:tmch-1.0">
<cd>
<name exists="1">example.tld</name>
</cd>
</chkData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
Mitchell & Wright Expires June 4, 2013 [Page 8]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
4.1.2. EPP <info> Command
This extension does not define any extension to the EPP <info>
command or response described in the EPP Domain Name Mapping
[RFC5731].
4.1.3. EPP <transfer> Command
This extension does not define any extension to the EPP <transfer>
command or response described in the EPP Domain Name Mapping
[RFC5731].
4.2. EPP Transform Commands
EPP provides five commands to transform objects: <create> to create
an instance of an object, <delete> to delete an instance of an
object, <renew> to extend the validity period of an object,
<transfer> to manage object sponsorship changes, and <update> to
change information associated with an object.
4.2.1. EPP <create> Command
There are two forms of the extension to the EPP <create> command that
are dependent on the whether the server is operating a sunrise or TM
claims process. Both forms are described below.
4.2.1.1. Sunrise Domain Create
The Sunrise Create extension to the EPP Domain Name Mapping [RFC5731]
includes the verifiable trademark information that the server uses to
match against the domain name to authorize the domain create.
This extension defines additional elements to be sent to the server
for domain creates. In addition to the normal <domain:create>, the
command contains a <tmch:create> element that contains the following
child elements:
o A <tmch:smd> element that contains the base-64 encoded signed mark
data.
Mitchell & Wright Expires June 4, 2013 [Page 9]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
Example <create> during the sunrise period.
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<create xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
<registrant>jd1234</registrant>
<contact type="admin">sh8013</contact>
<contact type="tech">sh8013</contact>
<authInfo>
<pw>2fooBAR</pw>
</authInfo>
</create>
</create>
<extension>
<create xmlns="urn:rbp:params:xml:ns:tmch-1.0">
<smd>VGhpcyBpcyBhIHBsYWNlaG9sZGVyIGZvciBkYXRhIHByb3Z
pZGVkIGJ5IHRoZSBUcmFkZW1hcmsgQ2xlYXJpbmdob3VzZQo=
</smd>
</create>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
4.2.1.2. TM Claims Domain Create
The Claims Create extension to the EPP Domain Name Mapping [RFC5731]
includes the information related to the acceptance of the claims
notice for the TM Claims period.
This extension defines additional elements to be sent to the server
for domain creates. In addition to the normal <domain:create>, the
command contains a <tmch:create> element that contains the following
child elements:
o A <tmch:noticeID> element that contains the unique notice
identifier generated by the Claims Notice Information Service
(CNIS).
o A <generated> element that contains the date and time that the
claims notice was generated.
o A <accepted> element that contains the date and time that the
claims notice was accepted.
Mitchell & Wright Expires June 4, 2013 [Page 10]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
o A <source> element that contains the source information of the
consumer that was displayed or that accepted the claims notice,
for example the consumer's IP address.
Example create during the TM Claims period.
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<create xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
<registrant>jd1234</registrant>
<contact type="admin">sh8013</contact>
<contact type="tech">sh8013</contact>
<authInfo>
<pw>2fooBAR</pw>
</authInfo>
</create>
</create>
<extension>
<create xmlns="urn:rbp:params:xml:ns:tmch-1.0">
<noticeID>49FD46E6C4B45C55D4AC</noticeID>
<generated>2012-06-19T09:00:00.0Z</generated>
<accepted>2012-06-19T09:00:10.0Z</accepted>
<source>192.0.2.29</source>
</create>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
4.2.2. EPP <delete> Command
This extension does not define any extension to the EPP <delete>
command or response described in the EPP Domain Name Mapping
[RFC5731].
4.2.3. EPP <renew> Command
This extension does not define any extension to the EPP <renew>
command or response described in the EPP Domain Name Mapping
[RFC5731].
4.2.4. EPP <transfer> Command
This extension does not define any extension to the EPP <transfer>
command or response described in the EPP Domain Name Mapping
Mitchell & Wright Expires June 4, 2013 [Page 11]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
[RFC5731].
4.2.5. EPP <update> Command
This extension does not define any extension to the EPP <update>
command or response described in the EPP Domain Name Mapping
[RFC5731].
5. Formal Syntax
<?xml version="1.0"?>
<schema targetNamespace="urn:rbp:params:xml:ns:tmch-1.0"
xmlns:tmch="urn:rbp:params:xml:ns:tmch-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
<!-- Custom command extensions -->
<element name="check" />
<element name="create" type="tmch:createType" />
<complexType name="createType">
<choice>
<element name="smd" type="base64Binary" />
<sequence>
<element name="noticeID" type="token" />
<element name="generated" type="dateTime" />
<element name="accepted" type="dateTime" />
<element name="source" type="token" />
</sequence>
</choice>
</complexType>
<!-- Custom response extensions for checkbis extension -->
<element name="chkData" type="tmch:chkDataType" />
<complexType name="chkDataType">
<sequence>
<element name="cd" type="tmch:checkType"
maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="checkType">
<sequence>
Mitchell & Wright Expires June 4, 2013 [Page 12]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
<element name="name" type="tmch:checkNameType" />
<element name="key" type="normalizedString" minOccurs="0" />
</sequence>
</complexType>
<complexType name="checkNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="exists" type="boolean" use="required" />
</extension>
</simpleContent>
</complexType>
</schema>
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
The mapping extensions described in this document do not provide any
security services beyond those described by EPP [RFC5730], the EPP
Domain Name Mapping [RFC5731], and protocol layers used by EPP. The
security considerations described in these other specifications apply
to this specification as well.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, August 2009.
8.2. Informative References
[RBP-APP-1.0]
Mitchell, J. and C. Wright, "Domain Name Application
Extension Mapping for the Extensible Provisioning Protocol
Mitchell & Wright Expires June 4, 2013 [Page 13]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
(EPP)", December 2012.
Appendix A. Appendix A - TMCH Sunrise Domain Application Example
Example showing creating an application for a domain name during the
sunrise period. Additional extensions, such as IDN may be included
as required by the server.
<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<create xmlns="urn:ietf:params:xml:ns:domain-1.0">
<name>example.tld</name>
<ns>
<hostObj>ns1.example.net</hostObj>
<hostObj>ns2.example.net</hostObj>
</ns>
<registrant>jd1234</registrant>
<contact type="admin">sh8013</contact>
<contact type="tech">sh8013</contact>
<authInfo>
<pw>2fooBAR</pw>
</authInfo>
</create>
</create>
<extension>
<create xmlns="urn:rbp:params:xml:ns:application-1.0">
<phase>tmch-sunrise</phase>
</create>
<create xmlns="urn:rbp:params:xml:ns:tmch-1.0">
<smd>VGhpcyBpcyBhIHBsYWNlaG9sZGVyIGZvciBkYXRhIHByb3Z
pZGVkIGJ5IHRoZSBUcmFkZW1hcmsgQ2xlYXJpbmdob3VzZQo=
</smd>
</create>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
Mitchell & Wright Expires June 4, 2013 [Page 14]
Internet-Draft EPP Trademark Clearinghouse Mapping December 2012
Authors' Addresses
James Mitchell
ARI Registry Services
8/10 Queens Road
Melbourne, Victoria 3004
AU
Phone: +61 3 9866 3710
Email: [email protected]
URI: www.ariservices.com
Chris Wright
ARI Registry Services
8/10 Queens Road
Melbourne, Victoria 3004
AU
Phone: +61 3 9866 3710
Email: [email protected]
URI: www.ariservices.com
Mitchell & Wright Expires June 4, 2013 [Page 15]