draft-ietf-eppext-launchphase-01.txt   draft-ietf-eppext-launchphase-02.txt 
Internet Engineering Task Force J. Gould Internet Engineering Task Force J. Gould
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Standards Track W. Tan Intended status: Standards Track W. Tan
Expires: September 18, 2014 Cloud Registry Expires: March 29, 2015 Cloud Registry
G. Brown G. Brown
CentralNic Ltd CentralNic Ltd
March 17, 2014 September 25, 2014
Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
draft-ietf-eppext-launchphase-01 draft-ietf-eppext-launchphase-02
Abstract Abstract
This document describes an Extensible Provisioning Protocol (EPP) This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name registrations and applications during the launch of a domain name
registry. registry.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 18, 2014. This Internet-Draft will expire on March 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Application Identifier . . . . . . . . . . . . . . . . . . 5 2.1. Application Identifier . . . . . . . . . . . . . . . . . 4
2.2. Validator Identifier . . . . . . . . . . . . . . . . . . . 5 2.2. Validator Identifier . . . . . . . . . . . . . . . . . . 5
2.3. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. State Transition . . . . . . . . . . . . . . . . . . . 9 2.4.1. State Transition . . . . . . . . . . . . . . . . . . 7
2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . . 10 2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . 8
2.6. Mark Validation Models . . . . . . . . . . . . . . . . . . 13 2.6. Mark Validation Models . . . . . . . . . . . . . . . . . 11
2.6.1. <launch:codeMark> element . . . . . . . . . . . . . . 14 2.6.1. <launch:codeMark> element . . . . . . . . . . . . . . 12
2.6.2. <mark:mark> element . . . . . . . . . . . . . . . . . 15 2.6.2. <mark:mark> element . . . . . . . . . . . . . . . . . 13
2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 15 2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 13
2.6.3.1. <smd:signedMark> element . . . . . . . . . . . . . 15 2.6.3.1. <smd:signedMark> element . . . . . . . . . . . . 13
2.6.3.2. <smd:encodedSignedMark> element . . . . . . . . . 15 2.6.3.2. <smd:encodedSignedMark> element . . . . . . . . . 13
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 15 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 13
3.1. EPP <check> Command . . . . . . . . . . . . . . . . . . . 16 3.1. EPP <check> Command . . . . . . . . . . . . . . . . . . . 14
3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 16 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 14
3.1.2. Availability Check Form . . . . . . . . . . . . . . . 18 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 17
3.2. EPP <info> Command . . . . . . . . . . . . . . . . . . . . 19 3.2. EPP <info> Command . . . . . . . . . . . . . . . . . . . 19
3.3. EPP <create> Command . . . . . . . . . . . . . . . . . . . 23 3.3. EPP <create> Command . . . . . . . . . . . . . . . . . . 22
3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 23 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 22
3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 29 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . 28
3.3.3. General Create Form . . . . . . . . . . . . . . . . . 31 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 31
3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 32 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 32
3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 34 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 34
3.4. EPP <update> Command . . . . . . . . . . . . . . . . . . . 35 3.4. EPP <update> Command . . . . . . . . . . . . . . . . . . 35
3.5. EPP <delete> Command . . . . . . . . . . . . . . . . . . . 36 3.5. EPP <delete> Command . . . . . . . . . . . . . . . . . . 36
3.6. EPP <renew> Command . . . . . . . . . . . . . . . . . . . 37 3.6. EPP <renew> Command . . . . . . . . . . . . . . . . . . . 37
3.7. EPP <transfer> Command . . . . . . . . . . . . . . . . . . 38 3.7. EPP <transfer> Command . . . . . . . . . . . . . . . . . 38
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 38 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 38 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 38
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 45 6. Change History . . . . . . . . . . . . . . . . . . . . . . . 46
6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 46 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 46
6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 46 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 46
6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 46 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 46
6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 46 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 46
6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 47 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 47
6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . . 47 6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 47
6.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . . 47 6.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 47
6.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . . 47 6.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 47
6.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . . 48 6.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 48
6.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . . 48 6.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 48
6.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . . 49 6.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 49
6.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . . 49 6.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 49
6.13. Change from 12 to WG 00 . . . . . . . . . . . . . . . . . 49 6.13. Change from 12 to WG 00 . . . . . . . . . . . . . . . . . 49
6.14. Change WG 00 to WG 01 . . . . . . . . . . . . . . . . . . 50 6.14. Change WG 00 to WG 01 . . . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 6.15. Change WG 01 to WG 02 . . . . . . . . . . . . . . . . . . 50
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
9. Normative References . . . . . . . . . . . . . . . . . . . . . 50 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.1. Normative References . . . . . . . . . . . . . . . . . . 51
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document describes an extension mapping for version 1.0 of the This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping
specifies a flexible schema that can be used to implement several specifies a flexible schema that can be used to implement several
common use cases related to the provisioning and management of domain common use cases related to the provisioning and management of domain
name registrations and applications during the launch of a domain name registrations and applications during the launch of a domain
name registry. name registry.
skipping to change at page 4, line 29 skipping to change at page 3, line 41
The EPP domain name mapping [RFC5731] is designed for the steady- The EPP domain name mapping [RFC5731] is designed for the steady-
state operation of a registry. During a launch period, the model in state operation of a registry. During a launch period, the model in
place may be different from what is defined in the EPP domain name place may be different from what is defined in the EPP domain name
mapping [RFC5731]. For example, registries often accept multiple mapping [RFC5731]. For example, registries often accept multiple
applications for the same domain name during the "Sunrise" launch applications for the same domain name during the "Sunrise" launch
phase, referred to as a Launch Application. A Launch Registration phase, referred to as a Launch Application. A Launch Registration
refers to a registration made during a launch phase when the server refers to a registration made during a launch phase when the server
uses a "first-come, first-served" model. Even in a "first-come, uses a "first-come, first-served" model. Even in a "first-come,
first-served" model, additional steps and information might be first-served" model, additional steps and information might be
required, such as trademark information. In addition, the TMCH required, such as trademark information. In addition, the
Functional Specification [1] defines a registry interface for the [I-D.ietf-eppext-tmch-smd] defines a registry interface for the
Trademark Claims or "claims" launch phase that includes support for Trademark Claims or "claims" launch phase that includes support for
presenting a Trademark Claims Notice to the Registrant. This presenting a Trademark Claims Notice to the Registrant. This
document proposes an extension to the domain name mapping in order to document proposes an extension to the domain name mapping in order to
provide a uniform interface for the management of Launch Applications provide a uniform interface for the management of Launch Applications
and Launch Registrations in launch phases. and Launch Registrations in launch phases.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 5, line 13 skipping to change at page 4, line 29
relationships and are not a REQUIRED feature of this protocol. relationships and are not a REQUIRED feature of this protocol.
"launch-1.0" is used as an abbreviation for "launch-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix
"launch" is used, but implementations MUST NOT depend on it and "launch" is used, but implementations MUST NOT depend on it and
instead employ a proper namespace-aware XML parser and serializer to instead employ a proper namespace-aware XML parser and serializer to
interpret and output the XML documents. interpret and output the XML documents.
"signedMark-1.0" is used as an abbreviation for "signedMark-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:signedMark-1.0" that is defined in "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in
[draft-ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is used,
used, but implementations MUST NOT depend on it and instead employ a but implementations MUST NOT depend on it and instead employ a proper
proper namespace-aware XML parser and serializer to interpret and namespace-aware XML parser and serializer to interpret and output the
output the XML documents. XML documents.
"mark-1.0" is used as an abbreviation for "mark-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:mark-1.0" that is defined in "urn:ietf:params:xml:ns:mark-1.0" that is defined in
[draft-ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is used,
used, but implementations MUST NOT depend on it and instead employ a but implementations MUST NOT depend on it and instead employ a proper
proper namespace-aware XML parser and serializer to interpret and namespace-aware XML parser and serializer to interpret and output the
output the XML documents. XML documents.
2. Object Attributes 2. Object Attributes
This extension adds additional elements to the EPP domain name This extension adds additional elements to the EPP domain name
mapping [RFC5731]. Only those new elements are described here. mapping [RFC5731]. Only those new elements are described here.
2.1. Application Identifier 2.1. Application Identifier
Servers MAY allow multiple applications, referred to as a Launch Servers MAY allow multiple applications, referred to as a Launch
Application, of the same domain name during its launch phase Application, of the same domain name during its launch phase
operations. Upon receiving a valid request to create a Launch operations. Upon receiving a valid request to create a Launch
Application, the server MUST create an application object Application, the server MUST create an application object
corresponding to the request, assign an application identifier for corresponding to the request, assign an application identifier for
the Launch Application, set the [RFC5731] pendingCreate status, and the Launch Application, set the [RFC5731] pendingCreate status, and
return the application identifier to the client with the <launch: return the application identifier to the client with the
applicationID> element. In order to facilitate correlation, all <launch:applicationID> element. In order to facilitate correlation,
subsequent launch operations on the Launch Application MUST be all subsequent launch operations on the Launch Application MUST be
qualified by the previously assigned application identifier using the qualified by the previously assigned application identifier using the
<launch:applicationID> element. <launch:applicationID> element.
If the <domain:create> command processes a request synchronously If the <domain:create> command processes a request synchronously
without the use of an intermediate Launch Application, then an without the use of an intermediate Launch Application, then an
application identifier MAY not be needed. application identifier MAY not be needed.
2.2. Validator Identifier 2.2. Validator Identifier
The Validator Identifier is the unique identifier for a Trademark The Validator Identifier is the unique identifier for a Trademark
skipping to change at page 6, line 15 skipping to change at page 5, line 30
Validator Identifier of the Trademark Validator. Registries MAY Validator Identifier of the Trademark Validator. Registries MAY
support more than one Third Party Trademark Validator. The Internet support more than one Third Party Trademark Validator. The Internet
Corporation for Assigned Names and Numbers (ICANN) Trademark Corporation for Assigned Names and Numbers (ICANN) Trademark
Clearinghouse (TMCH) is the default Trademark Validator and is Clearinghouse (TMCH) is the default Trademark Validator and is
reserved the Validator Identifier of "tmch". If the ICANN TMCH is reserved the Validator Identifier of "tmch". If the ICANN TMCH is
not used or multiple Trademark Validators are used, the Validator not used or multiple Trademark Validators are used, the Validator
Identifier MUST be defined using the "validatorID" attribute. Identifier MUST be defined using the "validatorID" attribute.
The Validator Identifier MAY be related to one or more issuer The Validator Identifier MAY be related to one or more issuer
identifiers of the <mark:id> element and the <smd:id> element defined identifiers of the <mark:id> element and the <smd:id> element defined
in [draft-ietf-eppext-tmch-smd]. Both the Validator Identifier and in [I-D.ietf-eppext-tmch-smd]. Both the Validator Identifier and the
the Issuer Identifier used MUST be unique. The list of validator Issuer Identifier used MUST be unique. The list of validator
identifiers and the relationship to issuer identifiers is out of identifiers and the relationship to issuer identifiers is out of
scope for this document. scope for this document.
The Validator Identifier MAY define a non-Trademark Validator that
supports a form of claims.
2.3. Launch Phases 2.3. Launch Phases
The server MAY support multiple launch phases sequentially or The server MAY support multiple launch phases sequentially or
simultaneously. The <launch:phase> element MUST be included by the simultaneously. The <launch:phase> element MUST be included by the
client to define the target launch phase of the command. The server client to define the target launch phase of the command. The server
SHOULD validate the phase and MAY validate the sub-phase of the SHOULD validate the phase and MAY validate the sub-phase of the
<launch:phase> element against the active phase and OPTIONAL sub- <launch:phase> element against the active phase and OPTIONAL sub-
phase of the server on a create command, and return an EPP error phase of the server on a create command, and return an EPP error
result code of 2306 if there is a mismatch. result code of 2306 if there is a mismatch.
skipping to change at page 6, line 31 skipping to change at page 6, line 4
The server MAY support multiple launch phases sequentially or The server MAY support multiple launch phases sequentially or
simultaneously. The <launch:phase> element MUST be included by the simultaneously. The <launch:phase> element MUST be included by the
client to define the target launch phase of the command. The server client to define the target launch phase of the command. The server
SHOULD validate the phase and MAY validate the sub-phase of the SHOULD validate the phase and MAY validate the sub-phase of the
<launch:phase> element against the active phase and OPTIONAL sub- <launch:phase> element against the active phase and OPTIONAL sub-
phase of the server on a create command, and return an EPP error phase of the server on a create command, and return an EPP error
result code of 2306 if there is a mismatch. result code of 2306 if there is a mismatch.
The following launch phase values are defined: The following launch phase values are defined:
sunrise The phase during which trademark holders can submit sunrise The phase during which trademark holders can submit
registrations or applications with trademark information that can registrations or applications with trademark information that can
be validated by the server. be validated by the server.
landrush A post-Sunrise phase when non-trademark holders are allowed landrush A post-Sunrise phase when non-trademark holders are allowed
to register domain names with steps taken to address a large to register domain names with steps taken to address a large
volume of initial registrations. volume of initial registrations.
claims The Trademark Claims phase, as defined in the TMCH Functional claims The Trademark Claims phase, as defined in the TMCH Functional
Specification [2], in which a Claims Notice must be displayed to a Specification [1], in which a Claims Notice must be displayed to a
prospective registrant of a domain name that matches trademarks. prospective registrant of a domain name that matches trademarks.
open A post-launch phase that is also referred to as "steady state". open A post-launch phase that is also referred to as "steady state".
Servers MAY require additional trademark protection during this Servers MAY require additional trademark protection during this
phase. phase.
custom A custom server launch phase that is defined using the "name" custom A custom server launch phase that is defined using the "name"
attribute. attribute.
For extensibility, the <launch:phase> element includes an OPTIONAL For extensibility, the <launch:phase> element includes an OPTIONAL
"name" attribute that can define a sub-phase or the full name of the "name" attribute that can define a sub-phase or the full name of the
phase when the <launch:phase> element has the "custom" value. For phase when the <launch:phase> element has the "custom" value. For
skipping to change at page 10, line 14 skipping to change at page 9, line 6
2.5. Poll Messaging 2.5. Poll Messaging
A Launch Application MUST and a Launch Registration MAY be handled as A Launch Application MUST and a Launch Registration MAY be handled as
a domain name of [RFC5731] in "pendingCreate" status, with the launch a domain name of [RFC5731] in "pendingCreate" status, with the launch
status values defined in Section 2.4. As a Launch Application or status values defined in Section 2.4. As a Launch Application or
Launch Registration transitions between the status values defined in Launch Registration transitions between the status values defined in
Section 2.4, the server SHOULD insert poll messages, per [RFC5730], Section 2.4, the server SHOULD insert poll messages, per [RFC5730],
for the applicable intermediate statuses, including the for the applicable intermediate statuses, including the
"pendingValidation", "validated", "pendingAllocation, and "invalid" "pendingValidation", "validated", "pendingAllocation, and "invalid"
statuses, using the <domain:infData> element with the <launch: statuses, using the <domain:infData> element with the
infData> extension. The <domain:infData> element MAY contain non- <launch:infData> extension. The <domain:infData> element MAY contain
mandatory information, like contact and name server information. non-mandatory information, like contact and name server information.
Also, further extensions that would normally be included in the Also, further extensions that would normally be included in the
response of a <domain:info> command, per [RFC5731], MAY be included. response of a <domain:info> command, per [RFC5731], MAY be included.
For the final statuses, including the "allocated" and "rejected" For the final statuses, including the "allocated" and "rejected"
statuses, the server MUST insert a <domain:panData> poll message, per statuses, the server MUST insert a <domain:panData> poll message, per
[RFC5731], with the <launch:infData> extension. [RFC5731], with the <launch:infData> extension.
The following is an example poll message for a Launch Application The following is an example poll message for a Launch Application
that has transitioned to the "pendingAllocation" state. that has transitioned to the "pendingAllocation" state.
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
skipping to change at page 13, line 48 skipping to change at page 11, line 48
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
2.6. Mark Validation Models 2.6. Mark Validation Models
A server MUST support at least one of the following models for A server MUST support at least one of the following models for
validating trademark information: validating trademark information:
code Use of a mark code by itself to validate that the mark matches code Use of a mark code by itself to validate that the mark matches
the domain name. This model is supported using the <launch: the domain name. This model is supported using the
codeMark> element with just the <launch:code> element. <launch:codeMark> element with just the <launch:code> element.
mark The mark information is passed without any other validation mark The mark information is passed without any other validation
element. The server will use some custom form of validation to element. The server will use some custom form of validation to
validate that the mark information is authentic. This model is validate that the mark information is authentic. This model is
supported using the <launch:codeMark> element with just the <mark: supported using the <launch:codeMark> element with just the
mark> (Section 2.6.2) element. <mark:mark> (Section 2.6.2) element.
code with mark: A code is used along with the mark information by code with mark: A code is used along with the mark information by
the server to validate the mark utilizing an external party. The the server to validate the mark utilizing an external party. The
code represents some form of secret that matches the mark code represents some form of secret that matches the mark
information passed. This model is supported using the <launch: information passed. This model is supported using the
codeMark> element that contains both the <launch:code> and the <launch:codeMark> element that contains both the <launch:code> and
<mark:mark> (Section 2.6.2) elements. the <mark:mark> (Section 2.6.2) elements.
signed mark: The mark information is digitally signed as described signed mark: The mark information is digitally signed as described
in the Digital Signature (Section 2.6.3) section. The digital in the Digital Signature (Section 2.6.3) section. The digital
signature can be directly validated by the server using the public signature can be directly validated by the server using the public
key of the external party that created the signed mark using its key of the external party that created the signed mark using its
private key. This model is supported using the <smd:signedMark> private key. This model is supported using the <smd:signedMark>
(Section 2.6.3.1) and <smd:encodedSignedMark> (Section 2.6.3.2) (Section 2.6.3.1) and <smd:encodedSignedMark> (Section 2.6.3.2)
elements. elements.
More than one <launch:codeMark>, <smd:signedMark> (Section 2.6.3.1), More than one <launch:codeMark>, <smd:signedMark> (Section 2.6.3.1),
or <smd:encodedSignedMark> (Section 2.6.3.2) element MAY be or <smd:encodedSignedMark> (Section 2.6.3.2) element MAY be
skipping to change at page 15, line 10 skipping to change at page 13, line 10
<mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"> <mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
... ...
</mark:mark> </mark:mark>
</launch:codeMark> </launch:codeMark>
2.6.2. <mark:mark> element 2.6.2. <mark:mark> element
A <mark:mark> element describes an applicant's prior right to a given A <mark:mark> element describes an applicant's prior right to a given
domain name that is used with the "mark", "mark with code", and the domain name that is used with the "mark", "mark with code", and the
"signed mark" validation models. The <mark:mark> element is defined "signed mark" validation models. The <mark:mark> element is defined
in [draft-ietf-eppext-tmch-smd]. A new mark format can be supported in [I-D.ietf-eppext-tmch-smd]. A new mark format can be supported by
by creating a new XML schema for the mark that has an element that creating a new XML schema for the mark that has an element that
substitutes for the <mark:abstractMark> element from substitutes for the <mark:abstractMark> element from
[draft-ietf-eppext-tmch-smd]. [I-D.ietf-eppext-tmch-smd].
2.6.3. Digital Signature 2.6.3. Digital Signature
Digital signatures MAY be used by the server to validate either the Digital signatures MAY be used by the server to validate either the
mark information, when using the "signed mark" validation model with mark information, when using the "signed mark" validation model with
the <smd:signedMark> (Section 2.6.3.1) element or the <smd: the <smd:signedMark> (Section 2.6.3.1) element or the
encodedSignedMark> (Section 2.6.3.2) element. <smd:encodedSignedMark> (Section 2.6.3.2) element.
2.6.3.1. <smd:signedMark> element 2.6.3.1. <smd:signedMark> element
The <smd:signedMark> element contains the digitally signed mark The <smd:signedMark> element contains the digitally signed mark
information. The <smd:signedMark> element is defined in information. The <smd:signedMark> element is defined in
[draft-ietf-eppext-tmch-smd]. A new signed mark format can be [I-D.ietf-eppext-tmch-smd]. A new signed mark format can be
supported by creating a new XML schema for the signed mark that has supported by creating a new XML schema for the signed mark that has
an element that substitutes for the <smd:abstractSignedMark> element an element that substitutes for the <smd:abstractSignedMark> element
from [draft-ietf-eppext-tmch-smd]. from [I-D.ietf-eppext-tmch-smd].
2.6.3.2. <smd:encodedSignedMark> element 2.6.3.2. <smd:encodedSignedMark> element
The <smd:encodedSignedMark> element contains an encoded form of the The <smd:encodedSignedMark> element contains an encoded form of the
digitally signed <smd:signedMark> (Section 2.6.3.1) element. The digitally signed <smd:signedMark> (Section 2.6.3.1) element. The
<smd:encodedSignedMark> element is defined in <smd:encodedSignedMark> element is defined in
[draft-ietf-eppext-tmch-smd]. A new encoded signed mark format can [I-D.ietf-eppext-tmch-smd]. A new encoded signed mark format can be
be supported by creating a new XML schema for the encoded signed mark supported by creating a new XML schema for the encoded signed mark
that has an element that substitutes for the <smd:encodedSignedMark> that has an element that substitutes for the <smd:encodedSignedMark>
element from [draft-ietf-eppext-tmch-smd]. element from [I-D.ietf-eppext-tmch-smd].
3. EPP Command Mapping 3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730]. The command in the EPP core protocol specification [RFC5730]. The command
mappings described here are specifically for use in the Launch Phase mappings described here are specifically for use in the Launch Phase
Extension. Extension.
This mapping is designed to be flexible, requiring only a minimum set This mapping is designed to be flexible, requiring only a minimum set
of required elements. of required elements.
skipping to change at page 16, line 39 skipping to change at page 14, line 38
matching trademarks, in the specified launch phase, for each domain matching trademarks, in the specified launch phase, for each domain
name passed in the command. The availability check information name passed in the command. The availability check information
defined in the EPP domain name mapping [RFC5731] MUST NOT be returned defined in the EPP domain name mapping [RFC5731] MUST NOT be returned
for the Claims Check Command. This form is the default form and MAY for the Claims Check Command. This form is the default form and MAY
be explicitly identified by setting the <launch:check> "type" be explicitly identified by setting the <launch:check> "type"
attribute to "claims". attribute to "claims".
Instead of returning whether the domain name is available, the Claims Instead of returning whether the domain name is available, the Claims
Check Command will return whether or not at least one matching Check Command will return whether or not at least one matching
trademark exists for the domain name. If there is at least one trademark exists for the domain name. If there is at least one
matching trademark that exists for the domain name, a <launch: matching trademark that exists for the domain name, a
claimKey> element is returned. The client MAY then use the value of <launch:claimKey> element is returned. The client MAY then use the
the <launch:claimKey> element to obtain information needed to value of the <launch:claimKey> element to obtain information needed
generate the Trademark Claims Notice from Trademark Validator based to generate the Trademark Claims Notice from Trademark Validator
on the Validator Identifier (Section 2.2). The unique notice based on the Validator Identifier (Section 2.2). The unique notice
identifier of the Trademark Claims Notice MUST be passed in the identifier of the Trademark Claims Notice MUST be passed in the
<launch:noticeID> element of the extension to the Create Command <launch:noticeID> element of the extension to the Create Command
(Section 3.3). (Section 3.3).
The <domain:name> elements in the EPP <check> command of EPP domain The <domain:name> elements in the EPP <check> command of EPP domain
name mapping [RFC5731] define the domain names to check for matching name mapping [RFC5731] define the domain names to check for matching
trademarks. The <launch:check> element contains the following child trademarks. The <launch:check> element contains the following child
elements: elements:
<launch:phase> The launch phase that SHOULD be "claims". <launch:phase> The launch phase that SHOULD be "claims".
skipping to change at page 18, line 4 skipping to change at page 15, line 49
<launch:cd> One or more <launch:cd> elements that contain the <launch:cd> One or more <launch:cd> elements that contain the
following child elements: following child elements:
<launch:name> Contains the fully qualified name of the queried <launch:name> Contains the fully qualified name of the queried
domain name. This element MUST contain an "exists" attribute domain name. This element MUST contain an "exists" attribute
whose value indicates if a matching trademark exists for the whose value indicates if a matching trademark exists for the
domain name. A value of "1" (or "true") means that a domain name. A value of "1" (or "true") means that a
matching trademark does exist for the claims launch phase. A matching trademark does exist for the claims launch phase. A
value of "0" (or "false") means that a matching trademark value of "0" (or "false") means that a matching trademark
does not exist. does not exist.
<launch:claimKey> Zero or more OPTIONAL claim keys that MAY be
<launch:claimKey> An OPTIONAL claim key that MAY be passed to a passed to a third-party trademark validator such as the
third-party trademark validator such as the Trademark Trademark Clearinghouse (TMCH) for querying the information
Clearinghouse (TMCH) for querying the information needed to needed to generate a Trademark Claims Notice. The
generate a Trademark Claims Notice. The <launch:claimKey> is <launch:claimKey> is used as the key for the query in place
used as the key for the query in place of the domain name to of the domain name to securely query the service without
securely query the service without using a well-known value using a well-known value like a domain name. The OPTIONAL
like a domain name. The OPTIONAL "validatorID" attribute is "validatorID" attribute is the Validator Identifier
the Validator Identifier (Section 2.2) whose value indicates (Section 2.2) whose value indicates which Trademark Validator
which Trademark Validator to query for the Claims Notice to query for the Claims Notice information, with the default
information, with the default being the ICANN TMCH. being the ICANN TMCH. The "validatorID" attribute MAY
reference a non-trademark claims clearinghouse identifer to
support other forms of claims notices.
Example Claims Check response when no matching trademarks are found Example Claims Check response when no matching trademarks are found
for the domain name example1.tld and matching trademarks are found for the domain name example1.tld, matching trademarks are found for
for the domain name example2.tld for the "claims" launch phase: the domain name example2.tld in the "tmch", matching trademarks are
found for domain name example3.tld in the "tmch" and "custom-tmch",
for the "claims" launch phase:
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: <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: <extension> S: <extension>
S: <launch:chkData S: <launch:chkData
S: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"> S: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S: <launch:phase>claims</launch:phase> S: <launch:phase>claims</launch:phase>
S: <launch:cd> S: <launch:cd>
S: <launch:name exists="0">example1.tld</launch:name> S: <launch:name exists="0">example1.tld</launch:name>
S: </launch:cd> S: </launch:cd>
S: <launch:cd> S: <launch:cd>
S: <launch:name exists="1">example2.tld</launch:name> S: <launch:name exists="1">example2.tld</launch:name>
S: <launch:claimKey validatorID="tmch"> S: <launch:claimKey validatorID="tmch">
S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001
S: </launch:claimKey> S: </launch:claimKey>
S: </launch:cd> S: </launch:cd>
S: <launch:cd>
S: <launch:name exists="1">example3.tld</launch:name>
S: <launch:claimKey validatorID="tmch">
S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001
S: </launch:claimKey>
S: <launch:claimKey validatorID="custom-tmch">
S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002
S: </launch:claimKey>
S: </launch:cd>
S: </launch:chkData> S: </launch:chkData>
S: </extension> S: </extension>
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>
3.1.2. Availability Check Form 3.1.2. Availability Check Form
skipping to change at page 21, line 26 skipping to change at page 20, line 26
C: <extension> C: <extension>
C: <launch:info C: <launch:info
C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"> C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C: <launch:phase>sunrise</launch:phase> C: <launch:phase>sunrise</launch:phase>
C: </launch:info> C: </launch:info>
C: </extension> C: </extension>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
If the query was successful, the server replies with a <launch: If the query was successful, the server replies with a
infData> element along with the regular EPP <resData>. The <launch: <launch:infData> element along with the regular EPP <resData>. The
infData> contains the following child elements: <launch:infData> contains the following child elements:
<launch:phase> The phase during which the application was submitted, <launch:phase> The phase during which the application was submitted,
or is associated with, that matches the associated <info> command or is associated with, that matches the associated <info> command
<launch:phase>. <launch:phase>.
<launch:applicationID> OPTIONAL Application Identifier of the Launch <launch:applicationID> OPTIONAL Application Identifier of the Launch
Application. Application.
<launch:status> OPTIONAL status of the Launch Application using one <launch:status> OPTIONAL status of the Launch Application using one
of the supported status values (Section 2.4). of the supported status values (Section 2.4).
<mark:mark> Zero or more <mark:mark> (Section 2.6.2) elements. <mark:mark> Zero or more <mark:mark> (Section 2.6.2) elements.
skipping to change at page 24, line 8 skipping to change at page 23, line 5
domain command. The <launch:create> element has an OPTIONAL "type" domain command. The <launch:create> element has an OPTIONAL "type"
attribute that defines the expected type of object ("application" or attribute that defines the expected type of object ("application" or
"registration") to create. The server SHOULD validate the "type" "registration") to create. The server SHOULD validate the "type"
attribute, when passed, against the type of object that will be attribute, when passed, against the type of object that will be
created. The <launch:create> element contains the following child created. The <launch:create> element contains the following child
elements: elements:
<launch:phase> The identifier for the launch phase. <launch:phase> The identifier for the launch phase.
<launch:codeMark> or <smd:signedMark> or <smd:encodedSignedMark> <launch:codeMark> or <smd:signedMark> or <smd:encodedSignedMark>
<launch:codeMark> Zero or more <launch:codeMark> elements. The <launch:codeMark> Zero or more <launch:codeMark> elements. The
<launch:codeMark> child elements are defined in the <launch: <launch:codeMark> child elements are defined in the
codeMark> element (Section 2.6.1) section. <launch:codeMark> element (Section 2.6.1) section.
<smd:signedMark> Zero or more <smd:signedMark> elements. The <smd:signedMark> Zero or more <smd:signedMark> elements. The
<smd:signedMark> child elements are defined in the <smd: <smd:signedMark> child elements are defined in the
signedMark> element (Section 2.6.3.1) section. <smd:signedMark> element (Section 2.6.3.1) section.
<smd:encodedSignedMark> Zero or more <smd:encodedSignedMark> <smd:encodedSignedMark> Zero or more <smd:encodedSignedMark>
elements. The <smd:encodedSignedMark> child elements are elements. The <smd:encodedSignedMark> child elements are
defined in the <smd:encodedSignedMark> element defined in the <smd:encodedSignedMark> element
(Section 2.6.3.2) section. (Section 2.6.3.2) section.
The following is an example <create> domain command using the The following is an example <create> domain command using the
<launch:create> extension, following the "code" validation model, <launch:create> extension, following the "code" validation model,
with multiple sunrise codes: with multiple sunrise codes:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
skipping to change at page 30, line 7 skipping to change at page 29, line 7
A <launch:create> element is sent along with the regular <create> A <launch:create> element is sent along with the regular <create>
domain command. The <launch:create> element has an OPTIONAL "type" domain command. The <launch:create> element has an OPTIONAL "type"
attribute that defines the expected type of object ("application" or attribute that defines the expected type of object ("application" or
"registration") to create. The server SHOULD validate the "type" "registration") to create. The server SHOULD validate the "type"
attribute, when passed, against the type of object that will be attribute, when passed, against the type of object that will be
created. The <launch:create> element contains the following child created. The <launch:create> element contains the following child
elements: elements:
<launch:phase> MUST contain the value of "claims" to indicate the <launch:phase> MUST contain the value of "claims" to indicate the
claims launch phase. claims launch phase.
<launch:notice> <launch:notice> One or more <launch:notice> elements that contain
the following child elements:
<launch:noticeID> Unique notice identifier for the Claims <launch:noticeID> Unique notice identifier for the Claims
Notice. The <launch:noticeID> element has an OPTIONAL Notice. The <launch:noticeID> element has an OPTIONAL
"validatorID" attribute is the Validator Identifier "validatorID" attribute is the Validator Identifier
(Section 2.2) whose value indicates which Trademark Validator (Section 2.2) whose value indicates which Trademark Validator
is the source of the Claims Notice, with the default being is the source of the Claims Notice, with the default being
the ICANN TMCH. the ICANN TMCH.
<launch:notAfter> Expiry of the claims notice. <launch:notAfter> Expiry of the claims notice.
<launch:acceptedDate> Contains the date and time that the Claims <launch:acceptedDate> Contains the date and time that the Claims
Notice was accepted. Notice was accepted.
The following is an example <create> domain command using the The following is an example <create> domain command using the
<launch:create> extension with the <launch:notice> information for <launch:create> extension with the <launch:notice> information for
the "claims" launch phase: the "tmch" and the "custom-tmch" validators, for the "claims" launch
phase:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <create> C: <create>
C: <domain:create C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.tld</domain:name> C: <domain:name>example.tld</domain:name>
C: <domain:registrant>jd1234</domain:registrant> C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact> C: <domain:contact type="admin">sh8013</domain:contact>
skipping to change at page 31, line 26 skipping to change at page 30, line 31
C: <domain:pw>2fooBAR</domain:pw> C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:create> C: </domain:create>
C: </create> C: </create>
C: <extension> C: <extension>
C: <launch:create C: <launch:create
C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"> C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C: <launch:phase>claims</launch:phase> C: <launch:phase>claims</launch:phase>
C: <launch:notice> C: <launch:notice>
C: <launch:noticeID validatorID="tmch"> C: <launch:noticeID validatorID="tmch">
C: 49FD46E6C4B45C55D4AC C: 370d0b7c9223372036854775807</launch:noticeID>
C: </launch:noticeID> C: <launch:notAfter>2014-06-19T10:00:00.0Z
C: <launch:notAfter>2012-06-19T10:00:10.0Z
C: </launch:notAfter> C: </launch:notAfter>
C: <launch:acceptedDate>2012-06-19T09:01:30.0Z C: <launch:acceptedDate>2014-06-19T09:00:00.0Z
C: </launch:acceptedDate>
C: </launch:notice>
C: <launch:notice>
C: <launch:noticeID validatorID="custom-tmch">
C: 470d0b7c9223654313275808</launch:noticeID>
C: <launch:notAfter>2014-06-19T10:00:00.0Z
C: </launch:notAfter>
C: <launch:acceptedDate>2014-06-19T09:00:30.0Z
C: </launch:acceptedDate> C: </launch:acceptedDate>
C: </launch:notice> C: </launch:notice>
C: </launch:create> C: </launch:create>
C: </extension> C: </extension>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
3.3.3. General Create Form 3.3.3. General Create Form
skipping to change at page 34, line 7 skipping to change at page 34, line 7
C: </launch:acceptedDate> C: </launch:acceptedDate>
C: </launch:notice> C: </launch:notice>
C: </launch:create> C: </launch:create>
C: </extension> C: </extension>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
3.3.5. Create Response 3.3.5. Create Response
If the create was successful, the server MAY reply with the <launch: If the create was successful, the server MAY reply with the
creData> element along with the regular EPP <resData> to indicate the <launch:creData> element along with the regular EPP <resData> to
server generated Application Identifier (Section 2.1), when multiple indicate the server generated Application Identifier (Section 2.1),
applications of a given domain name are supported; otherwise no when multiple applications of a given domain name are supported;
extension is included with the regular EPP <resData>. The <launch: otherwise no extension is included with the regular EPP <resData>.
creData> element contains the following child elements: The <launch:creData> element contains the following child elements:
<launch:phase> The phase of the application that mirrors the <launch:phase> The phase of the application that mirrors the
<launch:phase> element included in the <launch:create>. <launch:phase> element included in the <launch:create>.
<launch:applicationID> The application identifier of the <launch:applicationID> The application identifier of the
application. application.
An example response when multiple overlapping applications are An example response when multiple overlapping applications are
supported by the server: supported by the server:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
skipping to change at page 35, line 17 skipping to change at page 35, line 17
This extension defines additional elements to extend the EPP <update> This extension defines additional elements to extend the EPP <update>
command to be used in conjunction with the domain name mapping. command to be used in conjunction with the domain name mapping.
A client MUST NOT pass the extension on an EPP <update> command to a A client MUST NOT pass the extension on an EPP <update> command to a
server that does not support launch applications. A server that does server that does not support launch applications. A server that does
not support launch applications during its launch phase MUST return not support launch applications during its launch phase MUST return
an EPP error result code of 2102 when receiving an EPP <update> an EPP error result code of 2102 when receiving an EPP <update>
command with the extension. command with the extension.
Registry policies permitting, clients may update an application Registry policies permitting, clients may update an application
object by submitting an EPP <update> command along with a <launch: object by submitting an EPP <update> command along with a
update> element to indicate the application object to be updated. <launch:update> element to indicate the application object to be
The <launch:update> element contains the following child elements: updated. The <launch:update> element contains the following child
elements:
<launch:phase> The phase during which the application was submitted <launch:phase> The phase during which the application was submitted
or is associated with. or is associated with.
<launch:applicationID> The application identifier for which the <launch:applicationID> The application identifier for which the
client wishes to update. client wishes to update.
The following is an example <update> domain command with the <launch: The following is an example <update> domain command with the
update> extension to add and remove a name server of a sunrise <launch:update> extension to add and remove a name server of a
application with the application identifier "abc123": sunrise application with the application identifier "abc123":
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <update> C: <update>
C: <domain:update C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.tld</domain:name> C: <domain:name>example.tld</domain:name>
C: <domain:add> C: <domain:add>
C: <domain:ns> C: <domain:ns>
skipping to change at page 37, line 16 skipping to change at page 37, line 17
Registry policies permitting, clients MAY withdraw an application by Registry policies permitting, clients MAY withdraw an application by
submitting an EPP <delete> command along with a <launch:delete> submitting an EPP <delete> command along with a <launch:delete>
element to indicate the application object to be deleted. The element to indicate the application object to be deleted. The
<launch:delete> element contains the following child elements: <launch:delete> element contains the following child elements:
<launch:phase> The phase during which the application was submitted <launch:phase> The phase during which the application was submitted
or is associated with. or is associated with.
<launch:applicationID> The application identifier for which the <launch:applicationID> The application identifier for which the
client wishes to delete. client wishes to delete.
The following is an example <delete> domain command with the <launch: The following is an example <delete> domain command with the
delete> extension: <launch:delete> extension:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <delete> C: <delete>
C: <domain:delete C: <domain:delete
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.tld</domain:name> C: <domain:name>example.tld</domain:name>
C: </domain:delete> C: </domain:delete>
C: </delete> C: </delete>
skipping to change at page 39, line 51 skipping to change at page 39, line 50
<element name="info" type="launch:infoType"/> <element name="info" type="launch:infoType"/>
<element name="create" type="launch:createType"/> <element name="create" type="launch:createType"/>
<element name="update" type="launch:idContainerType"/> <element name="update" type="launch:idContainerType"/>
<element name="delete" type="launch:idContainerType"/> <element name="delete" type="launch:idContainerType"/>
<!-- <!--
Common container of id (identifier) element Common container of id (identifier) element
--> -->
<complexType name="idContainerType"> <complexType name="idContainerType">
<sequence> <sequence>
<element name="phase" type="launch:phaseType"/> <element name="phase"
<element name="applicationID" type="launch:applicationIDType"/> type="launch:phaseType"/>
<element name="applicationID"
type="launch:applicationIDType"/>
</sequence> </sequence>
</complexType> </complexType>
<!-- <!--
Definition for application identifier Definition for application identifier
--> -->
<simpleType name="applicationIDType"> <simpleType name="applicationIDType">
<restriction base="token"/> <restriction base="token"/>
</simpleType> </simpleType>
skipping to change at page 41, line 8 skipping to change at page 41, line 8
--> -->
<simpleType name="codeValue"> <simpleType name="codeValue">
<restriction base="token"> <restriction base="token">
<minLength value="1"/> <minLength value="1"/>
</restriction> </restriction>
</simpleType> </simpleType>
<complexType name="codeType"> <complexType name="codeType">
<simpleContent> <simpleContent>
<extension base="launch:codeValue"> <extension base="launch:codeValue">
<attribute name="validatorID" <attribute name="validatorID"
type="launch:validatorIDType" use="optional"/> type="launch:validatorIDType" use="optional"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
<!-- <!--
Definition for the notice identifier Definition for the notice identifier
--> -->
<simpleType name="noticeIDValue"> <simpleType name="noticeIDValue">
<restriction base="token"> <restriction base="token">
<minLength value="1"/> <minLength value="1"/>
</restriction> </restriction>
</simpleType> </simpleType>
<complexType name="noticeIDType"> <complexType name="noticeIDType">
<simpleContent> <simpleContent>
<extension base="launch:noticeIDValue"> <extension base="launch:noticeIDValue">
<attribute name="validatorID" <attribute name="validatorID"
type="launch:validatorIDType" use="optional"/> type="launch:validatorIDType" use="optional"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
<!-- <!--
Definition for the validator identifier Definition for the validator identifier
--> -->
<simpleType name="validatorIDType"> <simpleType name="validatorIDType">
<restriction base="token"> <restriction base="token">
<minLength value="1"/> <minLength value="1"/>
skipping to change at page 42, line 50 skipping to change at page 42, line 50
<sequence> <sequence>
<element name="phase" type="launch:phaseType"/> <element name="phase" type="launch:phaseType"/>
<choice minOccurs="0"> <choice minOccurs="0">
<element name="codeMark" type="launch:codeMarkType" <element name="codeMark" type="launch:codeMarkType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element ref="smd:abstractSignedMark" <element ref="smd:abstractSignedMark"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element ref="smd:encodedSignedMark" <element ref="smd:encodedSignedMark"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</choice> </choice>
<element name="notice" minOccurs="0" <element name="notice"
type="launch:createNoticeType"/> type="launch:createNoticeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
<attribute name="type" type="launch:objectType"/> <attribute name="type" type="launch:objectType"/>
</complexType> </complexType>
<!-- <!--
Type of launch object Type of launch object
--> -->
<simpleType name="objectType"> <simpleType name="objectType">
<restriction base="token"> <restriction base="token">
<enumeration value="application"/> <enumeration value="application"/>
skipping to change at page 44, line 40 skipping to change at page 44, line 43
<element name="phase" type="launch:phaseType"/> <element name="phase" type="launch:phaseType"/>
<element name="cd" type="launch:cdType" <element name="cd" type="launch:cdType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="cdType"> <complexType name="cdType">
<sequence> <sequence>
<element name="name" type="launch:cdNameType"/> <element name="name" type="launch:cdNameType"/>
<element name="claimKey" type="launch:claimKeyType" <element name="claimKey" type="launch:claimKeyType"
minOccurs="0"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="cdNameType"> <complexType name="cdNameType">
<simpleContent> <simpleContent>
<extension base="eppcom:labelType"> <extension base="eppcom:labelType">
<attribute name="exists" type="boolean" <attribute name="exists" type="boolean"
use="required"/> use="required"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
<complexType name="claimKeyType"> <complexType name="claimKeyType">
<simpleContent> <simpleContent>
<extension base="token"> <extension base="token">
<attribute name="validatorID" <attribute name="validatorID"
type="launch:validatorIDType" use="optional"/> type="launch:validatorIDType" use="optional"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
<!-- <!--
<info> response elements <info> response elements
--> -->
<complexType name="infDataType"> <complexType name="infDataType">
<sequence> <sequence>
<element name="phase" type="launch:phaseType"/> <element name="phase" type="launch:phaseType"/>
skipping to change at page 47, line 12 skipping to change at page 47, line 12
noticeID, timestamp, and the source elements. noticeID, timestamp, and the source elements.
9. Added the class and effectiveDate elements to mark. 9. Added the class and effectiveDate elements to mark.
6.5. Change from 04 to 05 6.5. Change from 04 to 05
1. Removed reference to <smd:zone> in the <smd:signedMark> example. 1. Removed reference to <smd:zone> in the <smd:signedMark> example.
2. Incorporated feedback from Bernhard Reutner-Fischer on the 2. Incorporated feedback from Bernhard Reutner-Fischer on the
provreg mail list. provreg mail list.
3. Added missing launch XML prefix to applicationIDType reference in 3. Added missing launch XML prefix to applicationIDType reference in
the idContainerType of the Launch Schema. the idContainerType of the Launch Schema.
4. Added missing description of the <mark:pc> element in the <mark: 4. Added missing description of the <mark:pc> element in the
addr> element. <mark:addr> element.
5. Updated note on replication of the EPP contact mapping elements 5. Updated note on replication of the EPP contact mapping elements
in the Mark Contact section. in the Mark Contact section.
6.6. Change from 05 to 06 6.6. Change from 05 to 06
1. Removed the definition of the mark-1.0 and signedMark-1.0 and 1. Removed the definition of the mark-1.0 and signedMark-1.0 and
replaced with reference to draft-lozano-smd, that contains the replaced with reference to draft-lozano-smd, that contains the
definition for the mark, signed marked, and encoded signed mark. definition for the mark, signed marked, and encoded signed mark.
2. Split the <launch:timestamp> into <launch:generatedDate> and 2. Split the <launch:timestamp> into <launch:generatedDate> and
<launch:acceptedDate> based on feedback from Trung Tran. <launch:acceptedDate> based on feedback from Trung Tran.
skipping to change at page 47, line 47 skipping to change at page 47, line 47
Application Identifier section. Application Identifier section.
4. Added the Poll Messaging section to define the use of poll 4. Added the Poll Messaging section to define the use of poll
messaging for intermediate state transitions and pending action messaging for intermediate state transitions and pending action
poll messaging for final state transitions. poll messaging for final state transitions.
6.8. Change from 07 to 08 6.8. Change from 07 to 08
1. Added support for use of the launch statuses and poll messaging 1. Added support for use of the launch statuses and poll messaging
for Launch Registrations based on feedback from Sharon Wodjenski for Launch Registrations based on feedback from Sharon Wodjenski
and Trung Tran. and Trung Tran.
2. Incorporated changes based on updates or clarifications in 2. Incorporated changes based on updates or clarifications in draft-
draft-lozano-tmch-func-spec-01, which include: lozano-tmch-func-spec-01, which include:
1. Removed the unused <launch:generatedDate> element. 1. Removed the unused <launch:generatedDate> element.
2. Removed the <launch:source> element. 2. Removed the <launch:source> element.
3. Added the <launch:notAfter> element based on the required 3. Added the <launch:notAfter> element based on the required
<tmNotice:notAfter> element. <tmNotice:notAfter> element.
6.9. Change from 08 to 09 6.9. Change from 08 to 09
1. Made <choice> element optional in <launch:create> to allow 1. Made <choice> element optional in <launch:create> to allow
passing just the <launch:phase> in <launch:create> per request passing just the <launch:phase> in <launch:create> per request
skipping to change at page 48, line 33 skipping to change at page 48, line 33
6. Replaced the "claims1" and "claims2" phases with the "claims" 6. Replaced the "claims1" and "claims2" phases with the "claims"
phase based on discussion on the provreg list. phase based on discussion on the provreg list.
7. Added support for a mixed create model (Sunrise Create Model and 7. Added support for a mixed create model (Sunrise Create Model and
Claims Create Model), where a trademark (encoded signed mark, Claims Create Model), where a trademark (encoded signed mark,
etc.) and notice can be passed, based on a request from James etc.) and notice can be passed, based on a request from James
Mitchell. Mitchell.
8. Added text for the handling of the overlapping "claims" and 8. Added text for the handling of the overlapping "claims" and
"landrush" launch phases. "landrush" launch phases.
9. Added support for two check forms (claims check form and 9. Added support for two check forms (claims check form and
availability check form) based on a request from James Mitchell. availability check form) based on a request from James Mitchell.
The availability check form was based on the text in The availability check form was based on the text in draft-rbp-
draft-rbp-application-epp-mapping. application-epp-mapping.
6.10. Change from 09 to 10 6.10. Change from 09 to 10
1. Changed noticeIDType from base64Binary to token to be compatible 1. Changed noticeIDType from base64Binary to token to be compatible
with draft-lozano-tmch-func-spec-05. with draft-lozano-tmch-func-spec-05.
2. Changed codeType from base64Binary to token to be more generic. 2. Changed codeType from base64Binary to token to be more generic.
3. Updated based on feedback from Alexander Mayrhofer, which 3. Updated based on feedback from Alexander Mayrhofer, which
include: include:
1. Changed "extension to the domain name extension" to 1. Changed "extension to the domain name extension" to
"extension to the domain name mapping". "extension to the domain name mapping".
2. Changed use of 2004 return code to 2306 return code when 2. Changed use of 2004 return code to 2306 return code when
phase passed mismatches active phase and sub-phase. phase passed mismatches active phase and sub-phase.
3. Changed description of "allocated" and "rejected" statuses. 3. Changed description of "allocated" and "rejected" statuses.
4. Moved sentence on a synchronous <domain:create> command 4. Moved sentence on a synchronous <domain:create> command
without the use of an intermediate application, then an without the use of an intermediate application, then an
Application Identifier MAY not be needed to the Application Application Identifier MAY not be needed to the Application
Identifier section. Identifier section.
skipping to change at page 49, line 6 skipping to change at page 49, line 6
"extension to the domain name mapping". "extension to the domain name mapping".
2. Changed use of 2004 return code to 2306 return code when 2. Changed use of 2004 return code to 2306 return code when
phase passed mismatches active phase and sub-phase. phase passed mismatches active phase and sub-phase.
3. Changed description of "allocated" and "rejected" statuses. 3. Changed description of "allocated" and "rejected" statuses.
4. Moved sentence on a synchronous <domain:create> command 4. Moved sentence on a synchronous <domain:create> command
without the use of an intermediate application, then an without the use of an intermediate application, then an
Application Identifier MAY not be needed to the Application Application Identifier MAY not be needed to the Application
Identifier section. Identifier section.
5. Restructured the Mark Validation Models section to include 5. Restructured the Mark Validation Models section to include
the "<launch:codeMark> element" sub-section, the "<mark: the "<launch:codeMark> element" sub-section, the
mark> element" sub-section, and the Digital Signature sub- "<mark:mark> element" sub-section, and the Digital Signature
section. sub-section.
6. Changed "Registries may" to "Registries MAY". 6. Changed "Registries may" to "Registries MAY".
7. Changed "extensed" to "extended" in "Availability Check 7. Changed "extensed" to "extended" in "Availability Check
Form" section. Form" section.
8. Broke the mix of create forms in the "EPP <create> Command" 8. Broke the mix of create forms in the "EPP <create> Command"
section to a fourth "Mixed Create Form" with its own sub- section to a fourth "Mixed Create Form" with its own sub-
section. section.
9. Removed "displayed or" from "displayed or accepted" in the 9. Removed "displayed or" from "displayed or accepted" in the
<launch:acceptedDate> description. <launch:acceptedDate> description.
10. Replaced "given domain name is supported" with "given domain 10. Replaced "given domain name is supported" with "given domain
name are supported" in the "Create Response" section. name are supported" in the "Create Response" section.
skipping to change at page 49, line 48 skipping to change at page 49, line 48
O'Connell. O'Connell.
2. Removed domain:exDate element from example in section 3.3.5 based 2. Removed domain:exDate element from example in section 3.3.5 based
on a request from Seth Goldman on the provreg list. on a request from Seth Goldman on the provreg list.
3. Added clarifying text for clients not passing the launch 3. Added clarifying text for clients not passing the launch
extension on update and delete commands to servers that do not extension on update and delete commands to servers that do not
support launch applications based on a request from Sharon support launch applications based on a request from Sharon
Wodjenski on the provreg list. Wodjenski on the provreg list.
6.13. Change from 12 to WG 00 6.13. Change from 12 to WG 00
1. Changed to eppext working group draft by changing 1. Changed to eppext working group draft by changing draft-tan-epp-
draft-tan-epp-launchphase to draft-ietf-eppext-launchphase and by launchphase to draft-ietf-eppext-launchphase and by changing
changing references of draft-lozano-tmch-smd to references of draft-lozano-tmch-smd to draft-ietf-eppext-tmch-
draft-ietf-eppext-tmch-smd. smd.
6.14. Change WG 00 to WG 01 6.14. Change WG 00 to WG 01
1. Removed text associated with support for the combining of status 1. Removed text associated with support for the combining of status
values based on feedback from Patrick Mevzek on the provreg values based on feedback from Patrick Mevzek on the provreg
mailing list, discussion on the eppext mailing list, and mailing list, discussion on the eppext mailing list, and
discussion at the eppext IETF meeting on March 6, 2014. discussion at the eppext IETF meeting on March 6, 2014.
6.15. Change WG 01 to WG 02
1. Changed the <launch:claim> element to be zero or more elements
and the <launch:notice> element to be one or more elements in the
Claims Create Form. These changes were needed to be able to
support more than one concurrent claims services.
7. IANA Considerations 7. 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]. One URI conforming to a registry mechanism described in [RFC3688]. One URI
assignment has been registered by the IANA. assignment has been registered by the IANA.
Registration request for the Launch namespace: Registration request for the Launch namespace:
URI: urn:ietf:params:xml:ns:launch-1.0 URI: urn:ietf:params:xml:ns:launch-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
skipping to change at page 50, line 45 skipping to change at page 51, line 5
As information contained within an application, or even the mere fact As information contained within an application, or even the mere fact
that an application exists may be confidential. Any attempt to that an application exists may be confidential. Any attempt to
operate on an application object by an unauthorized client MUST be operate on an application object by an unauthorized client MUST be
rejected with an EPP 2201 (authorization error) return code. Server rejected with an EPP 2201 (authorization error) return code. Server
policy may allow <info> operation with filtered output by clients policy may allow <info> operation with filtered output by clients
other than the sponsoring client, in which case the <domain:infData> other than the sponsoring client, in which case the <domain:infData>
and <launch:infData> response SHOULD be filtered to include only and <launch:infData> response SHOULD be filtered to include only
fields that are publicly accessible. fields that are publicly accessible.
9. Normative References 9. References
9.1. Normative References
[I-D.ietf-eppext-tmch-smd]
Lozano, G., "Mark and Signed Mark Objects Mapping", draft-
ietf-eppext-tmch-smd-00 (work in progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009. STD 69, RFC 5730, August 2009.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, August 2009. Domain Name Mapping", STD 69, RFC 5731, August 2009.
[draft-ietf-eppext-tmch-smd] 9.2. URIs
Lozano, G., "Mark and Signed Mark Objects Mapping".
[1] <http://tools.ietf.org/html/draft-ietf-eppext-tmch-smd> [1] http://tools.ietf.org/html/draft-lozano-tmch-func-spec
[2] <http://tools.ietf.org/html/draft-lozano-tmch-func-spec> [2] http://tools.ietf.org/html/draft-lozano-tmch-func-spec
Authors' Addresses Authors' Addresses
James Gould James Gould
VeriSign, Inc. VeriSign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US US
Email: jgould@verisign.com Email: jgould@verisign.com
 End of changes. 59 change blocks. 
165 lines changed or deleted 215 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/