idnits 2.17.1 draft-ietf-eppext-launchphase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2014) is 3748 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track W. Tan 5 Expires: July 25, 2014 Cloud Registry 6 G. Brown 7 CentralNic Ltd 8 January 21, 2014 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-ietf-eppext-launchphase-00 13 Abstract 15 This document describes an Extensible Provisioning Protocol (EPP) 16 extension mapping for the provisioning and management of domain name 17 registrations and applications during the launch of a domain name 18 registry. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 25, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 56 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Application Identifier . . . . . . . . . . . . . . . . . . 5 58 2.2. Validator Identifier . . . . . . . . . . . . . . . . . . . 5 59 2.3. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 7 61 2.4.1. State Transition . . . . . . . . . . . . . . . . . . . 9 62 2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . . 10 63 2.6. Mark Validation Models . . . . . . . . . . . . . . . . . . 13 64 2.6.1. element . . . . . . . . . . . . . . 14 65 2.6.2. element . . . . . . . . . . . . . . . . . 15 66 2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 15 67 2.6.3.1. element . . . . . . . . . . . . . 15 68 2.6.3.2. element . . . . . . . . . 15 69 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 15 70 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 16 71 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 16 72 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 18 73 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 19 74 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 23 75 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 23 76 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 29 77 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 31 78 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 32 79 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 34 80 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 35 81 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 36 82 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 37 83 3.7. EPP Command . . . . . . . . . . . . . . . . . . 38 84 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 38 85 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 38 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 87 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 45 88 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 46 89 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 46 90 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 46 91 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 46 92 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 47 93 6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . . 47 94 6.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . . 47 95 6.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . . 47 96 6.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . . 48 97 6.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . . 48 98 6.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . . 49 99 6.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . . 49 100 6.13. Change from 12 to WG 00 . . . . . . . . . . . . . . . . . 49 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 103 9. Normative References . . . . . . . . . . . . . . . . . . . . . 50 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 106 1. Introduction 108 This document describes an extension mapping for version 1.0 of the 109 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 110 specifies a flexible schema that can be used to implement several 111 common use cases related to the provisioning and management of domain 112 name registrations and applications during the launch of a domain 113 name registry. 115 It is typical for domain registries to operate in special modes 116 during their initial launch to facilitate allocation of domain names, 117 often according to special rules. This document uses the term 118 "launch phase" and the shorter form "launch" to refer to such a 119 period. 121 The EPP domain name mapping [RFC5731] is designed for the steady- 122 state operation of a registry. During a launch period, the model in 123 place may be different from what is defined in the EPP domain name 124 mapping [RFC5731]. For example, registries often accept multiple 125 applications for the same domain name during the "Sunrise" launch 126 phase, referred to as a Launch Application. A Launch Registration 127 refers to a registration made during a launch phase when the server 128 uses a "first-come, first-served" model. Even in a "first-come, 129 first-served" model, additional steps and information might be 130 required, such as trademark information. In addition, the TMCH 131 Functional Specification [1] defines a registry interface for the 132 Trademark Claims or "claims" launch phase that includes support for 133 presenting a Trademark Claims Notice to the Registrant. This 134 document proposes an extension to the domain name mapping in order to 135 provide a uniform interface for the management of Launch Applications 136 and Launch Registrations in launch phases. 138 1.1. Conventions Used in This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 XML is case sensitive. Unless stated otherwise, XML specifications 145 and examples provided in this document MUST be interpreted in the 146 character case presented in order to develop a conforming 147 implementation. 149 In examples, "C:" represents lines sent by a protocol client and "S:" 150 represents lines returned by a protocol server. Indentation and 151 white space in examples are provided only to illustrate element 152 relationships and are not a REQUIRED feature of this protocol. 154 "launch-1.0" is used as an abbreviation for 155 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 156 "launch" is used, but implementations MUST NOT depend on it and 157 instead employ a proper namespace-aware XML parser and serializer to 158 interpret and output the XML documents. 160 "signedMark-1.0" is used as an abbreviation for 161 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 162 [draft-ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is 163 used, but implementations MUST NOT depend on it and instead employ a 164 proper namespace-aware XML parser and serializer to interpret and 165 output the XML documents. 167 "mark-1.0" is used as an abbreviation for 168 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 169 [draft-ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is 170 used, but implementations MUST NOT depend on it and instead employ a 171 proper namespace-aware XML parser and serializer to interpret and 172 output the XML documents. 174 2. Object Attributes 176 This extension adds additional elements to the EPP domain name 177 mapping [RFC5731]. Only those new elements are described here. 179 2.1. Application Identifier 181 Servers MAY allow multiple applications, referred to as a Launch 182 Application, of the same domain name during its launch phase 183 operations. Upon receiving a valid request to create a Launch 184 Application, the server MUST create an application object 185 corresponding to the request, assign an application identifier for 186 the Launch Application, set the [RFC5731] pendingCreate status, and 187 return the application identifier to the client with the element. In order to facilitate correlation, all 189 subsequent launch operations on the Launch Application MUST be 190 qualified by the previously assigned application identifier using the 191 element. 193 If the command processes a request synchronously 194 without the use of an intermediate Launch Application, then an 195 application identifier MAY not be needed. 197 2.2. Validator Identifier 199 The Validator Identifier is the unique identifier for a Trademark 200 Validator that validates marks and has a repository of validated 201 marks. The OPTIONAL "validatorID" attribute is used to define the 202 Validator Identifier of the Trademark Validator. Registries MAY 203 support more than one Third Party Trademark Validator. The Internet 204 Corporation for Assigned Names and Numbers (ICANN) Trademark 205 Clearinghouse (TMCH) is the default Trademark Validator and is 206 reserved the Validator Identifier of "tmch". If the ICANN TMCH is 207 not used or multiple Trademark Validators are used, the Validator 208 Identifier MUST be defined using the "validatorID" attribute. 210 The Validator Identifier MAY be related to one or more issuer 211 identifiers of the element and the element defined 212 in [draft-ietf-eppext-tmch-smd]. Both the Validator Identifier and 213 the Issuer Identifier used MUST be unique. The list of validator 214 identifiers and the relationship to issuer identifiers is out of 215 scope for this document. 217 2.3. Launch Phases 219 The server MAY support multiple launch phases sequentially or 220 simultaneously. The element MUST be included by the 221 client to define the target launch phase of the command. The server 222 SHOULD validate the phase and MAY validate the sub-phase of the 223 element against the active phase and OPTIONAL sub- 224 phase of the server on a create command, and return an EPP error 225 result code of 2306 if there is a mismatch. 227 The following launch phase values are defined: 228 sunrise The phase during which trademark holders can submit 229 registrations or applications with trademark information that can 230 be validated by the server. 231 landrush A post-Sunrise phase when non-trademark holders are allowed 232 to register domain names with steps taken to address a large 233 volume of initial registrations. 234 claims The Trademark Claims phase, as defined in the TMCH Functional 235 Specification [2], in which a Claims Notice must be displayed to a 236 prospective registrant of a domain name that matches trademarks. 237 open A post-launch phase that is also referred to as "steady state". 238 Servers MAY require additional trademark protection during this 239 phase. 240 custom A custom server launch phase that is defined using the "name" 241 attribute. 243 For extensibility, the element includes an OPTIONAL 244 "name" attribute that can define a sub-phase or the full name of the 245 phase when the element has the "custom" value. For 246 example, the "claims" launch phase could have two sub-phases that 247 include "landrush" and "open". 249 Launch phases MAY overlap to support the "claims" launch phase, 250 defined in the TMCH Functional Specification [2], and to support a 251 traditional "landrush" launch phase. The overlap of the "claims" and 252 "landrush" launch phases SHOULD be handled by setting "claims" as the 253 value and setting "landrush" as the sub-phase with the 254 "name" attribute. For example, the element SHOULD be 255 claims. 257 2.4. Status Values 259 A Launch Application or Launch Registration object MAY have a launch 260 status value. The element is used to convey the 261 launch status pertaining to the object, beyond what is specified in 262 the object mapping. A Launch Application or Launch Registration MUST 263 set the [RFC5731] "pendingCreate" status if a launch status is 264 supported and the launch status is not one of the final statuses, 265 including the "allocated" and "rejected" statuses. 267 The following status values are defined using the required "s" 268 attribute: 269 pendingValidation: The initial state of a newly-created application 270 or registration object. The application or registration requires 271 validation, but the validation process has not yet completed. 272 validated: The application or registration meets relevant registry 273 rules. 274 invalid: The application or registration does not validate according 275 to registry rules. Server policies permitting, it may transition 276 back into "pendingValidation" for revalidation, after 277 modifications are made to ostensibly correct attributes that 278 caused the validation failure. 279 pendingAllocation: The allocation of the application or registration 280 is pending based on the results of some out-of-band process (for 281 example, an auction). 282 allocated: The object corresponding to the application or 283 registration has been provisioned. Is a possible end state of an 284 application or registration object. 285 rejected: The application or registration object was not 286 provisioned. Is a possible end state of an application or 287 registration object. 288 custom: A custom status that is defined using the "name" attribute. 290 Each status value MAY be accompanied by a string of human-readable 291 text that describes the rationale for the status applied to the 292 object. The OPTIONAL "lang" attribute MAY be present to identify the 293 language if the negotiated value is something other than the default 294 value of "en" (English). 296 For extensibility the element includes an OPTIONAL 297 "name" attribute that can define a sub-status or the full name of the 298 status when the status value is "custom". The server SHOULD NOT use 299 the "custom" status value. 301 Certain status values MAY be combined. For example, an application 302 or registration may be both "invalid" and "rejected". Additionally, 303 certain statuses MAY be skipped. For example, an application or 304 registration MAY immediately start at the "allocated" status or an 305 application or registration MAY skip the "pendingAllocation" status. 306 If the launch phase does not require validation of a request, an 307 application or registration MAY immediately skip to 308 "pendingAllocation". 310 2.4.1. State Transition 312 | request 313 | 314 | +--------------------------+ 315 | | | 316 v v | 317 +-------------------+ | 318 | | | 319 | pendingValidation +--------------+ | 320 | | | | 321 +---------+---------+ | | 322 | | | 323 | | | 324 v v | 325 +-----------+ +---------+ | 326 | | | | | 327 | validated | | invalid +--+ 328 | | | | 329 +-----+-----+ +----+----+ 330 | | 331 | | 332 v | 333 +-------------------+ | 334 | | | 335 | pendingAllocation +-----------+ | 336 | | | | 337 +---------+---------+ | | 338 | | | 339 | | | 340 | | | 341 | | | 342 | | | 343 v v v 344 +---------+ +--------+ 345 / \ / \ 346 | allocated | | rejected | 347 \ / \ / 348 +---------+ +--------+ 350 Figure 1 352 2.5. Poll Messaging 354 A Launch Application MUST and a Launch Registration MAY be handled as 355 a domain name of [RFC5731] in "pendingCreate" status, with the launch 356 status values defined in Section 2.4. As a Launch Application or 357 Launch Registration transitions between the status values defined in 358 Section 2.4, the server SHOULD insert poll messages, per [RFC5730], 359 for the applicable intermediate statuses, including the 360 "pendingValidation", "validated", "pendingAllocation, and "invalid" 361 statuses, using the element with the extension. The element MAY contain non- 363 mandatory information, like contact and name server information. 364 Also, further extensions that would normally be included in the 365 response of a command, per [RFC5731], MAY be included. 366 For the final statuses, including the "allocated" and "rejected" 367 statuses, the server MUST insert a poll message, per 368 [RFC5731], with the extension. 370 The following is an example poll message for a Launch Application 371 that has transitioned to the "pendingAllocation" state. 373 S: 374 S: 375 S: 376 S: 377 S: Command completed successfully; ack to dequeue 378 S: 379 S: 380 S: 2013-04-04T22:01:00.0Z 381 S: Application pendingAllocation. 382 S: 383 S: 384 S: 386 S: example.tld 387 S: ... 388 S: 389 S: 390 S: 391 S: 393 S: sunrise 394 S: abc123 395 S: 396 S: 397 S: 398 S: 399 S: ABC-12345 400 S: 54322-XYZ 401 S: 402 S: 403 S: 404 The following is an example poll message for an 405 "allocated" Launch Application. 407 S: 408 S: 409 S: 410 S: 411 S: Command completed successfully; ack to dequeue 412 S: 413 S: 414 S: 2013-04-04T22:01:00.0Z 415 S: Application successfully allocated. 416 S: 417 S: 418 S: 420 S: example.tld 421 S: 422 S: ABC-12345 423 S: 54321-XYZ 424 S: 425 S: 2013-04-04T22:00:00.0Z 426 S: 427 S: 428 S: 429 S: 431 S: sunrise 432 S: abc123 433 S: 434 S: 435 S: 436 S: 437 S: BCD-23456 438 S: 65432-WXY 439 S: 440 S: 441 S: 442 The following is an example poll message for an 443 "allocated" Launch Registration. 445 S: 446 S: 447 S: 448 S: 449 S: Command completed successfully; ack to dequeue 450 S: 451 S: 452 S: 2013-04-04T22:01:00.0Z 453 S: Registration successfully allocated. 454 S: 455 S: 456 S: 458 S: example.tld 459 S: 460 S: ABC-12345 461 S: 54321-XYZ 462 S: 463 S: 2013-04-04T22:00:00.0Z 464 S: 465 S: 466 S: 467 S: 469 S: sunrise 470 S: 471 S: 472 S: 473 S: 474 S: BCD-23456 475 S: 65432-WXY 476 S: 477 S: 478 S: 480 2.6. Mark Validation Models 482 A server MUST support at least one of the following models for 483 validating trademark information: 485 code Use of a mark code by itself to validate that the mark matches 486 the domain name. This model is supported using the element with just the element. 489 mark The mark information is passed without any other validation 490 element. The server will use some custom form of validation to 491 validate that the mark information is authentic. This model is 492 supported using the element with just the (Section 2.6.2) element. 494 code with mark: A code is used along with the mark information by 495 the server to validate the mark utilizing an external party. The 496 code represents some form of secret that matches the mark 497 information passed. This model is supported using the element that contains both the and the 499 (Section 2.6.2) elements. 500 signed mark: The mark information is digitally signed as described 501 in the Digital Signature (Section 2.6.3) section. The digital 502 signature can be directly validated by the server using the public 503 key of the external party that created the signed mark using its 504 private key. This model is supported using the 505 (Section 2.6.3.1) and (Section 2.6.3.2) 506 elements. 508 More than one , (Section 2.6.3.1), 509 or (Section 2.6.3.2) element MAY be 510 specified. The maximum number of marks per domain name is up to 511 server policy. 513 2.6.1. element 515 The element that is used by the "code", "mark", and 516 "code with mark" validation models, has the following child elements: 518 : OPTIONAL mark code used to validate the 519 (Section 2.6.2) information. The mark code is be a mark-specific 520 secret that the server can verify against a third party. The 521 OPTIONAL "validatorID" attribute is the Validator Identifier 522 (Section 2.2) whose value indicates which Trademark Validator that 523 the code originated from, with no default value. 524 : OPTIONAL mark information with child elements defined 525 in the Mark (Section 2.6.2) section. 527 The following is an example element with both a 528 and (Section 2.6.2) element. 530 531 532 49FD46E6C4B45C55D4AC 533 534 ... 535 536 538 2.6.2. element 540 A element describes an applicant's prior right to a given 541 domain name that is used with the "mark", "mark with code", and the 542 "signed mark" validation models. The element is defined 543 in [draft-ietf-eppext-tmch-smd]. A new mark format can be supported 544 by creating a new XML schema for the mark that has an element that 545 substitutes for the element from 546 [draft-ietf-eppext-tmch-smd]. 548 2.6.3. Digital Signature 550 Digital signatures MAY be used by the server to validate either the 551 mark information, when using the "signed mark" validation model with 552 the (Section 2.6.3.1) element or the (Section 2.6.3.2) element. 555 2.6.3.1. element 557 The element contains the digitally signed mark 558 information. The element is defined in 559 [draft-ietf-eppext-tmch-smd]. A new signed mark format can be 560 supported by creating a new XML schema for the signed mark that has 561 an element that substitutes for the element 562 from [draft-ietf-eppext-tmch-smd]. 564 2.6.3.2. element 566 The element contains an encoded form of the 567 digitally signed (Section 2.6.3.1) element. The 568 element is defined in 569 [draft-ietf-eppext-tmch-smd]. A new encoded signed mark format can 570 be supported by creating a new XML schema for the encoded signed mark 571 that has an element that substitutes for the 572 element from [draft-ietf-eppext-tmch-smd]. 574 3. EPP Command Mapping 576 A detailed description of the EPP syntax and semantics can be found 577 in the EPP core protocol specification [RFC5730]. The command 578 mappings described here are specifically for use in the Launch Phase 579 Extension. 581 This mapping is designed to be flexible, requiring only a minimum set 582 of required elements. 584 While it is meant to serve several use cases, it does not prescribe 585 any interpretation by the client or server. Such processing is 586 typically highly policy-dependent and therefore specific to 587 implementations. 589 Operations on application objects are done via one or more of the 590 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 591 Registries MAY choose to support a subset of the operations. 593 3.1. EPP Command 595 There are two forms of the extension to the EPP command: the 596 Claims Check Form (Section 3.1.1) and the Availability Check Form 597 (Section 3.1.2). The element "type" attribute defines 598 the form, with the value of "claims" for the Claims Check Form 599 (Section 3.1.1) and with the value of "avail" for the Availability 600 Check Form (Section 3.1.2). The default value of the "type" 601 attribute is "claims". The forms supported by the server is 602 determined by server policy. The server MUST return an EPP error 603 result code of 2307 if it receives a check form that is not 604 supported. 606 3.1.1. Claims Check Form 608 The Claims Check Form defines a new command called the Claims Check 609 Command that is used to determine whether or not there are any 610 matching trademarks, in the specified launch phase, for each domain 611 name passed in the command. The availability check information 612 defined in the EPP domain name mapping [RFC5731] MUST NOT be returned 613 for the Claims Check Command. This form is the default form and MAY 614 be explicitly identified by setting the "type" 615 attribute to "claims". 617 Instead of returning whether the domain name is available, the Claims 618 Check Command will return whether or not at least one matching 619 trademark exists for the domain name. If there is at least one 620 matching trademark that exists for the domain name, a element is returned. The client MAY then use the value of 622 the element to obtain information needed to 623 generate the Trademark Claims Notice from Trademark Validator based 624 on the Validator Identifier (Section 2.2). The unique notice 625 identifier of the Trademark Claims Notice MUST be passed in the 626 element of the extension to the Create Command 627 (Section 3.3). 629 The elements in the EPP command of EPP domain 630 name mapping [RFC5731] define the domain names to check for matching 631 trademarks. The element contains the following child 632 elements: 634 The launch phase that SHOULD be "claims". 636 Example Claims Check command using the domain command and the 637 extension with the "type" explicitly set to "claims", 638 to determine if "example1.tld" and "example2.tld" have any matching 639 trademarks during the "claims" launch phase: 641 C: 642 C: 643 C: 644 C: 645 C: 647 C: example1.tld 648 C: example2.tld 649 C: 650 C: 651 C: 652 C: 655 C: claims 656 C: 657 C: 658 C: ABC-12345 659 C: 660 C: 662 If the command has been processed successfully, the EPP 663 MUST contain an element that 664 identifies the launch namespace. The element 665 contains the following child elements: 667 The launch phase that SHOULD be "claims". 668 One or more elements that contain the 669 following child elements: 671 Contains the fully qualified name of the queried 672 domain name. This element MUST contain an "exists" attribute 673 whose value indicates if a matching trademark exists for the 674 domain name. A value of "1" (or "true") means that a 675 matching trademark does exist for the claims launch phase. A 676 value of "0" (or "false") means that a matching trademark 677 does not exist. 679 An OPTIONAL claim key that MAY be passed to a 680 third-party trademark validator such as the Trademark 681 Clearinghouse (TMCH) for querying the information needed to 682 generate a Trademark Claims Notice. The is 683 used as the key for the query in place of the domain name to 684 securely query the service without using a well-known value 685 like a domain name. The OPTIONAL "validatorID" attribute is 686 the Validator Identifier (Section 2.2) whose value indicates 687 which Trademark Validator to query for the Claims Notice 688 information, with the default being the ICANN TMCH. 690 Example Claims Check response when no matching trademarks are found 691 for the domain name example1.tld and matching trademarks are found 692 for the domain name example2.tld for the "claims" launch phase: 694 S: 695 S: 696 S: 697 S: 698 S: Command completed successfully 699 S: 700 S: 701 S: 703 S: claims 704 S: 705 S: example1.tld 706 S: 707 S: 708 S: example2.tld 709 S: 710 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 711 S: 712 S: 713 S: 714 S: 715 S: 716 S: ABC-12345 717 S: 54321-XYZ 718 S: 719 S: 720 S: 722 3.1.2. Availability Check Form 724 The Availability Check Form defines additional elements to extend the 725 EPP command described in the EPP domain name mapping 726 [RFC5731]. No additional elements are defined for the EPP 727 response. This form MUST be identified by setting the 728 "type" attribute to "avail". 730 The EPP command is used to determine if an object can be 731 provisioned within a repository. Domain names may be made available 732 only in unique launch phases, whilst remaining unavailable for 733 concurrent launch phases. In addition to the elements expressed in 734 the , the command is extended with the 735 element that contains the following child elements: 737 The launch phase to which domain name availability 738 should be determined. 740 Example Availability Check Form command using the domain 741 command and the extension with the "type" set to 742 "avail", to determine the availability of two domain names in the 743 "idn-release" custom launch phase: 745 C: 746 C: 747 C: 748 C: 749 C: 751 C: example1.tld 752 C: example2.tld 753 C: 754 C: 755 C: 756 C: 759 C: custom 760 C: 761 C: 762 C: ABC-12345 763 C: 764 C: 766 The Availability Check Form does not define any extension to the 767 response of an domain command. After processing the command, 768 the server replies with a standard EPP response as defined in the EPP 769 domain name mapping [RFC5731]. 771 3.2. EPP Command 773 This extension defines additional elements to extend the EPP 774 command and response to be used in conjunction with the EPP domain 775 name mapping [RFC5731]. 777 The EPP command is used to retrieve information for a launch 778 phase registration or application. The Application Identifier 779 (Section 2.1) returned in the element of the create 780 response (Section 3.3) is used for retrieving information for a 781 Launch Application. A element is sent along with the 782 regular domain command. The element includes an 783 OPTIONAL "includeMark" boolean attribute, with a default value of 784 "false", to indicate whether or not to include the mark in the 785 response. The element contains the following child 786 elements: 788 The phase during which the application or 789 registration was submitted or is associated with. Server policy 790 defines the phases that are supported. 791 OPTIONAL application identifier of the Launch 792 Application. 794 Example domain command with the extension to 795 retrieve information for the sunrise application for example.tld and 796 application identifier "abc123": 798 C: 799 C: 800 C: 801 C: 802 C: 804 C: example.tld 805 C: 806 C: 807 C: 808 C: 811 C: sunrise 812 C: abc123 813 C: 814 C: 815 C: ABC-12345 816 C: 817 C: 818 Example domain command with the extension to 819 retrieve information for the sunrise registration for example.tld: 821 C: 822 C: 823 C: 824 C: 825 C: 827 C: example.tld 828 C: 829 C: 830 C: 831 C: 833 C: sunrise 834 C: 835 C: 836 C: ABC-12345 837 C: 838 C: 840 If the query was successful, the server replies with a element along with the regular EPP . The contains the following child elements: 844 The phase during which the application was submitted, 845 or is associated with, that matches the associated command 846 . 847 OPTIONAL Application Identifier of the Launch 848 Application. 849 OPTIONAL status of the Launch Application using one 850 of the supported status values (Section 2.4). 851 Zero or more (Section 2.6.2) elements. 853 Example domain response using the extension 854 with the mark information: 856 S: 857 S: 858 S: 859 S: 860 S: Command completed successfully 861 S: 862 S: 863 S: 865 S: example.tld 866 S: EXAMPLE1-REP 867 S: 868 S: jd1234 869 S: sh8013 870 S: sh8013 871 S: ClientX 872 S: ClientY 873 S: 2012-04-03T22:00:00.0Z 874 S: 875 S: 2fooBAR 876 S: 877 S: 878 S: 879 S: 880 S: 882 S: sunrise 883 S: abc123 884 S: 885 S: 887 S: ... 888 S: 889 S: 890 S: 891 S: 892 S: ABC-12345 893 S: 54321-XYZ 894 S: 895 S: 896 S: 898 3.3. EPP Command 900 There are four forms of the extension to the EPP command 901 that include the Sunrise Create Form (Section 3.3.1), the Claims 902 Create Form (Section 3.3.2), the General Create Form (Section 3.3.3), 903 and the Mixed Create Form (Section 3.3.4). The form is dependent on 904 the supported launch phases (Section 2.3) as defined below. 906 sunrise The EPP command with the "sunrise" launch phase is 907 used to submit a registration with trademark information that can 908 be verified by the server with the value. The 909 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 910 launch phase. 911 landrush The EPP command with the "landrush" launch phase 912 MAY use the General Create Form (Section 3.3.3) to explicitly 913 specify the phase and optionally define the expected type of 914 object to create. 915 claims The EPP command with the "claims" launch phase is 916 used to pass the information associated with the presentation and 917 acceptance of the Claims Notice. The Claims Create Form 918 (Section 3.3.2) is used and the General Create Form 919 (Section 3.3.3) MAY be used for the "claims" launch phase. 920 open The EPP command with the "open" launch phase is 921 undefined but the form supported is up to server policy. 922 custom The EPP command with the "custom" launch phase is 923 undefined but the form supported is up to server policy. 925 3.3.1. Sunrise Create Form 927 The Sunrise Create Form of the extension to the EPP domain name 928 mapping [RFC5731] includes the verifiable trademark information that 929 the server uses to match against the domain name to authorize the 930 domain create. A server MUST support one of four models in Claim 931 Validation Models (Section 2.6) to verify the trademark information 932 passed by the client. 934 A element is sent along with the regular 935 domain command. The element has an OPTIONAL "type" 936 attribute that defines the expected type of object ("application" or 937 "registration") to create. The server SHOULD validate the "type" 938 attribute, when passed, against the type of object that will be 939 created. The element contains the following child 940 elements: 942 The identifier for the launch phase. 943 or or 944 Zero or more elements. The 945 child elements are defined in the element (Section 2.6.1) section. 947 Zero or more elements. The 948 child elements are defined in the element (Section 2.6.3.1) section. 950 Zero or more 951 elements. The child elements are 952 defined in the element 953 (Section 2.6.3.2) section. 955 The following is an example domain command using the 956 extension, following the "code" validation model, 957 with multiple sunrise codes: 959 C: 960 C: 961 C: 962 C: 963 C: 965 C: example.tld 966 C: jd1234 967 C: sh8013 968 C: sh8013 969 C: 970 C: 2fooBAR 971 C: 972 C: 973 C: 974 C: 975 C: 977 C: sunrise 978 C: 979 C: 980 C: 49FD46E6C4B45C55D4AC 981 C: 982 C: 983 C: 49FD46E6C4B45C55D4AD 984 C: 985 C: 986 C: 987 C: 49FD46E6C4B45C55D4AE 988 C: 989 C: 990 C: 991 C: ABC-12345 992 C: 993 C: 994 The following is an example domain command using the 995 extension, following the "mark" validation model, 996 with the mark information: 998 C: 999 C: 1000 C: 1001 C: 1002 C: 1004 C: exampleone.tld 1005 C: jd1234 1006 C: sh8013 1007 C: sh8013 1008 C: 1009 C: 2fooBAR 1010 C: 1011 C: 1012 C: 1013 C: 1014 C: 1016 C: sunrise 1017 C: 1018 C: 1020 C: ... 1021 C: 1022 C: 1023 C: 1024 C: 1025 C: ABC-12345 1026 C: 1027 C: 1028 The following is an example domain command using the 1029 extension, following the "code with mark" validation 1030 model, with a code and mark information: 1032 C: 1033 C: 1034 C: 1035 C: 1036 C: 1038 C: example.tld 1039 C: jd1234 1040 C: sh8013 1041 C: sh8013 1042 C: 1043 C: 2fooBAR 1044 C: 1045 C: 1046 C: 1047 C: 1048 C: 1050 C: sunrise 1051 C: 1052 C: 1053 C: 49FD46E6C4B45C55D4AC 1054 C: 1056 C: ... 1057 C: 1058 C: 1059 C: 1060 C: 1061 C: ABC-12345 1062 C: 1063 C: 1064 The following is an example domain command using the 1065 extension, following the "signed mark" validation 1066 model, with the signed mark information for a sunrise application: 1068 C: 1069 C: 1070 C: 1071 C: 1072 C: 1074 C: exampleone.tld 1075 C: jd1234 1076 C: sh8013 1077 C: sh8013 1078 C: 1079 C: 2fooBAR 1080 C: 1081 C: 1082 C: 1083 C: 1084 C: 1087 C: sunrise 1088 C: 1090 C: ... 1091 C: 1092 C: 1093 C: 1094 C: ABC-12345 1095 C: 1096 C: 1097 The following is an example domain command using the 1098 extension, following the "signed mark" validation 1099 model, with the base64 encoded signed mark information: 1101 C: 1102 C: 1103 C: 1104 C: 1105 C: 1107 C: exampleone.tld 1108 C: jd1234 1109 C: sh8013 1110 C: sh8013 1111 C: 1112 C: 2fooBAR 1113 C: 1114 C: 1115 C: 1116 C: 1117 C: 1119 C: sunrise 1120 C: 1122 C: ... 1123 C: 1124 C: 1125 C: 1126 C: ABC-12345 1127 C: 1128 C: 1130 3.3.2. Claims Create Form 1132 The Claims Create Form of the extension to the EPP domain name 1133 mapping [RFC5731] includes the information related to the 1134 registrant's acceptance of the Claims Notice for the "claims" launch 1135 phase. 1137 A element is sent along with the regular 1138 domain command. The element has an OPTIONAL "type" 1139 attribute that defines the expected type of object ("application" or 1140 "registration") to create. The server SHOULD validate the "type" 1141 attribute, when passed, against the type of object that will be 1142 created. The element contains the following child 1143 elements: 1145 MUST contain the value of "claims" to indicate the 1146 claims launch phase. 1147 1148 Unique notice identifier for the Claims 1149 Notice. The element has an OPTIONAL 1150 "validatorID" attribute is the Validator Identifier 1151 (Section 2.2) whose value indicates which Trademark Validator 1152 is the source of the Claims Notice, with the default being 1153 the ICANN TMCH. 1154 Expiry of the claims notice. 1155 Contains the date and time that the Claims 1156 Notice was accepted. 1158 The following is an example domain command using the 1159 extension with the information for 1160 the "claims" launch phase: 1162 C: 1163 C: 1164 C: 1165 C: 1166 C: 1168 C: example.tld 1169 C: jd1234 1170 C: sh8013 1171 C: sh8013 1172 C: 1173 C: 2fooBAR 1174 C: 1175 C: 1176 C: 1177 C: 1178 C: 1180 C: claims 1181 C: 1182 C: 1183 C: 49FD46E6C4B45C55D4AC 1184 C: 1185 C: 2012-06-19T10:00:10.0Z 1186 C: 1187 C: 2012-06-19T09:01:30.0Z 1188 C: 1189 C: 1190 C: 1191 C: 1192 C: ABC-12345 1193 C: 1194 C: 1196 3.3.3. General Create Form 1198 The General Create Form of the extension to the EPP domain name 1199 mapping [RFC5731] includes the launch phase and optionally the object 1200 type to create. The OPTIONAL "type" attribute defines the expected 1201 type of object ("application" or "registration") to create. The 1202 server SHOULD validate the "type" attribute, when passed, against the 1203 type of object that will be created. 1205 A element is sent along with the regular 1206 domain command. The element contains the following 1207 child elements: 1209 Contains the value of the active launch phase of the 1210 server. The server SHOULD validate the value against the active 1211 server launch phase. 1213 The following is an example domain command using the 1214 extension for a "landrush" launch phase application: 1216 C: 1217 C: 1218 C: 1219 C: 1220 C: 1222 C: example.tld 1223 C: jd1234 1224 C: sh8013 1225 C: sh8013 1226 C: 1227 C: 2fooBAR 1228 C: 1229 C: 1230 C: 1231 C: 1232 C: 1235 C: landrush 1236 C: 1237 C: 1238 C: ABC-12345 1239 C: 1240 C: 1242 3.3.4. Mixed Create Form 1244 The Mixed Create Form supports a mix of the create forms, where for 1245 example the Sunrise Create Form (Section 3.3.1) and the Claims Create 1246 Form (Section 3.3.2) MAY be supported in a single command by 1247 including both the verified trademark information and the information 1248 related to the registrant's acceptance of the Claims Notice. The 1249 server MAY support the Mixed Create Form. The "custom" launch phase 1250 SHOULD be used when using the Mixed Create Form. 1252 The following is an example domain command using the 1253 extension, with using a mix of the Sunrise Create 1254 Form (Section 3.3.1) and the Claims Create Form (Section 3.3.2) by 1255 including both a mark and a notice: 1257 C: 1258 C: 1259 C: 1260 C: 1261 C: 1263 C: exampleone.tld 1264 C: jd1234 1265 C: sh8013 1266 C: sh8013 1267 C: 1268 C: 2fooBAR 1269 C: 1270 C: 1271 C: 1272 C: 1273 C: 1276 C: custom 1277 C: 1278 C: 1280 C: ... 1281 C: 1282 C: 1283 C: 1284 C: 1285 C: 49FD46E6C4B45C55D4AC 1286 C: 1287 C: 2012-06-19T10:00:10.0Z 1288 C: 1289 C: 2012-06-19T09:01:30.0Z 1290 C: 1291 C: 1292 C: 1293 C: 1294 C: ABC-12345 1295 C: 1296 C: 1298 3.3.5. Create Response 1300 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1302 server generated Application Identifier (Section 2.1), when multiple 1303 applications of a given domain name are supported; otherwise no 1304 extension is included with the regular EPP . The element contains the following child elements: 1307 The phase of the application that mirrors the 1308 element included in the . 1309 The application identifier of the 1310 application. 1312 An example response when multiple overlapping applications are 1313 supported by the server: 1315 S: 1316 S: 1317 S: 1318 S: 1319 S: Command completed successfully; action pending 1320 S: 1321 S: 1322 S: 1324 S: example.tld 1325 S: 2010-08-10T15:38:26.623854Z 1326 S: 1327 S: 1328 S: 1329 S: 1331 S: sunrise 1332 S: 2393-9323-E08C-03B1 1333 S: 1334 S: 1335 S: 1336 S: 1337 S: ABC-12345 1338 S: 54321-XYZ 1339 S: 1340 S: 1341 S: 1343 3.4. EPP Command 1345 This extension defines additional elements to extend the EPP 1346 command to be used in conjunction with the domain name mapping. 1348 A client MUST NOT pass the extension on an EPP command to a 1349 server that does not support launch applications. A server that does 1350 not support launch applications during its launch phase MUST return 1351 an EPP error result code of 2102 when receiving an EPP 1352 command with the extension. 1354 Registry policies permitting, clients may update an application 1355 object by submitting an EPP command along with a element to indicate the application object to be updated. 1357 The element contains the following child elements: 1359 The phase during which the application was submitted 1360 or is associated with. 1361 The application identifier for which the 1362 client wishes to update. 1364 The following is an example domain command with the extension to add and remove a name server of a sunrise 1366 application with the application identifier "abc123": 1368 C: 1369 C: 1370 C: 1371 C: 1372 C: 1374 C: example.tld 1375 C: 1376 C: 1377 C: ns2.example.tld 1378 C: 1379 C: 1380 C: 1381 C: 1382 C: ns1.example.tld 1383 C: 1384 C: 1385 C: 1386 C: 1387 C: 1388 C: 1390 C: sunrise 1391 C: abc123 1392 C: 1393 C: 1394 C: ABC-12345 1395 C: 1396 C: 1398 This extension does not define any extension to the response of an 1399 domain command. After processing the command, the server 1400 replies with a standard EPP response as defined in the EPP domain 1401 name mapping [RFC5731]. 1403 3.5. EPP Command 1405 This extension defines additional elements to extend the EPP 1406 command to be used in conjunction with the domain name mapping. 1408 A client MUST NOT pass the extension on an EPP command to a 1409 server that does not support launch applications. A server that does 1410 not support launch applications during its launch phase MUST return 1411 an EPP error result code of 2102 when receiving an EPP 1412 command with the extension. 1414 Registry policies permitting, clients MAY withdraw an application by 1415 submitting an EPP command along with a 1416 element to indicate the application object to be deleted. The 1417 element contains the following child elements: 1419 The phase during which the application was submitted 1420 or is associated with. 1421 The application identifier for which the 1422 client wishes to delete. 1424 The following is an example domain command with the extension: 1427 C: 1428 C: 1429 C: 1430 C: 1431 C: 1433 C: example.tld 1434 C: 1435 C: 1436 C: 1437 C: 1439 C: sunrise 1440 C: abc123 1441 C: 1442 C: 1443 C: ABC-12345 1444 C: 1445 C: 1447 This extension does not define any extension to the response of a 1448 domain command. After processing the command, the server 1449 replies with a standard EPP response as defined in the EPP domain 1450 name mapping [RFC5731]. 1452 3.6. EPP Command 1454 This extension does not define any extension to the EPP 1455 command or response described in the EPP domain name mapping 1456 [RFC5731]. 1458 3.7. EPP Command 1460 This extension does not define any extension to the EPP 1461 command or response described in the EPP domain name mapping 1462 [RFC5731]. 1464 4. Formal Syntax 1466 One schema is presented here that is the EPP Launch Phase Mapping 1467 schema. 1469 The formal syntax presented here is a complete schema representation 1470 of the object mapping suitable for automated validation of EPP XML 1471 instances. The BEGIN and END tags are not part of the schema; they 1472 are used to note the beginning and ending of the schema for URI 1473 registration purposes. 1475 4.1. Launch Schema 1477 Copyright (c) 2012 IETF Trust and the persons identified as authors 1478 of the code. All rights reserved. 1480 Redistribution and use in source and binary forms, with or without 1481 modification, are permitted provided that the following conditions 1482 are met: 1484 o Redistributions of source code must retain the above copyright 1485 notice, this list of conditions and the following disclaimer. 1486 o Redistributions in binary form must reproduce the above copyright 1487 notice, this list of conditions and the following disclaimer in 1488 the documentation and/or other materials provided with the 1489 distribution. 1490 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1491 names of specific contributors, may be used to endorse or promote 1492 products derived from this software without specific prior written 1493 permission. 1495 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1496 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1497 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1498 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1499 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1500 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1501 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1502 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1503 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1504 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1505 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1507 BEGIN 1508 1509 1518 1521 1524 1527 1530 1531 1532 Extensible Provisioning Protocol v1.0 1533 domain name extension schema 1534 for the launch phase processing. 1535 1536 1538 1541 1542 1543 1544 1545 1547 1550 1551 1552 1553 1554 1555 1557 1560 1561 1562 1564 1570 1571 1572 1573 1574 1575 1576 1578 1581 1582 1583 1584 1585 1586 1587 1588 1589 1591 1594 1595 1596 1597 1598 1599 1600 1601 1602 1604 1605 1606 1608 1611 1612 1613 1614 1615 1617 1618 1619 1620 1622 1623 1624 1626 1629 1630 1631 1632 1633 1635 1638 1639 1640 1641 1642 1643 1644 1645 1646 1648 1649 1651 1654 1655 1656 1657 1659 1661 1662 1663 1664 1666 1670 1671 1672 1674 1676 1677 1679 1682 1683 1684 1685 1686 1688 1690 1692 1693 1695 1696 1697 1699 1702 1703 1704 1705 1706 1707 1709 1712 1713 1714 1715 1716 1717 1718 1720 1723 1724 1725 1726 1727 1729 1731 1735 1736 1737 1738 1739 1740 1741 1744 1745 1746 1747 1750 1751 1753 1755 1758 1759 1760 1762 1765 1766 1767 1768 1770 1771 1773 1774 1775 1776 1778 1779 1781 1782 1783 1784 1786 1787 1788 1789 1790 1791 1792 1794 1795 1796 1798 1801 1802 1803 1804 1807 1809 1811 1812 1814 1815 END 1817 5. Acknowledgements 1819 The authors wish to acknowledge the efforts of the leading 1820 participants of the Community TMCH Model that led to many of the 1821 changes to this document, which include Chris Wright, Jeff Neuman, 1822 Jeff Eckhaus, and Will Shorter. 1824 Special suggestions that have been incorporated into this document 1825 were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Jan 1826 Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus Malorny, 1827 Alexander Mayrhofer, Patrick Mevzek, James Mitchell, Francisco 1828 Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung Tran, Ulrich 1829 Wisser and Sharon Wodjenski. 1831 6. Change History 1832 6.1. Change from 00 to 01 1834 1. Changed to use camel case for the XML elements. 1835 2. Replaced "cancelled" status to "rejected" status. 1836 3. Added the child elements of the element. 1837 4. Removed the XML schema and replaced with "[TBD]". 1839 6.2. Change from 01 to 02 1841 1. Added support for both the ICANN and ARI/Neustar TMCH models. 1842 2. Changed the namespace URI and prefix to use "launch" instead of 1843 "launchphase". 1844 3. Added definition of multiple claim validation models. 1845 4. Added the and 1846 elements. 1847 5. Added support for Claims Info Command 1849 6.3. Change from 02 to 03 1851 1. Removed XSI namespace per Keith Gaughan's suggestion on the 1852 provreg list. 1853 2. Added extensibility to the launch:status element and added the 1854 pendingAuction status per Trung Tran's feedback on the provreg 1855 list. 1856 3. Added support for the Claims Check Command, updated the location 1857 and contents of the signedNotice, and replaced most references of 1858 Claim to Mark based on the work being done on the ARI/Neustar 1859 launch model. 1861 6.4. Change from 03 to 04 1863 1. Removed references to the ICANN model. 1864 2. Removed support for the Claims Info Command. 1865 3. Removed use of the signedClaim. 1866 4. Revised the method for referring to the signedClaim from the XML 1867 Signature using the IDREF URI. 1868 5. Split the launch-1.0.xsd into three XML schemas including launch- 1869 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 1870 6. Split the "claims" launch phase to the "claims1" and "claims2" 1871 launch phases. 1872 7. Added support for the encodedSignedMark with base64 encoded 1873 signedMark. 1874 8. Changed the elements in the createNoticeType to include the 1875 noticeID, timestamp, and the source elements. 1876 9. Added the class and effectiveDate elements to mark. 1878 6.5. Change from 04 to 05 1880 1. Removed reference to in the example. 1881 2. Incorporated feedback from Bernhard Reutner-Fischer on the 1882 provreg mail list. 1883 3. Added missing launch XML prefix to applicationIDType reference in 1884 the idContainerType of the Launch Schema. 1885 4. Added missing description of the element in the element. 1887 5. Updated note on replication of the EPP contact mapping elements 1888 in the Mark Contact section. 1890 6.6. Change from 05 to 06 1892 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 1893 replaced with reference to draft-lozano-smd, that contains the 1894 definition for the mark, signed marked, and encoded signed mark. 1895 2. Split the into and 1896 based on feedback from Trung Tran. 1897 3. Added the "includeMark" optional attribute to the 1898 element to enable the client to request whether or not to include 1899 the mark in the info response. 1900 4. Fixed state diagram to remove redundant transition from "invalid" 1901 to "rejected"; thanks Klaus Malorny. 1903 6.7. Change from 06 to 07 1905 1. Proof-read grammar and spelling. 1906 2. Changed "pendingAuction" status to "pendingAllocation", changed 1907 "pending" to "pendingValidation" status, per proposal from Trung 1908 Tran and seconded by Rubens Kuhl. 1909 3. Added text related to the use of RFC 5731 pendingCreate to the 1910 Application Identifier section. 1911 4. Added the Poll Messaging section to define the use of poll 1912 messaging for intermediate state transitions and pending action 1913 poll messaging for final state transitions. 1915 6.8. Change from 07 to 08 1917 1. Added support for use of the launch statuses and poll messaging 1918 for Launch Registrations based on feedback from Sharon Wodjenski 1919 and Trung Tran. 1920 2. Incorporated changes based on updates or clarifications in 1921 draft-lozano-tmch-func-spec-01, which include: 1922 1. Removed the unused element. 1923 2. Removed the element. 1925 3. Added the element based on the required 1926 element. 1928 6.9. Change from 08 to 09 1930 1. Made element optional in to allow 1931 passing just the in per request 1932 from Ben Levac. 1933 2. Added optional "type" attribute in to enable the 1934 client to explicitly define the desired type of object 1935 (application or registration) to create to all forms of the 1936 create extension. 1937 3. Added text that the server SHOULD validate the 1938 element in the Launch Phases section. 1939 4. Add the "General Create Form" to the create command extension to 1940 support the request from Ben Levac. 1941 5. Updated the text for the Poll Messaging section based on feedback 1942 from Klaus Malorny. 1943 6. Replaced the "claims1" and "claims2" phases with the "claims" 1944 phase based on discussion on the provreg list. 1945 7. Added support for a mixed create model (Sunrise Create Model and 1946 Claims Create Model), where a trademark (encoded signed mark, 1947 etc.) and notice can be passed, based on a request from James 1948 Mitchell. 1949 8. Added text for the handling of the overlapping "claims" and 1950 "landrush" launch phases. 1951 9. Added support for two check forms (claims check form and 1952 availability check form) based on a request from James Mitchell. 1953 The availability check form was based on the text in 1954 draft-rbp-application-epp-mapping. 1956 6.10. Change from 09 to 10 1958 1. Changed noticeIDType from base64Binary to token to be compatible 1959 with draft-lozano-tmch-func-spec-05. 1960 2. Changed codeType from base64Binary to token to be more generic. 1961 3. Updated based on feedback from Alexander Mayrhofer, which 1962 include: 1963 1. Changed "extension to the domain name extension" to 1964 "extension to the domain name mapping". 1965 2. Changed use of 2004 return code to 2306 return code when 1966 phase passed mismatches active phase and sub-phase. 1967 3. Changed description of "allocated" and "rejected" statuses. 1968 4. Moved sentence on a synchronous command 1969 without the use of an intermediate application, then an 1970 Application Identifier MAY not be needed to the Application 1971 Identifier section. 1973 5. Restructured the Mark Validation Models section to include 1974 the " element" sub-section, the " element" sub-section, and the Digital Signature sub- 1976 section. 1977 6. Changed "Registries may" to "Registries MAY". 1978 7. Changed "extensed" to "extended" in "Availability Check 1979 Form" section. 1980 8. Broke the mix of create forms in the "EPP Command" 1981 section to a fourth "Mixed Create Form" with its own sub- 1982 section. 1983 9. Removed "displayed or" from "displayed or accepted" in the 1984 description. 1985 10. Replaced "given domain name is supported" with "given domain 1986 name are supported" in the "Create Response" section. 1987 11. Changed the reference of 2303 (object does not exist) in the 1988 "Security Considerations" section to 2201 (authorization 1989 error). 1990 12. Added arrow from "invalid" status to "pendingValidation" 1991 status and "pendingAllocation" status to "rejected" status 1992 in the State Transition Diagram. 1993 4. Added the "C:" and "S:" example prefixes and related text in the 1994 "Conventions Used in This Document" section. 1996 6.11. Change from 10 to 11 1998 1. Moved the claims check response element under 1999 the element instead of the element based on 2000 the request from Francisco Obispo. 2002 6.12. Change from 11 to 12 2004 1. Added support for multiple validator identifiers for claims 2005 notices and marks based on a request and text provided by Mike 2006 O'Connell. 2007 2. Removed domain:exDate element from example in section 3.3.5 based 2008 on a request from Seth Goldman on the provreg list. 2009 3. Added clarifying text for clients not passing the launch 2010 extension on update and delete commands to servers that do not 2011 support launch applications based on a request from Sharon 2012 Wodjenski on the provreg list. 2014 6.13. Change from 12 to WG 00 2016 1. Changed to eppext working group draft by changing 2017 draft-tan-epp-launchphase to draft-ietf-eppext-launchphase and by 2018 changing references of draft-lozano-tmch-smd to 2019 draft-ietf-eppext-tmch-smd. 2021 7. IANA Considerations 2023 This document uses URNs to describe XML namespaces and XML schemas 2024 conforming to a registry mechanism described in [RFC3688]. One URI 2025 assignment has been registered by the IANA. 2027 Registration request for the Launch namespace: 2029 URI: urn:ietf:params:xml:ns:launch-1.0 2030 Registrant Contact: See the "Author's Address" section of this 2031 document. 2032 XML: None. Namespace URIs do not represent an XML specification. 2034 8. Security Considerations 2036 The mapping extensions described in this document do not provide any 2037 security services beyond those described by EPP [RFC5730], the EPP 2038 domain name mapping [RFC5731], and protocol layers used by EPP. The 2039 security considerations described in these other specifications apply 2040 to this specification as well. 2042 Updates to, and deletion of an application object must be restricted 2043 to clients authorized to perform the said operation on the object. 2045 As information contained within an application, or even the mere fact 2046 that an application exists may be confidential. Any attempt to 2047 operate on an application object by an unauthorized client MUST be 2048 rejected with an EPP 2201 (authorization error) return code. Server 2049 policy may allow operation with filtered output by clients 2050 other than the sponsoring client, in which case the 2051 and response SHOULD be filtered to include only 2052 fields that are publicly accessible. 2054 9. Normative References 2056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2057 Requirement Levels", BCP 14, RFC 2119, March 1997. 2059 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2060 January 2004. 2062 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2063 STD 69, RFC 5730, August 2009. 2065 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2066 Domain Name Mapping", STD 69, RFC 5731, August 2009. 2068 [draft-ietf-eppext-tmch-smd] 2069 Lozano, G., "Mark and Signed Mark Objects Mapping". 2071 [1] 2073 [2] 2075 Authors' Addresses 2077 James Gould 2078 VeriSign, Inc. 2079 12061 Bluemont Way 2080 Reston, VA 20190 2081 US 2083 Email: jgould@verisign.com 2084 URI: http://www.verisigninc.com 2086 Wil Tan 2087 Cloud Registry 2088 Suite 32 Seabridge House 2089 377 Kent St 2090 Sydney, NSW 2000 2091 AU 2093 Phone: +61 414 710899 2094 Email: wil@cloudregistry.net 2095 URI: http://www.cloudregistry.net 2097 Gavin Brown 2098 CentralNic Ltd 2099 35-39 Mooregate 2100 London, England EC2R 6AR 2101 GB 2103 Phone: +44 20 33 88 0600 2104 Email: gavin.brown@centralnic.com 2105 URI: https://www.centralnic.com