idnits 2.17.1 draft-ietf-regext-launchphase-05.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 (June 22, 2017) is 2493 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: December 24, 2017 Cloud Registry 6 G. Brown 7 CentralNic Ltd 8 June 22, 2017 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-ietf-regext-launchphase-05 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 December 24, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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.3.1. Trademark Claims Phase . . . . . . . . . . . . . . . 7 61 2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 9 62 2.4.1. State Transition . . . . . . . . . . . . . . . . . . 10 63 2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . 11 64 2.6. Mark Validation Models . . . . . . . . . . . . . . . . . 14 65 2.6.1. element . . . . . . . . . . . . . . 15 66 2.6.2. element . . . . . . . . . . . . . . . . . 16 67 2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 16 68 2.6.3.1. element . . . . . . . . . . . . 16 69 2.6.3.2. element . . . . . . . . . 16 70 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 16 71 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 17 72 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 17 73 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 20 74 3.1.3. Trademark Check Form . . . . . . . . . . . . . . . . 22 75 3.2. EPP Command . . . . . . . . . . . . . . . . . . . 25 76 3.3. EPP Command . . . . . . . . . . . . . . . . . . 28 77 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 28 78 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . 34 79 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 37 80 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 38 81 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 40 82 3.4. EPP Command . . . . . . . . . . . . . . . . . . 41 83 3.5. EPP Command . . . . . . . . . . . . . . . . . . 42 84 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 43 85 3.7. EPP Command . . . . . . . . . . . . . . . . . 44 86 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 44 87 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 44 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 89 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 51 90 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 52 91 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 52 92 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 53 93 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 53 94 6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 54 95 6.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 54 96 6.5. RegistryEngine EPP Service . . . . . . . . . . . . . . . 54 97 6.6. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 55 98 6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 55 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 57 103 9.2. Informative References . . . . . . . . . . . . . . . . . 57 104 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 57 105 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 57 106 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 58 107 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 58 108 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 58 109 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 58 110 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 59 111 A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 59 112 A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 59 113 A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 59 114 A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 60 115 A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 61 116 A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 61 117 A.13. Change from 12 to EPPEXT 00 . . . . . . . . . . . . . . . 61 118 A.14. Change EPPEXT 00 to EPPEXT 01 . . . . . . . . . . . . . . 61 119 A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 62 120 A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 62 121 A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 62 122 A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 62 123 A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 62 124 A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 63 125 A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 63 126 A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 63 127 A.23. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 63 128 A.24. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 63 129 A.25. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 63 130 A.26. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 64 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 133 1. Introduction 135 This document describes an extension mapping for version 1.0 of the 136 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 137 specifies a flexible schema that can be used to implement several 138 common use cases related to the provisioning and management of domain 139 name registrations and applications during the launch of a domain 140 name registry. 142 It is typical for domain registries to operate in special modes 143 during their initial launch to facilitate allocation of domain names, 144 often according to special rules. This document uses the term 145 "launch phase" and the shorter form "launch" to refer to such a 146 period. 148 The EPP domain name mapping [RFC5731] is designed for the steady- 149 state operation of a registry. During a launch period, the model in 150 place may be different from what is defined in the EPP domain name 151 mapping [RFC5731]. For example, registries often accept multiple 152 applications for the same domain name during the "Sunrise" launch 153 phase, referred to as a Launch Application. A Launch Registration 154 refers to a registration made during a launch phase when the server 155 uses a "first-come, first-served" model. Even in a "first-come, 156 first-served" model, additional steps and information might be 157 required, such as trademark information. In addition, RFC 7848 158 [RFC7848] defines a registry interface for the Trademark Claims or 159 "claims" launch phase that includes support for presenting a 160 Trademark Claims Notice to the Registrant. This document proposes an 161 extension to the domain name mapping in order to provide a uniform 162 interface for the management of Launch Applications and Launch 163 Registrations in launch phases. 165 1.1. Conventions Used in This Document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 XML is case sensitive. Unless stated otherwise, XML specifications 172 and examples provided in this document MUST be interpreted in the 173 character case presented in order to develop a conforming 174 implementation. 176 In examples, "C:" represents lines sent by a protocol client and "S:" 177 represents lines returned by a protocol server. Indentation and 178 white space in examples are provided only to illustrate element 179 relationships and are not a REQUIRED feature of this protocol. 181 "launch-1.0" is used as an abbreviation for 182 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 183 "launch" is used, but implementations MUST NOT depend on it and 184 instead employ a proper namespace-aware XML parser and serializer to 185 interpret and output the XML documents. 187 "signedMark-1.0" is used as an abbreviation for 188 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in [RFC7848]. 189 The XML namespace prefix "smd" is used, but implementations MUST NOT 190 depend on it and instead employ a proper namespace-aware XML parser 191 and serializer to interpret and output the XML documents. 193 "mark-1.0" is used as an abbreviation for 194 "urn:ietf:params:xml:ns:mark-1.0" that is defined in [RFC7848]. The 195 XML namespace prefix "mark" is used, but implementations MUST NOT 196 depend on it and instead employ a proper namespace-aware XML parser 197 and serializer to interpret and output the XML documents. 199 2. Object Attributes 201 This extension adds additional elements to the EPP domain name 202 mapping [RFC5731]. Only those new elements are described here. 204 2.1. Application Identifier 206 Servers MAY allow multiple applications, referred to as a Launch 207 Application, of the same domain name during its launch phase 208 operations. Upon receiving a valid command to create 209 a Launch Application, the server MUST create an application object 210 corresponding to the request, assign an application identifier for 211 the Launch Application, set the [RFC5731] pendingCreate status, and 212 return the application identifier to the client with the 213 element. In order to facilitate correlation, 214 all subsequent launch operations on the Launch Application MUST be 215 qualified by the previously assigned application identifier using the 216 element. 218 2.2. Validator Identifier 220 The Validator Identifier is the unique identifier for a Trademark 221 Validator that validates marks and has a repository of validated 222 marks. The OPTIONAL "validatorID" attribute is used to define the 223 Validator Identifier of the Trademark Validator. Registries MAY 224 support more than one Third Party Trademark Validator. The Internet 225 Corporation for Assigned Names and Numbers (ICANN) Trademark 226 Clearinghouse (TMCH) is the default Trademark Validator and is 227 reserved the Validator Identifier of "tmch". If the ICANN TMCH is 228 not used or multiple Trademark Validators are used, the Validator 229 Identifier MUST be defined using the "validatorID" attribute. 231 The Validator Identifier MAY be related to one or more issuer 232 identifiers of the element and the element defined 233 in [RFC7848]. Both the Validator Identifier and the Issuer 234 Identifier used MUST be unique. If the ICANN TMCH is not used or 235 multiple Trademark Validators are used, the server MUST define the 236 list of supported validator identifiers and MUST make this 237 information available to clients using a mutually acceptable, out-of- 238 band mechanism. 240 The Validator Identifier MAY define a non-Trademark Validator that 241 supports a form of claims. 243 2.3. Launch Phases 245 The server MAY support multiple launch phases sequentially or 246 simultaneously. The element MUST be included by the 247 client to define the target launch phase of the command. The server 248 SHOULD validate the phase and MAY validate the sub-phase of the 249 element against the active phase and OPTIONAL sub- 250 phase of the server on a create command, and return an EPP error 251 result code of 2306 if there is a mismatch. 253 The following launch phase values are defined: 255 sunrise The phase during which trademark holders can submit 256 registrations or applications with trademark information that can 257 be validated by the server. 258 landrush A post-Sunrise phase when non-trademark holders are allowed 259 to register domain names with steps taken to address a large 260 volume of initial registrations. 261 claims The phase, as defined in the Section 2.3.1, in which a Claims 262 Notice MUST be displayed to a prospective registrant of a domain 263 name that matches trademarks. 264 open A post-launch phase that is also referred to as "steady state". 265 Servers MAY require additional trademark protection during this 266 phase. 267 custom A custom server launch phase that is defined using the "name" 268 attribute. 270 For extensibility, the element includes an OPTIONAL 271 "name" attribute that can define a sub-phase, or the full name of the 272 phase when the element has the "custom" value. For 273 example, the "claims" launch phase could have two sub-phases that 274 include "landrush" and "open". 276 Launch phases MAY overlap to support the "claims" launch phase, 277 defined in the Section 2.3.1, and to support a traditional "landrush" 278 launch phase. The overlap of the "claims" and "landrush" launch 279 phases SHOULD be handled by setting "claims" as the 280 value and setting "landrush" as the sub-phase with the "name" 281 attribute. For example, the element SHOULD be 282 claims. 284 2.3.1. Trademark Claims Phase 286 The Trademark Claims Phase is when a Claims Notice MUST be displayed 287 to a prospective registrant of a domain name that matches trademarks. 288 The source of the trademarks is a Trademark Validator and the source 289 of the Claims Notice information is a Claim Notice Information 290 Service (CNIS), which MAY be directly linked to a Trademark 291 Validator. The client interfaces with the server to determine if a 292 trademark exists for a domain name, interfaces with a CNIS to get the 293 Claims Notice information, and interfaces with the server to pass the 294 Claims Notice acceptance information in a create command. This 295 document supports the Trademark Claims Phase in two ways including: 297 Claims Check Form Claims Check Form (Section 3.1.1) is used to 298 determine whether or not there are any matching trademarks for a 299 domain name. If there is at least one matching trademark that 300 exists for the domain name, a claims key is returned. The mapping 301 of domain names and the claims keys is based on an out-of-band 302 interface between the server and the Trademark Validator. The 303 CNIS associated with the claims key Validator Identifier 304 (Section 2.2) MUST accept the claims key as the basis for 305 retrieving the claims information. 306 Claims Create Form Claims Create Form (Section 3.3.2) is used to 307 pass the Claims Notice acceptance information in a create command. 308 The notice identifier () format, validation 309 rules, and server processing is up to the interface between the 310 server and the Trademark Validator. The CNIS associated with the 311 Validator Identifier (Section 2.2) MUST generate a notice 312 identifier compliant with the element. 314 The following shows the Trademark Claims Phase registration flow: 316 .------------. .--------. .--------. .------. 317 | Registrant | | Client | | Server | | CNIS | 318 '------------' '--------' '--------' '------' 319 | Request Domain | | | 320 | Registration | | | 321 |--------------->| Domain Check | | 322 | |--------------------------->| | 323 | Domain | Domain Unavailable .------------. | 324 | Unavailable |<---------------------( Available? ) | 325 |<---------------| No '------------' | 326 | | Domain Available | Yes | 327 | |<---------------------------| | 328 | | Domain Claims Check | | 329 | |--------------------------->| | 330 | | .---------. | 331 | | / Does \ | 332 | |<--------------------( Domain have ) | 333 | | No \ Claims? / | 334 | | '---------' | 335 | | Domain Create | | Yes | 336 | |--------------------------->| | | 337 | Domain | Domain Registered | | | 338 | Registered |<---------------------------| | | 339 |<---------------| | | 340 | | | 341 | | Claims Key | | 342 | |<------------------------------' | 343 | | | 344 .-----. | | Request Claims Info with Claims Key | 345 |Abort| | Display |-------------------------------------->| 346 '-----' | Claims | Return Claims Info | 347 ^ | Notice |<--------------------------------------| 348 | No |<---------------| | 349 | .------. Yes | | 350 '-( Ack? )----------->| Domain Claims Create Form | | 351 '------' |--------------------------->| | 352 | Registration | Error .----------------------. | 353 | Error |<-----------( Validation Successful? ) | 354 |<---------------| No '----------------------' | 355 | | | Yes | 356 | Domain | Domain Registered | | 357 | Registered |<---------------------------| | 358 |<---------------| | | 360 Figure 1 362 2.4. Status Values 364 A Launch Application or Launch Registration object MAY have a launch 365 status value. The element is used to convey the 366 launch status pertaining to the object, beyond what is specified in 367 the object mapping. A Launch Application or Launch Registration MUST 368 set the [RFC5731] "pendingCreate" status if a launch status is 369 supported and the launch status is not one of the final statuses, 370 including the "allocated" and "rejected" statuses. 372 The following status values are defined using the required "s" 373 attribute: 375 pendingValidation: The initial state of a newly-created application 376 or registration object. The application or registration requires 377 validation, but the validation process has not yet completed. 378 validated: The application or registration meets relevant registry 379 rules. 380 invalid: The application or registration does not validate according 381 to registry rules. Server policies permitting, it may transition 382 back into "pendingValidation" for revalidation, after 383 modifications are made to ostensibly correct attributes that 384 caused the validation failure. 385 pendingAllocation: The allocation of the application or registration 386 is pending based on the results of some out-of-band process (for 387 example, an auction). 388 allocated: The object corresponding to the application or 389 registration has been provisioned. Is a possible end state of an 390 application or registration object. 391 rejected: The application or registration object was not 392 provisioned. Is a possible end state of an application or 393 registration object. 394 custom: A custom status that is defined using the "name" attribute. 396 Each status value MAY be accompanied by a string of human-readable 397 text that describes the rationale for the status applied to the 398 object. The OPTIONAL "lang" attribute MAY be present to identify the 399 language if the negotiated value is something other than the default 400 value of "en" (English). 402 For extensibility the element includes an OPTIONAL 403 "name" attribute that can define a sub-status or the full name of the 404 status when the status value is "custom". The server SHOULD NOT use 405 the "custom" status value. 407 Status values MAY be skipped. For example, an application or 408 registration MAY immediately start at the "allocated" status or an 409 application or registration MAY skip the "pendingAllocation" status. 411 If the launch phase does not require validation of a request, an 412 application or registration MAY immediately skip to 413 "pendingAllocation". 415 2.4.1. State Transition 417 | request 418 | 419 | +--------------------------+ 420 | | | 421 v v | 422 +-------------------+ | 423 | | | 424 | pendingValidation +--------------+ | 425 | | | | 426 +---------+---------+ | | 427 | | | 428 | | | 429 v v | 430 +-----------+ +---------+ | 431 | | | | | 432 | validated | | invalid +--+ 433 | | | | 434 +-----+-----+ +----+----+ 435 | | 436 | | 437 v | 438 +-------------------+ | 439 | | | 440 | pendingAllocation +-----------+ | 441 | | | | 442 +---------+---------+ | | 443 | | | 444 | | | 445 | | | 446 | | | 447 | | | 448 v v v 449 +---------+ +--------+ 450 / \ / \ 451 | allocated | | rejected | 452 \ / \ / 453 +---------+ +--------+ 455 Figure 2 457 2.5. Poll Messaging 459 A Launch Application MUST and a Launch Registration MAY be handled as 460 an EPP domain name object as specified in RFC 5731 [RFC5731] in 461 "pendingCreate" status, with the launch status values defined in 462 Section 2.4. As a Launch Application or Launch Registration 463 transitions between the status values defined in Section 2.4, the 464 server SHOULD insert poll messages, per [RFC5730], for the applicable 465 intermediate statuses, including the "pendingValidation", 466 "validated", "pendingAllocation, and "invalid" statuses, using the 467 element with the extension. The 468 element MAY contain non-mandatory information, like 469 contact and name server information. Also, further extensions that 470 would normally be included in the response of a 471 command, per [RFC5731], MAY be included. For the final statuses, 472 including the "allocated" and "rejected" statuses, the server MUST 473 insert a poll message, per [RFC5731], with the 474 extension. 476 The following is an example poll message for a Launch Application 477 that has transitioned to the "pendingAllocation" state. 479 S: 480 S: 481 S: 482 S: 483 S: Command completed successfully; ack to dequeue 484 S: 485 S: 486 S: 2013-04-04T22:01:00.0Z 487 S: Application pendingAllocation. 488 S: 489 S: 490 S: 492 S: domain.example 493 S: ... 494 S: 495 S: 496 S: 497 S: 499 S: sunrise 500 S: abc123 501 S: 502 S: 503 S: 504 S: 505 S: ABC-12345 506 S: 54322-XYZ 507 S: 508 S: 509 S: 510 The following is an example poll message for an 511 "allocated" Launch Application. 513 S: 514 S: 515 S: 516 S: 517 S: Command completed successfully; ack to dequeue 518 S: 519 S: 520 S: 2013-04-04T22:01:00.0Z 521 S: Application successfully allocated. 522 S: 523 S: 524 S: 526 S: domain.example 527 S: 528 S: ABC-12345 529 S: 54321-XYZ 530 S: 531 S: 2013-04-04T22:00:00.0Z 532 S: 533 S: 534 S: 535 S: 537 S: sunrise 538 S: abc123 539 S: 540 S: 541 S: 542 S: 543 S: BCD-23456 544 S: 65432-WXY 545 S: 546 S: 547 S: 548 The following is an example poll message for an 549 "allocated" Launch Registration. 551 S: 552 S: 553 S: 554 S: 555 S: Command completed successfully; ack to dequeue 556 S: 557 S: 558 S: 2013-04-04T22:01:00.0Z 559 S: Registration successfully allocated. 560 S: 561 S: 562 S: 564 S: domain.example 565 S: 566 S: ABC-12345 567 S: 54321-XYZ 568 S: 569 S: 2013-04-04T22:00:00.0Z 570 S: 571 S: 572 S: 573 S: 575 S: sunrise 576 S: 577 S: 578 S: 579 S: 580 S: BCD-23456 581 S: 65432-WXY 582 S: 583 S: 584 S: 586 2.6. Mark Validation Models 588 A server MUST support at least one of the following models for 589 validating trademark information: 591 code Use of a mark code by itself to validate that the mark matches 592 the domain name. This model is supported using the 593 element with just the element. 594 mark The mark information is passed without any other validation 595 element. The server will use some custom form of validation to 596 validate that the mark information is authentic. This model is 597 supported using the element with just the 598 (Section 2.6.2) element. 599 code with mark: A code is used along with the mark information by 600 the server to validate the mark utilizing an external party. The 601 code represents some form of secret that matches the mark 602 information passed. This model is supported using the 603 element that contains both the and 604 the (Section 2.6.2) elements. 605 signed mark: The mark information is digitally signed as described 606 in the Digital Signature (Section 2.6.3) section. The digital 607 signature can be directly validated by the server using the public 608 key of the external party that created the signed mark using its 609 private key. This model is supported using the 610 (Section 2.6.3.1) and (Section 2.6.3.2) 611 elements. 613 More than one , (Section 2.6.3.1), 614 or (Section 2.6.3.2) element MAY be 615 specified. The maximum number of marks per domain name is up to 616 server policy. 618 2.6.1. element 620 The element that is used by the "code", "mark", and 621 "code with mark" validation models, has the following child elements: 623 : OPTIONAL mark code used to validate the 624 (Section 2.6.2) information. The mark code is be a mark-specific 625 secret that the server can verify against a third party. The 626 OPTIONAL "validatorID" attribute is the Validator Identifier 627 (Section 2.2) whose value indicates which Trademark Validator that 628 the code originated from, with no default value. 629 : OPTIONAL mark information with child elements defined 630 in the Mark (Section 2.6.2) section. 632 The following is an example element with both a 633 and (Section 2.6.2) element. 635 636 637 49FD46E6C4B45C55D4AC 638 639 ... 640 641 643 2.6.2. element 645 A element describes an applicant's prior right to a given 646 domain name that is used with the "mark", "mark with code", and the 647 "signed mark" validation models. The element is defined 648 in [RFC7848]. A new mark format can be supported by creating a new 649 XML schema for the mark that has an element that substitutes for the 650 element from [RFC7848]. 652 2.6.3. Digital Signature 654 Digital signatures MAY be used by the server to validate either the 655 mark information, when using the "signed mark" validation model with 656 the (Section 2.6.3.1) element or the 657 (Section 2.6.3.2) element. 659 2.6.3.1. element 661 The element contains the digitally signed mark 662 information. The element is defined in [RFC7848]. 663 A new signed mark format can be supported by creating a new XML 664 schema for the signed mark that has an element that substitutes for 665 the element from [RFC7848]. 667 2.6.3.2. element 669 The element contains an encoded form of the 670 digitally signed (Section 2.6.3.1) element. The 671 element is defined in [RFC7848]. A new 672 encoded signed mark format can be supported by creating a new XML 673 schema for the encoded signed mark that has an element that 674 substitutes for the element from [RFC7848]. 676 3. EPP Command Mapping 678 A detailed description of the EPP syntax and semantics can be found 679 in the EPP core protocol specification [RFC5730]. The command 680 mappings described here are specifically for use in the Launch Phase 681 Extension. 683 This mapping is designed to be flexible, requiring only a minimum set 684 of required elements. 686 While it is meant to serve several use cases, it does not prescribe 687 any interpretation by the client or server. Such processing is 688 typically highly policy-dependent and therefore specific to 689 implementations. 691 Operations on application objects are done via one or more of the 692 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 693 Registries MAY choose to support a subset of the operations. 695 3.1. EPP Command 697 There are three forms of the extension to the EPP command: 698 the Claims Check Form (Section 3.1.1), the Availability Check Form 699 (Section 3.1.2), and the Trademark Check Form (Section 3.1.3). The 700 element "type" attribute defines the form, with the 701 value of "claims" for the Claims Check Form (Section 3.1.1), with the 702 value of "avail" for the Availability Check Form (Section 3.1.2), and 703 with the value of "trademark" for the Trademark Check Form 704 (Section 3.1.3). The default value of the "type" attribute is 705 "claims". The forms supported by the server is determined by server 706 policy. The server MUST return an EPP error result code of 2307 if 707 it receives a check form that is not supported. 709 3.1.1. Claims Check Form 711 The Claims Check Form defines a new command called the Claims Check 712 Command that is used to determine whether or not there are any 713 matching trademarks, in the specified launch phase, for each domain 714 name passed in the command, that requires the use of the "Claims 715 Create Form" on a Domain Create Command. The availability check 716 information defined in the EPP domain name mapping [RFC5731] MUST NOT 717 be returned for the Claims Check Command. This form is the default 718 form and MAY be explicitly identified by setting the 719 "type" attribute to "claims". 721 Instead of returning whether the domain name is available, the Claims 722 Check Command will return whether or not at least one matching 723 trademark exists for the domain name, that requires the use of the 724 "Claims Create Form" on a Domain Create Command. If there is at 725 least one matching trademark that exists for the domain name, a 726 element is returned. The client MAY then use the 727 value of the element to obtain information needed 728 to generate the Trademark Claims Notice from Trademark Validator 729 based on the Validator Identifier (Section 2.2). The unique notice 730 identifier of the Trademark Claims Notice MUST be passed in the 731 element of the extension to the Create Command 732 (Section 3.3). 734 The elements in the EPP command of EPP domain 735 name mapping [RFC5731] define the domain names to check for matching 736 trademarks. The element contains the following child 737 elements: 739 Contains the value of the active launch phase of the 740 server. The server SHOULD validate the value against the active 741 server launch phase. 743 Example Claims Check command using the domain command and the 744 extension with the "type" explicitly set to "claims", 745 to determine if "domain1.example", "domain2.example", and 746 "domain3.example" require claims notices during the "claims" launch 747 phase: 749 C: 750 C: 751 C: 752 C: 753 C: 755 C: domain1.example 756 C: domain2.example 757 C: domain3.example 758 C: 759 C: 760 C: 761 C: 764 C: claims 765 C: 766 C: 767 C: ABC-12345 768 C: 769 C: 771 If the command has been processed successfully, the EPP 772 MUST contain an element that 773 identifies the launch namespace. The element 774 contains the following child elements: 776 The phase that mirrors the element 777 included in the . 778 One or more elements that contain the 779 following child elements: 781 Contains the fully qualified name of the queried 782 domain name. This element MUST contain an "exists" attribute 783 whose value indicates if a matching trademark exists for the 784 domain name that requires the use of the "Claims Create Form" 785 on a Domain Create Command. A value of "1" (or "true") means 786 that a matching trademark does exist and that the "Claims 787 Create Form" is required on a Domain Create Command. A value 788 of "0" (or "false") means that a matching trademark does not 789 exist or that the "Claims Create Form" is NOT required on a 790 Domain Create Command. 791 Zero or more OPTIONAL claim keys that MAY be 792 passed to a third-party Trademark Validator such as the ICANN 793 Trademark Clearinghouse (TMCH) for querying the information 794 needed to generate a Trademark Claims Notice. The 795 is used as the key for the query in place 796 of the domain name to securely query the service without 797 using a well-known value like a domain name. The OPTIONAL 798 "validatorID" attribute is the Validator Identifier 799 (Section 2.2) whose value indicates which Trademark Validator 800 to query for the Claims Notice information, with the default 801 being the ICANN TMCH. The "validatorID" attribute MAY 802 reference a non-trademark claims clearinghouse identifer to 803 support other forms of claims notices. 805 Example Claims Check response when a claims notice is not required 806 for the domain name domain1.example, a claims notice is required for 807 the domain name domain2.example in the "tmch", and a claims notice is 808 required for the domain name domain3.example in the "tmch" and 809 "custom-tmch", for the "claims" launch phase: 811 S: 812 S: 813 S: 814 S: 815 S: Command completed successfully 816 S: 817 S: 818 S: 820 S: claims 821 S: 822 S: domain1.example 823 S: 824 S: 825 S: domain2.example 826 S: 827 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 828 S: 829 S: 830 S: 831 S: domain3.example 832 S: 833 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 834 S: 835 S: 836 S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 837 S: 838 S: 839 S: 840 S: 841 S: 842 S: ABC-12345 843 S: 54321-XYZ 844 S: 845 S: 846 S: 848 3.1.2. Availability Check Form 850 The Availability Check Form defines additional elements to extend the 851 EPP command described in the EPP domain name mapping 852 [RFC5731]. No additional elements are defined for the EPP 853 response. This form MUST be identified by setting the 854 "type" attribute to "avail". 856 The EPP command is used to determine if an object can be 857 provisioned within a repository. Domain names may be made available 858 only in unique launch phases, whilst remaining unavailable for 859 concurrent launch phases. In addition to the elements expressed in 860 the , the command is extended with the 861 element that contains the following child elements: 863 The launch phase to which domain name availability 864 should be determined. 866 Example Availability Check Form command using the domain 867 command and the extension with the "type" set to 868 "avail", to determine the availability of two domain names in the 869 "idn-release" custom launch phase: 871 C: 872 C: 873 C: 874 C: 875 C: 877 C: domain1.example 878 C: domain2.example 879 C: 880 C: 881 C: 882 C: 885 C: custom 886 C: 887 C: 888 C: ABC-12345 889 C: 890 C: 892 The Availability Check Form does not define any extension to the 893 response of an domain command. After processing the command, 894 the server replies with a standard EPP response as defined in the EPP 895 domain name mapping [RFC5731]. 897 3.1.3. Trademark Check Form 899 The Trademark Check Form defines a new command called the Trademark 900 Check Command that is used to determine whether or not there are any 901 matching trademarks for each domain name passed in the command, 902 independent of the active launch phase of the server and whether the 903 "Claims Create Form" is required on a Domain Create Command. The 904 availability check information defined in the EPP domain name mapping 905 [RFC5731] MUST NOT be returned for the Trademark Check Command. This 906 form MUST be identified by setting the "type" 907 attribute to "trademark". 909 Instead of returning whether the domain name is available, the 910 Trademark Check Command will return whether or not at least one 911 matching trademark exists for the domain name. If there is at least 912 one matching trademark that exists for the domain name, a 913 element is returned. The client MAY then use the 914 value of the element to obtain Trademark Claims 915 Notice information from Trademark Validator based on the Validator 916 Identifier (Section 2.2). 918 The elements in the EPP command of EPP domain 919 name mapping [RFC5731] define the domain names to check for matching 920 trademarks. The element does not contain any child 921 elements with the "Trademark Check Form": 923 Example Trademark Check command using the domain command and 924 the extension with the "type" set to "trademark", to 925 determine if "domain1.example", "domain2.example", and 926 "domain3.example" have any matching trademarks: 928 C: 929 C: 930 C: 931 C: 932 C: 934 C: domain1.example 935 C: domain2.example 936 C: domain3.example 937 C: 938 C: 939 C: 940 C: 943 C: 944 C: ABC-12345 945 C: 946 C: 948 If the command has been processed successfully, the EPP 949 MUST contain an element that 950 identifies the launch namespace. The element 951 contains the following child elements: 953 One or more elements that contain the 954 following child elements: 956 Contains the fully qualified name of the queried 957 domain name. This element MUST contain an "exists" attribute 958 whose value indicates if a matching trademark exists for the 959 domain name. A value of "1" (or "true") means that a 960 matching trademark does exist. A value of "0" (or "false") 961 means that a matching trademark does not exist. 962 Zero or more OPTIONAL claim keys that MAY be 963 passed to a third-party Trademark Validator such as the ICANN 964 Trademark Clearinghouse (TMCH) for querying the information 965 needed to generate a Trademark Claims Notice. The 966 is used as the key for the query in place 967 of the domain name to securely query the service without 968 using a well-known value like a domain name. The OPTIONAL 969 "validatorID" attribute is the Validator Identifier 970 (Section 2.2) whose value indicates which Trademark Validator 971 to query for the Claims Notice information, with the default 972 being the ICANN TMCH. The "validatorID" attribute MAY 973 reference a non-trademark claims clearinghouse identifer to 974 support other forms of claims notices. 976 Example Trademark Check response when no matching trademarks are 977 found for the domain name domain1.example, matching trademarks are 978 found for the domain name domain2.example in the "tmch", matching 979 trademarks are found for domain name domain3.example in the "tmch" 980 and "custom-tmch", for the "claims" launch phase: 982 S: 983 S: 984 S: 985 S: 986 S: Command completed successfully 987 S: 988 S: 989 S: 991 S: 992 S: domain1.example 993 S: 994 S: 995 S: domain2.example 996 S: 997 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 998 S: 999 S: 1000 S: 1001 S: domain3.example 1002 S: 1003 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 1004 S: 1005 S: 1006 S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 1007 S: 1008 S: 1009 S: 1010 S: 1011 S: 1012 S: ABC-12345 1013 S: 54321-XYZ 1014 S: 1015 S: 1016 S: 1018 3.2. EPP Command 1020 This extension defines additional elements to extend the EPP 1021 command and response to be used in conjunction with the EPP domain 1022 name mapping [RFC5731]. 1024 The EPP command is used to retrieve information for a launch 1025 phase registration or application. The Application Identifier 1026 (Section 2.1) returned in the element of the create 1027 response (Section 3.3) is used for retrieving information for a 1028 Launch Application. A element is sent along with the 1029 regular domain command. The element includes an 1030 OPTIONAL "includeMark" boolean attribute, with a default value of 1031 "false", to indicate whether or not to include the mark in the 1032 response. The element contains the following child 1033 elements: 1035 The phase during which the application or 1036 registration was submitted or is associated with. Server policy 1037 defines the phases that are supported. 1038 OPTIONAL application identifier of the Launch 1039 Application. 1041 Example domain command with the extension to 1042 retrieve information for the sunrise application for domain.example 1043 and application identifier "abc123": 1045 C: 1046 C: 1047 C: 1048 C: 1049 C: 1051 C: domain.example 1052 C: 1053 C: 1054 C: 1055 C: 1058 C: sunrise 1059 C: abc123 1060 C: 1061 C: 1062 C: ABC-12345 1063 C: 1064 C: 1065 Example domain command with the extension to 1066 retrieve information for the sunrise registration for domain.example: 1068 C: 1069 C: 1070 C: 1071 C: 1072 C: 1074 C: domain.example 1075 C: 1076 C: 1077 C: 1078 C: 1080 C: sunrise 1081 C: 1082 C: 1083 C: ABC-12345 1084 C: 1085 C: 1087 If the query was successful, the server replies with a 1088 element along with the regular EPP . The 1089 contains the following child elements: 1091 The phase during which the application was submitted, 1092 or is associated with, that matches the associated command 1093 . 1094 OPTIONAL Application Identifier of the Launch 1095 Application. 1096 OPTIONAL status of the Launch Application using one 1097 of the supported status values (Section 2.4). 1098 Zero or more (Section 2.6.2) elements. 1100 Example domain response using the extension 1101 with the mark information: 1103 S: 1104 S: 1105 S: 1106 S: 1107 S: Command completed successfully 1108 S: 1109 S: 1110 S: 1112 S: domain.example 1113 S: EXAMPLE1-REP 1114 S: 1115 S: jd1234 1116 S: sh8013 1117 S: sh8013 1118 S: ClientX 1119 S: ClientY 1120 S: 2012-04-03T22:00:00.0Z 1121 S: 1122 S: 2fooBAR 1123 S: 1124 S: 1125 S: 1126 S: 1127 S: 1129 S: sunrise 1130 S: abc123 1131 S: 1132 S: 1134 S: ... 1135 S: 1136 S: 1137 S: 1138 S: 1139 S: ABC-12345 1140 S: 54321-XYZ 1141 S: 1142 S: 1143 S: 1145 3.3. EPP Command 1147 There are four forms of the extension to the EPP command 1148 that include the Sunrise Create Form (Section 3.3.1), the Claims 1149 Create Form (Section 3.3.2), the General Create Form (Section 3.3.3), 1150 and the Mixed Create Form (Section 3.3.4). The form is dependent on 1151 the supported launch phases (Section 2.3) as defined below. 1153 sunrise The EPP command with the "sunrise" launch phase is 1154 used to submit a registration with trademark information that can 1155 be verified by the server with the value. The 1156 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 1157 launch phase. 1158 landrush The EPP command with the "landrush" launch phase 1159 MAY use the General Create Form (Section 3.3.3) to explicitly 1160 specify the phase and optionally define the expected type of 1161 object to create. 1162 claims The EPP command with the "claims" launch phase is 1163 used to pass the information associated with the presentation and 1164 acceptance of the Claims Notice. The Claims Create Form 1165 (Section 3.3.2) is used and the General Create Form 1166 (Section 3.3.3) MAY be used for the "claims" launch phase. 1167 open The EPP command with the "open" launch phase is 1168 undefined but the form supported is up to server policy. Use of 1169 the Claims Create Form (Section 3.3.2) MAY be used to pass the 1170 information associated with the presentation and acceptance of the 1171 Claims Notice if required for the domain name. 1172 custom The EPP command with the "custom" launch phase is 1173 undefined but the form supported is up to server policy. 1175 3.3.1. Sunrise Create Form 1177 The Sunrise Create Form of the extension to the EPP domain name 1178 mapping [RFC5731] includes the verifiable trademark information that 1179 the server uses to match against the domain name to authorize the 1180 domain create. A server MUST support one of four models in Claim 1181 Validation Models (Section 2.6) to verify the trademark information 1182 passed by the client. 1184 A element is sent along with the regular 1185 domain command. The element has an OPTIONAL "type" 1186 attribute that defines the expected type of object ("application" or 1187 "registration") to create. The server SHOULD validate the "type" 1188 attribute, when passed, against the type of object that will be 1189 created. The element contains the following child 1190 elements: 1192 The identifier for the launch phase. 1194 or or 1196 Zero or more elements. The 1197 child elements are defined in the 1198 element (Section 2.6.1) section. 1199 Zero or more elements. The 1200 child elements are defined in the 1201 element (Section 2.6.3.1) section. 1202 Zero or more 1203 elements. The child elements are 1204 defined in the element 1205 (Section 2.6.3.2) section. 1207 The following is an example domain command using the 1208 extension, following the "code" validation model, 1209 with multiple sunrise codes: 1211 C: 1212 C: 1213 C: 1214 C: 1215 C: 1217 C: domain.example 1218 C: jd1234 1219 C: sh8013 1220 C: sh8013 1221 C: 1222 C: 2fooBAR 1223 C: 1224 C: 1225 C: 1226 C: 1227 C: 1229 C: sunrise 1230 C: 1231 C: 1232 C: 49FD46E6C4B45C55D4AC 1233 C: 1234 C: 1235 C: 49FD46E6C4B45C55D4AD 1236 C: 1237 C: 1238 C: 1239 C: 49FD46E6C4B45C55D4AE 1240 C: 1241 C: 1242 C: 1243 C: ABC-12345 1244 C: 1245 C: 1246 The following is an example domain command using the 1247 extension, following the "mark" validation model, 1248 with the mark information: 1250 C: 1251 C: 1252 C: 1253 C: 1254 C: 1256 C: domainone.example 1257 C: jd1234 1258 C: sh8013 1259 C: sh8013 1260 C: 1261 C: 2fooBAR 1262 C: 1263 C: 1264 C: 1265 C: 1266 C: 1268 C: sunrise 1269 C: 1270 C: 1272 C: ... 1273 C: 1274 C: 1275 C: 1276 C: 1277 C: ABC-12345 1278 C: 1279 C: 1280 The following is an example domain command using the 1281 extension, following the "code with mark" validation 1282 model, with a code and mark information: 1284 C: 1285 C: 1286 C: 1287 C: 1288 C: 1290 C: domain.example 1291 C: jd1234 1292 C: sh8013 1293 C: sh8013 1294 C: 1295 C: 2fooBAR 1296 C: 1297 C: 1298 C: 1299 C: 1300 C: 1302 C: sunrise 1303 C: 1304 C: 1305 C: 49FD46E6C4B45C55D4AC 1306 C: 1308 C: ... 1309 C: 1310 C: 1311 C: 1312 C: 1313 C: ABC-12345 1314 C: 1315 C: 1316 The following is an example domain command using the 1317 extension, following the "signed mark" validation 1318 model, with the signed mark information for a sunrise application: 1320 C: 1321 C: 1322 C: 1323 C: 1324 C: 1326 C: domainone.example 1327 C: jd1234 1328 C: sh8013 1329 C: sh8013 1330 C: 1331 C: 2fooBAR 1332 C: 1333 C: 1334 C: 1335 C: 1336 C: 1339 C: sunrise 1340 C: 1342 C: ... 1343 C: 1344 C: 1345 C: 1346 C: ABC-12345 1347 C: 1348 C: 1349 The following is an example domain command using the 1350 extension, following the "signed mark" validation 1351 model, with the base64 encoded signed mark information: 1353 C: 1354 C: 1355 C: 1356 C: 1357 C: 1359 C: domainone.example 1360 C: jd1234 1361 C: sh8013 1362 C: sh8013 1363 C: 1364 C: 2fooBAR 1365 C: 1366 C: 1367 C: 1368 C: 1369 C: 1371 C: sunrise 1372 C: 1374 C: ... 1375 C: 1376 C: 1377 C: 1378 C: ABC-12345 1379 C: 1380 C: 1382 3.3.2. Claims Create Form 1384 The Claims Create Form of the extension to the EPP domain name 1385 mapping [RFC5731] includes the information related to the 1386 registrant's acceptance of the Claims Notice. 1388 A element is sent along with the regular 1389 domain command. The element has an OPTIONAL "type" 1390 attribute that defines the expected type of object ("application" or 1391 "registration") to create. The server SHOULD validate the "type" 1392 attribute, when passed, against the type of object that will be 1393 created. The element contains the following child 1394 elements: 1396 Contains the value of the active launch phase of the 1397 server. The server SHOULD validate the value against the active 1398 server launch phase. 1399 One or more elements that contain 1400 the following child elements: 1402 Unique notice identifier for the Claims 1403 Notice. The element has an OPTIONAL 1404 "validatorID" attribute is the Validator Identifier 1405 (Section 2.2) whose value indicates which Trademark Validator 1406 is the source of the claims notice, with the default being 1407 the ICANN TMCH. 1408 Expiry of the claims notice. 1409 Contains the date and time that the claims 1410 notice was accepted. 1412 The following is an example domain command using the 1413 extension with the information for 1414 the "tmch" and the "custom-tmch" validators, for the "claims" launch 1415 phase: 1417 C: 1418 C: 1419 C: 1420 C: 1421 C: 1423 C: domain.example 1424 C: jd1234 1425 C: sh8013 1426 C: sh8013 1427 C: 1428 C: 2fooBAR 1429 C: 1430 C: 1431 C: 1432 C: 1433 C: 1435 C: claims 1436 C: 1437 C: 1438 C: 370d0b7c9223372036854775807 1439 C: 2014-06-19T10:00:00.0Z 1440 C: 1441 C: 2014-06-19T09:00:00.0Z 1442 C: 1443 C: 1444 C: 1445 C: 1446 C: 470d0b7c9223654313275808 1447 C: 2014-06-19T10:00:00.0Z 1448 C: 1449 C: 2014-06-19T09:00:30.0Z 1450 C: 1451 C: 1452 C: 1453 C: 1454 C: ABC-12345 1455 C: 1456 C: 1458 3.3.3. General Create Form 1460 The General Create Form of the extension to the EPP domain name 1461 mapping [RFC5731] includes the launch phase and optionally the object 1462 type to create. The OPTIONAL "type" attribute defines the expected 1463 type of object ("application" or "registration") to create. The 1464 server SHOULD validate the "type" attribute, when passed, against the 1465 type of object that will be created. 1467 A element is sent along with the regular 1468 domain command. The element contains the following 1469 child elements: 1471 Contains the value of the active launch phase of the 1472 server. The server SHOULD validate the value against the active 1473 server launch phase. 1475 The following is an example domain command using the 1476 extension for a "landrush" launch phase application: 1478 C: 1479 C: 1480 C: 1481 C: 1482 C: 1484 C: domain.example 1485 C: jd1234 1486 C: sh8013 1487 C: sh8013 1488 C: 1489 C: 2fooBAR 1490 C: 1491 C: 1492 C: 1493 C: 1494 C: 1497 C: landrush 1498 C: 1499 C: 1500 C: ABC-12345 1501 C: 1502 C: 1504 3.3.4. Mixed Create Form 1506 The Mixed Create Form supports a mix of the create forms, where for 1507 example the Sunrise Create Form (Section 3.3.1) and the Claims Create 1508 Form (Section 3.3.2) MAY be supported in a single command by 1509 including both the verified trademark information and the information 1510 related to the registrant's acceptance of the Claims Notice. The 1511 server MAY support the Mixed Create Form. The "custom" launch phase 1512 SHOULD be used when using the Mixed Create Form. 1514 The following is an example domain command using the 1515 extension, with using a mix of the Sunrise Create 1516 Form (Section 3.3.1) and the Claims Create Form (Section 3.3.2) by 1517 including both a mark and a notice: 1519 C: 1520 C: 1521 C: 1522 C: 1523 C: 1525 C: domainone.example 1526 C: jd1234 1527 C: sh8013 1528 C: sh8013 1529 C: 1530 C: 2fooBAR 1531 C: 1532 C: 1533 C: 1534 C: 1535 C: 1538 C: custom 1539 C: 1540 C: 1542 C: ... 1543 C: 1544 C: 1545 C: 1546 C: 1547 C: 49FD46E6C4B45C55D4AC 1548 C: 1549 C: 2012-06-19T10:00:10.0Z 1550 C: 1551 C: 2012-06-19T09:01:30.0Z 1552 C: 1553 C: 1554 C: 1555 C: 1556 C: ABC-12345 1557 C: 1558 C: 1560 3.3.5. Create Response 1562 If the create was successful, the server MAY reply with the 1563 element along with the regular EPP to 1564 indicate the server generated Application Identifier (Section 2.1), 1565 when multiple applications of a given domain name are supported; 1566 otherwise no extension is included with the regular EPP . 1567 The element contains the following child elements: 1569 The phase of the application that mirrors the 1570 element included in the . 1571 The application identifier of the 1572 application. 1574 An example response when multiple overlapping applications are 1575 supported by the server: 1577 S: 1578 S: 1579 S: 1580 S: 1581 S: Command completed successfully; action pending 1582 S: 1583 S: 1584 S: 1586 S: domain.example 1587 S: 2010-08-10T15:38:26.623854Z 1588 S: 1589 S: 1590 S: 1591 S: 1593 S: sunrise 1594 S: 2393-9323-E08C-03B1 1595 S: 1596 S: 1597 S: 1598 S: 1599 S: ABC-12345 1600 S: 54321-XYZ 1601 S: 1602 S: 1603 S: 1605 3.4. EPP Command 1607 This extension defines additional elements to extend the EPP 1608 command to be used in conjunction with the domain name mapping. 1610 A client MUST NOT pass the extension on an EPP command to a 1611 server that does not support launch applications. A server that does 1612 not support launch applications during its launch phase MUST return 1613 an EPP error result code of 2102 when receiving an EPP 1614 command with the extension. 1616 Registry policies permitting, clients may update an application 1617 object by submitting an EPP command along with a 1618 element to indicate the application object to be 1619 updated. The element contains the following child 1620 elements: 1622 The phase during which the application was submitted 1623 or is associated with. 1624 The application identifier for which the 1625 client wishes to update. 1627 The following is an example domain command with the 1628 extension to add and remove a name server of a 1629 sunrise application with the application identifier "abc123": 1631 C: 1632 C: 1633 C: 1634 C: 1635 C: 1637 C: domain.example 1638 C: 1639 C: 1640 C: ns2.domain.example 1641 C: 1642 C: 1643 C: 1644 C: 1645 C: ns1.domain.example 1646 C: 1647 C: 1648 C: 1649 C: 1650 C: 1651 C: 1653 C: sunrise 1654 C: abc123 1655 C: 1656 C: 1657 C: ABC-12345 1658 C: 1659 C: 1661 This extension does not define any extension to the response of an 1662 domain command. After processing the command, the server 1663 replies with a standard EPP response as defined in the EPP domain 1664 name mapping [RFC5731]. 1666 3.5. EPP Command 1668 This extension defines additional elements to extend the EPP 1669 command to be used in conjunction with the domain name mapping. 1671 A client MUST NOT pass the extension on an EPP command to a 1672 server that does not support launch applications. A server that does 1673 not support launch applications during its launch phase MUST return 1674 an EPP error result code of 2102 when receiving an EPP 1675 command with the extension. 1677 Registry policies permitting, clients MAY withdraw an application by 1678 submitting an EPP command along with a 1679 element to indicate the application object to be deleted. The 1680 element contains the following child elements: 1682 The phase during which the application was submitted 1683 or is associated with. 1684 The application identifier for which the 1685 client wishes to delete. 1687 The following is an example domain command with the 1688 extension: 1690 C: 1691 C: 1692 C: 1693 C: 1694 C: 1696 C: domain.example 1697 C: 1698 C: 1699 C: 1700 C: 1702 C: sunrise 1703 C: abc123 1704 C: 1705 C: 1706 C: ABC-12345 1707 C: 1708 C: 1710 This extension does not define any extension to the response of a 1711 domain command. After processing the command, the server 1712 replies with a standard EPP response as defined in the EPP domain 1713 name mapping [RFC5731]. 1715 3.6. EPP Command 1717 This extension does not define any extension to the EPP 1718 command or response described in the EPP domain name mapping 1719 [RFC5731]. 1721 3.7. EPP Command 1723 This extension does not define any extension to the EPP 1724 command or response described in the EPP domain name mapping 1725 [RFC5731]. 1727 4. Formal Syntax 1729 One schema is presented here that is the EPP Launch Phase Mapping 1730 schema. 1732 The formal syntax presented here is a complete schema representation 1733 of the object mapping suitable for automated validation of EPP XML 1734 instances. The BEGIN and END tags are not part of the schema; they 1735 are used to note the beginning and ending of the schema for URI 1736 registration purposes. 1738 4.1. Launch Schema 1740 Copyright (c) 2017 IETF Trust and the persons identified as authors 1741 of the code. All rights reserved. 1743 Redistribution and use in source and binary forms, with or without 1744 modification, are permitted provided that the following conditions 1745 are met: 1747 o Redistributions of source code must retain the above copyright 1748 notice, this list of conditions and the following disclaimer. 1749 o Redistributions in binary form must reproduce the above copyright 1750 notice, this list of conditions and the following disclaimer in 1751 the documentation and/or other materials provided with the 1752 distribution. 1753 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1754 names of specific contributors, may be used to endorse or promote 1755 products derived from this software without specific prior written 1756 permission. 1758 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1759 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1760 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1761 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1762 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1763 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1764 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1765 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1766 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1767 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1768 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1770 BEGIN 1771 1772 1781 1784 1785 1786 1788 1789 1790 Extensible Provisioning Protocol v1.0 1791 domain name extension schema 1792 for the launch phase processing. 1793 1794 1796 1799 1800 1801 1802 1803 1805 1808 1809 1810 1812 1814 1815 1817 1820 1821 1822 1824 1830 1831 1832 1833 1834 1835 1836 1838 1841 1842 1843 1844 1845 1846 1847 1848 1849 1851 1854 1855 1856 1857 1858 1860 1861 1862 1863 1866 1867 1868 1870 1873 1874 1875 1876 1877 1879 1880 1881 1882 1884 1885 1886 1888 1891 1892 1893 1894 1895 1897 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1912 1915 1916 1917 1918 1920 1922 1923 1924 1925 1927 1931 1932 1933 1935 1937 1938 1940 1943 1944 1945 1946 1947 1949 1951 1953 1954 1957 1958 1959 1961 1964 1965 1966 1967 1968 1969 1971 1974 1975 1976 1977 1978 1979 1980 1982 1985 1986 1987 1989 1990 1992 1994 1998 1999 2000 2001 2002 2003 2004 2005 2008 2009 2010 2011 2014 2015 2017 2019 2022 2023 2024 2026 2029 2030 2031 2033 2035 2036 2038 2039 2040 2041 2043 2044 2046 2047 2048 2049 2051 2052 2054 2056 2057 2058 2059 2061 2062 2063 2065 2068 2069 2070 2071 2074 2076 2078 2079 2081 2082 END 2084 5. IANA Considerations 2086 5.1. XML Namespace 2088 This document uses URNs to describe XML namespaces and XML schemas 2089 conforming to a registry mechanism described in [RFC3688]. 2091 Registration request for the launch namespace: 2093 URI: urn:ietf:params:xml:ns:launch-1.0 2094 Registrant Contact: See the "Author's Address" section of this 2095 document. 2096 XML: None. Namespace URIs do not represent an XML specification. 2098 Registration request for the launch XML schema: 2100 URI: urn:ietf:params:xml:schema:launch-1.0 2101 Registrant Contact: See the "Author's Address" section of this 2102 document. 2103 XML: See the "Formal Syntax" section of this document. 2105 5.2. EPP Extension Registry 2107 The EPP extension described in this document should be registered by 2108 the IANA in the EPP Extension Registry described in [RFC7451]. The 2109 details of the registration are as follows: 2111 Name of Extension: "Launch Phase Mapping for the Extensible 2112 Provisioning Protocol (EPP)" 2114 Document status: Standards Track 2116 Reference: (insert reference to RFC version of this document) 2118 Registrant Name and Email Address: IESG, 2120 TLDs: Any 2122 IPR Disclosure: None 2124 Status: Active 2126 Notes: None 2128 6. Implementation Status 2130 Note to RFC Editor: Please remove this section and the reference to 2131 RFC 7942 [RFC7942] before publication. 2133 This section records the status of known implementations of the 2134 protocol defined by this specification at the time of posting of this 2135 Internet-Draft, and is based on a proposal described in RFC 7942 2136 [RFC7942]. The description of implementations in this section is 2137 intended to assist the IETF in its decision processes in progressing 2138 drafts to RFCs. Please note that the listing of any individual 2139 implementation here does not imply endorsement by the IETF. 2140 Furthermore, no effort has been spent to verify the information 2141 presented here that was supplied by IETF contributors. This is not 2142 intended as, and must not be construed to be, a catalog of available 2143 implementations or their features. Readers are advised to note that 2144 other implementations may exist. 2146 According to RFC 7942 [RFC7942], "this will allow reviewers and 2147 working groups to assign due consideration to documents that have the 2148 benefit of running code, which may serve as evidence of valuable 2149 experimentation and feedback that have made the implemented protocols 2150 more mature. It is up to the individual working groups to use this 2151 information as they see fit". 2153 6.1. Verisign EPP SDK 2155 Organization: Verisign Inc. 2157 Name: Verisign EPP SDK 2159 Description: The Verisign EPP SDK includes both a full client 2160 implementation and a full server stub implementation of draft-ietf- 2161 regext-launchphase. 2163 Level of maturity: Production 2165 Coverage: All aspects of the protocol are implemented. 2167 Licensing: GNU Lesser General Public License 2169 Contact: jgould@verisign.com 2171 URL: http://www.verisigninc.com/en_US/channel-resources/domain- 2172 registry-products/epp-sdks 2174 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 2176 Organization: Verisign Inc. 2178 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 2179 System (SRS) 2181 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 2182 Registry System (SRS) implements the server-side of draft-ietf- 2183 regext-launchphase for a variety of Top Level Domains (TLD's). 2185 Level of maturity: Production 2187 Coverage: The "signed mark" Mark Validation Model, the Claims Check 2188 Form for the EPP Command, the Sunrise and Claims Forms for 2189 the EPP Command of Launch Registrations and Launch 2190 Applications. For Launch Applications the Poll Messaging, the EPP 2191 Command, the EPP Command, and the EPP 2192 Command is covered. 2194 Licensing: Proprietary 2196 Contact: jgould@verisign.com 2198 6.3. Verisign .COM / .NET SRS 2200 Organization: Verisign Inc. 2202 Name: Verisign .COM / .NET Shared Registry System (SRS) 2204 Description: The Verisign Shared Registry System (SRS) for .COM, .NET 2205 and other IDN TLD's implements the server-side of draft-ietf-regext- 2206 launchphase. 2208 Level of maturity: Operational Test Environment (OTE) 2210 Coverage: The "signed mark" Mark Validation Model, the Claims Check 2211 Form for the EPP Command, the Sunrise and Claims Forms for 2212 the EPP Command of Launch Registrations. 2214 Licensing: Proprietary 2216 Contact: jgould@verisign.com 2218 6.4. REngin v3.7 2220 Organization: Domain Name Services (Pty) Ltd 2222 Name: REngin v3.7 2224 Description: Server side implementation only 2226 Level of maturity: Production 2228 Coverage: All features from version 12 have been implemented 2230 Licensing: Proprietary Licensing with Maintenance Contracts 2232 Contact: info@dnservices.co.za 2234 URL: https://www.registry.net.za and soon http://dnservices.co.za 2236 6.5. RegistryEngine EPP Service 2238 Organization: CentralNic 2240 Name: RegistryEngine EPP Service 2242 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 2243 SLDs 2244 Level of maturity: Deployed in CentralNic's production environment as 2245 well as two other gTLD registry systems, and two ccTLD registry 2246 systems. 2248 Coverage: Majority of elements including TMCH sunrise, landrush and 2249 TM claims as well as sunrise applications validated using codes. 2251 Licensing: Proprietary In-House software 2253 Contact: epp@centralnic.com 2255 URL: https://www.centralnic.com 2257 6.6. Neustar EPP SDK 2259 Organization: Neustar 2261 Name: Neustar EPP SDK 2263 Description: The Neustar EPP SDK includes client implementation of 2264 draft-ietf-regext-launchphase in both Java and C++. 2266 Level of maturity: Production 2268 Coverage: All aspects of the protocol are implemented. 2270 Licensing: GNU Lesser General Public License 2272 Contact: trung.tran@neustar.biz 2274 6.7. gTLD Shared Registry System 2276 Organization: Stichting Internet Domeinnaamregistratie Nederland 2277 (SIDN) 2279 Name: gTLD Shared Registry System 2281 Description: The gTLD SRS implements the server side of the draft- 2282 ietf-regext-launchphase. 2284 Level of maturity: (soon) Production 2286 Coverage: The following parts of the draft are supported: 2288 Signed mark validation model using Digital Signature 2289 (Section 2.6.3) 2290 Claims Check Form (Section 3.1.1) 2291 Sunrise Create Form (Section 3.3.1) 2292 Claims Create Form (Section 3.3.2) 2294 The parts of the document not described here are not implemented. 2296 Licensing: Proprietary 2298 Contact: rik.ribbers@sidn.nl 2300 7. Security Considerations 2302 The mapping extensions described in this document do not provide any 2303 security services beyond those described by EPP [RFC5730], the EPP 2304 domain name mapping [RFC5731], and protocol layers used by EPP. The 2305 security considerations described in these other specifications apply 2306 to this specification as well. 2308 Updates to, and deletion of an application object must be restricted 2309 to clients authorized to perform the said operation on the object. 2311 As information contained within an application, or even the mere fact 2312 that an application exists may be confidential. Any attempt to 2313 operate on an application object by an unauthorized client MUST be 2314 rejected with an EPP 2201 (authorization error) return code. Server 2315 policy may allow operation with filtered output by clients 2316 other than the sponsoring client, in which case the 2317 and response SHOULD be filtered to include only 2318 fields that are publicly accessible. 2320 8. Acknowledgements 2322 The authors wish to acknowledge the efforts of the leading 2323 participants of the Community TMCH Model that led to many of the 2324 changes to this document, which include Chris Wright, Jeff Neuman, 2325 Jeff Eckhaus, and Will Shorter. 2327 Special suggestions that have been incorporated into this document 2328 were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Scott 2329 Hollenbeck, Michael Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, 2330 Gustavo Lozano, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, 2331 James Mitchell, Francisco Obispo, Mike O'Connell, Bernhard Reutner- 2332 Fischer, Trung Tran, Ulrich Wisser and Sharon Wodjenski. 2334 Some of the description of the Trademark Claims Phase was based on 2335 the work done by Gustavo Lozano in the ICANN TMCH functional 2336 specifications. 2338 9. References 2340 9.1. Normative References 2342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2343 Requirement Levels", BCP 14, RFC 2119, 2344 DOI 10.17487/RFC2119, March 1997, 2345 . 2347 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2348 DOI 10.17487/RFC3688, January 2004, 2349 . 2351 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2352 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 2353 . 2355 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2356 Domain Name Mapping", STD 69, RFC 5731, 2357 DOI 10.17487/RFC5731, August 2009, 2358 . 2360 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2361 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2362 . 2364 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2365 Code: The Implementation Status Section", BCP 205, 2366 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2367 . 2369 9.2. Informative References 2371 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 2372 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 2373 February 2015, . 2375 Appendix A. Change History 2377 A.1. Change from 00 to 01 2379 1. Changed to use camel case for the XML elements. 2380 2. Replaced "cancelled" status to "rejected" status. 2381 3. Added the child elements of the element. 2382 4. Removed the XML schema and replaced with "[TBD]". 2384 A.2. Change from 01 to 02 2386 1. Added support for both the ICANN and ARI/Neustar TMCH models. 2387 2. Changed the namespace URI and prefix to use "launch" instead of 2388 "launchphase". 2389 3. Added definition of multiple claim validation models. 2390 4. Added the and 2391 elements. 2392 5. Added support for Claims Info Command 2394 A.3. Change from 02 to 03 2396 1. Removed XSI namespace per Keith Gaughan's suggestion on the 2397 provreg list. 2398 2. Added extensibility to the launch:status element and added the 2399 pendingAuction status per Trung Tran's feedback on the provreg 2400 list. 2401 3. Added support for the Claims Check Command, updated the location 2402 and contents of the signedNotice, and replaced most references of 2403 Claim to Mark based on the work being done on the ARI/Neustar 2404 launch model. 2406 A.4. Change from 03 to 04 2408 1. Removed references to the ICANN model. 2409 2. Removed support for the Claims Info Command. 2410 3. Removed use of the signedClaim. 2411 4. Revised the method for referring to the signedClaim from the XML 2412 Signature using the IDREF URI. 2413 5. Split the launch-1.0.xsd into three XML schemas including launch- 2414 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 2415 6. Split the "claims" launch phase to the "claims1" and "claims2" 2416 launch phases. 2417 7. Added support for the encodedSignedMark with base64 encoded 2418 signedMark. 2419 8. Changed the elements in the createNoticeType to include the 2420 noticeID, timestamp, and the source elements. 2421 9. Added the class and effectiveDate elements to mark. 2423 A.5. Change from 04 to 05 2425 1. Removed reference to in the example. 2426 2. Incorporated feedback from Bernhard Reutner-Fischer on the 2427 provreg mail list. 2428 3. Added missing launch XML prefix to applicationIDType reference in 2429 the idContainerType of the Launch Schema. 2430 4. Added missing description of the element in the 2431 element. 2433 5. Updated note on replication of the EPP contact mapping elements 2434 in the Mark Contact section. 2436 A.6. Change from 05 to 06 2438 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 2439 replaced with reference to draft-lozano-smd, that contains the 2440 definition for the mark, signed marked, and encoded signed mark. 2441 2. Split the into and 2442 based on feedback from Trung Tran. 2443 3. Added the "includeMark" optional attribute to the 2444 element to enable the client to request whether or not to include 2445 the mark in the info response. 2446 4. Fixed state diagram to remove redundant transition from "invalid" 2447 to "rejected"; thanks Klaus Malorny. 2449 A.7. Change from 06 to 07 2451 1. Proof-read grammar and spelling. 2452 2. Changed "pendingAuction" status to "pendingAllocation", changed 2453 "pending" to "pendingValidation" status, per proposal from Trung 2454 Tran and seconded by Rubens Kuhl. 2455 3. Added text related to the use of RFC 5731 pendingCreate to the 2456 Application Identifier section. 2457 4. Added the Poll Messaging section to define the use of poll 2458 messaging for intermediate state transitions and pending action 2459 poll messaging for final state transitions. 2461 A.8. Change from 07 to 08 2463 1. Added support for use of the launch statuses and poll messaging 2464 for Launch Registrations based on feedback from Sharon Wodjenski 2465 and Trung Tran. 2466 2. Incorporated changes based on updates or clarifications in draft- 2467 lozano-tmch-func-spec-01, which include: 2469 1. Removed the unused element. 2470 2. Removed the element. 2471 3. Added the element based on the required 2472 element. 2474 A.9. Change from 08 to 09 2476 1. Made element optional in to allow 2477 passing just the in per request 2478 from Ben Levac. 2479 2. Added optional "type" attribute in to enable the 2480 client to explicitly define the desired type of object 2481 (application or registration) to create to all forms of the 2482 create extension. 2483 3. Added text that the server SHOULD validate the 2484 element in the Launch Phases section. 2485 4. Add the "General Create Form" to the create command extension to 2486 support the request from Ben Levac. 2487 5. Updated the text for the Poll Messaging section based on feedback 2488 from Klaus Malorny. 2489 6. Replaced the "claims1" and "claims2" phases with the "claims" 2490 phase based on discussion on the provreg list. 2491 7. Added support for a mixed create model (Sunrise Create Model and 2492 Claims Create Model), where a trademark (encoded signed mark, 2493 etc.) and notice can be passed, based on a request from James 2494 Mitchell. 2495 8. Added text for the handling of the overlapping "claims" and 2496 "landrush" launch phases. 2497 9. Added support for two check forms (claims check form and 2498 availability check form) based on a request from James Mitchell. 2499 The availability check form was based on the text in draft-rbp- 2500 application-epp-mapping. 2502 A.10. Change from 09 to 10 2504 1. Changed noticeIDType from base64Binary to token to be compatible 2505 with draft-lozano-tmch-func-spec-05. 2506 2. Changed codeType from base64Binary to token to be more generic. 2507 3. Updated based on feedback from Alexander Mayrhofer, which 2508 include: 2510 1. Changed "extension to the domain name extension" to 2511 "extension to the domain name mapping". 2512 2. Changed use of 2004 return code to 2306 return code when 2513 phase passed mismatches active phase and sub-phase. 2514 3. Changed description of "allocated" and "rejected" statuses. 2515 4. Moved sentence on a synchronous command 2516 without the use of an intermediate application, then an 2517 Application Identifier MAY not be needed to the Application 2518 Identifier section. 2519 5. Restructured the Mark Validation Models section to include 2520 the " element" sub-section, the 2521 " element" sub-section, and the Digital Signature 2522 sub-section. 2523 6. Changed "Registries may" to "Registries MAY". 2524 7. Changed "extensed" to "extended" in "Availability Check 2525 Form" section. 2526 8. Broke the mix of create forms in the "EPP Command" 2527 section to a fourth "Mixed Create Form" with its own sub- 2528 section. 2530 9. Removed "displayed or" from "displayed or accepted" in the 2531 description. 2532 10. Replaced "given domain name is supported" with "given domain 2533 name are supported" in the "Create Response" section. 2534 11. Changed the reference of 2303 (object does not exist) in the 2535 "Security Considerations" section to 2201 (authorization 2536 error). 2537 12. Added arrow from "invalid" status to "pendingValidation" 2538 status and "pendingAllocation" status to "rejected" status 2539 in the State Transition Diagram. 2540 4. Added the "C:" and "S:" example prefixes and related text in the 2541 "Conventions Used in This Document" section. 2543 A.11. Change from 10 to 11 2545 1. Moved the claims check response element under 2546 the element instead of the element based on 2547 the request from Francisco Obispo. 2549 A.12. Change from 11 to 12 2551 1. Added support for multiple validator identifiers for claims 2552 notices and marks based on a request and text provided by Mike 2553 O'Connell. 2554 2. Removed domain:exDate element from example in section 3.3.5 based 2555 on a request from Seth Goldman on the provreg list. 2556 3. Added clarifying text for clients not passing the launch 2557 extension on update and delete commands to servers that do not 2558 support launch applications based on a request from Sharon 2559 Wodjenski on the provreg list. 2561 A.13. Change from 12 to EPPEXT 00 2563 1. Changed to eppext working group draft by changing draft-tan-epp- 2564 launchphase to draft-ietf-eppext-launchphase and by changing 2565 references of draft-lozano-tmch-smd to draft-ietf-eppext-tmch- 2566 smd. 2568 A.14. Change EPPEXT 00 to EPPEXT 01 2570 1. Removed text associated with support for the combining of status 2571 values based on feedback from Patrick Mevzek on the provreg 2572 mailing list, discussion on the eppext mailing list, and 2573 discussion at the eppext IETF meeting on March 6, 2014. 2575 A.15. Change EPPEXT 01 to EPPEXT 02 2577 1. Changed the element to be zero or more elements 2578 and the element to be one or more elements in the 2579 Claims Create Form. These changes were needed to be able to 2580 support more than one concurrent claims services. 2582 A.16. Change EPPEXT 02 to EPPEXT 03 2584 1. Added the "Implementation Status" section based on an action item 2585 from the eppext IETF-91 meeting. 2586 2. Moved Section 7 "IANA Considerations" and Section 9 "Security 2587 Considerations" before Section 5 "Acknowledgements". Moved 2588 "Change Log" Section to end. 2589 3. Updated the text for the Claims Check Form and the Claims Create 2590 Form to support checking for the need of the claims notice and 2591 passing the claims notice outside of the "claims" phase. 2592 4. Added the new Trademark Check Form to support determining whether 2593 or not a trademark exists that matches the domain name 2594 independent of whether a claims notice is required on create. 2595 This was based on a request from Trung Tran and a discussion on 2596 the eppext mailing list. 2598 A.17. Change EPPEXT 03 to EPPEXT 04 2600 1. Amended XML Namespace section of IANA Considerations, added EPP 2601 Extension Registry section. 2603 A.18. Change EPPEXT 04 to EPPEXT 05 2605 1. Added a missing comma to the descripton of the 2606 element, based on feedback from Keith Gaughan on the eppext 2607 mailing list. 2608 2. Added the SIDN implementation status information. 2609 3. Fixed a few indentation issues in the samples. 2611 A.19. Change EPPEXT 05 to EPPEXT 06 2613 1. Removed duplicate "TMCH Functional Specification" URIs based on 2614 feedback from Scott Hollenbeck on the eppext mailing list. 2615 2. Changed references of example?.tld to domain?.example to be 2616 consistent with RFC 6761 based on feedback from Scott Hollenbeck 2617 on the eppext mailing list. 2618 3. A template was added to section 5 to register the XML schema in 2619 addition to the namespace based on feedback from Scott Hollenbeck 2620 on the eppext mailing list. 2622 A.20. Change EPPEXT 06 to EPPEXT 07 2624 1. Changed reference of lozano-tmch-func-spec to ietf-eppext-tmch- 2625 func-spec. 2627 A.21. Change from EPPEXT 07 to REGEXT 00 2629 1. Changed to regext working group draft by changing draft-ietf- 2630 eppext-launchphase to draft-ietf-regext-launchphase and by 2631 changing references of draft-ietf-eppext-tmch-func-spec to draft- 2632 ietf-regext-tmch-func-spec. 2634 A.22. Change from REGEXT 00 to REGEXT 01 2636 1. Fixed reference of Claims Check Command to Trademark Check 2637 Command in the Trademark Check Form section. 2638 2. Replaced reference of draft-ietf-eppext-tmch-smd to RFC 7848. 2640 A.23. Change from REGEXT 01 to REGEXT 02 2642 1. Removed the reference to ietf-regext-tmch-func-spec and briefly 2643 described the trademark claims phase that is relavent to draft- 2644 ietf-regext-launchphase. 2646 A.24. Change from REGEXT 02 to REGEXT 03 2648 1. Ping update. 2650 A.25. Change from REGEXT 03 to REGEXT 04 2652 1. Updates based on feedback from Scott Hollenbeck that include: 2654 1. Nit on reference to RFC 7848 in section 1. 2655 2. Added reference to for the request to create 2656 a Launch Application in section 2.1. 2657 3. Removed the second paragraph of section 2.1 describing the 2658 option of creating an application identifier for a Launch 2659 Registration. 2660 4. Provided clarification in section 2.2 on the responsibility 2661 of the server to ensure that the supported validator 2662 identifiers are unique. 2663 5. Updated the text in section 2.5 referencing the domain name 2664 object in RFC 5731. 2665 6. Updated the copyright to 2017 in section 4.1. 2667 A.26. Change from REGEXT 04 to REGEXT 05 2669 1. Updates based on feedback from Ulrich Wisser that include: 2671 1. Updated reference to obsoleted RFC 6982 with RFC 7942. 2672 2. Moved RFC 7451 reference from normative to informative. 2674 Authors' Addresses 2676 James Gould 2677 VeriSign, Inc. 2678 12061 Bluemont Way 2679 Reston, VA 20190 2680 US 2682 Email: jgould@verisign.com 2683 URI: http://www.verisigninc.com 2685 Wil Tan 2686 Cloud Registry 2687 Suite 32 Seabridge House 2688 377 Kent St 2689 Sydney, NSW 2000 2690 AU 2692 Phone: +61 414 710899 2693 Email: wil@cloudregistry.net 2694 URI: http://www.cloudregistry.net 2696 Gavin Brown 2697 CentralNic Ltd 2698 35-39 Mooregate 2699 London, England EC2R 6AR 2700 GB 2702 Phone: +44 20 33 88 0600 2703 Email: gavin.brown@centralnic.com 2704 URI: https://www.centralnic.com