idnits 2.17.1 draft-ietf-eppext-launchphase-06.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 (August 3, 2015) is 3189 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) == Outdated reference: A later version (-06) exists of draft-ietf-eppext-tmch-smd-02 ** Downref: Normative reference to an Informational draft: draft-lozano-tmch-func-spec (ref. 'I-D.lozano-tmch-func-spec') ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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: February 4, 2016 Cloud Registry 6 G. Brown 7 CentralNic Ltd 8 August 3, 2015 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-ietf-eppext-launchphase-06 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 February 4, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4.1. State Transition . . . . . . . . . . . . . . . . . . 8 62 2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . 9 63 2.6. Mark Validation Models . . . . . . . . . . . . . . . . . 12 64 2.6.1. element . . . . . . . . . . . . . . 13 65 2.6.2. element . . . . . . . . . . . . . . . . . 14 66 2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 14 67 2.6.3.1. element . . . . . . . . . . . . 14 68 2.6.3.2. element . . . . . . . . . 14 69 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 14 70 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 15 71 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 15 72 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 18 73 3.1.3. Trademark Check Form . . . . . . . . . . . . . . . . 20 74 3.2. EPP Command . . . . . . . . . . . . . . . . . . . 23 75 3.3. EPP Command . . . . . . . . . . . . . . . . . . 26 76 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 26 77 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . 32 78 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 35 79 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 36 80 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 38 81 3.4. EPP Command . . . . . . . . . . . . . . . . . . 39 82 3.5. EPP Command . . . . . . . . . . . . . . . . . . 40 83 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 41 84 3.7. EPP Command . . . . . . . . . . . . . . . . . 42 85 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 42 86 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 42 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 88 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 49 89 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 50 90 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 91 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 51 92 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 51 93 6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 52 94 6.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 52 95 6.5. RegistryEngine EPP Service . . . . . . . . . . . . . . . 52 96 6.6. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 53 97 6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 53 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 100 9. Normative References . . . . . . . . . . . . . . . . . . . . 54 101 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 55 102 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 55 103 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 55 104 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 56 105 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 56 106 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 56 107 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 56 108 A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 57 109 A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 57 110 A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 57 111 A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 58 112 A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 59 113 A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 59 114 A.13. Change from 12 to WG 00 . . . . . . . . . . . . . . . . . 59 115 A.14. Change WG 00 to WG 01 . . . . . . . . . . . . . . . . . . 59 116 A.15. Change WG 01 to WG 02 . . . . . . . . . . . . . . . . . . 59 117 A.16. Change WG 02 to WG 03 . . . . . . . . . . . . . . . . . . 60 118 A.17. Change WG 03 to WG 04 . . . . . . . . . . . . . . . . . . 60 119 A.18. Change WG 04 to WG 05 . . . . . . . . . . . . . . . . . . 60 120 A.19. Change WG 05 to WG 06 . . . . . . . . . . . . . . . . . . 60 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 123 1. Introduction 125 This document describes an extension mapping for version 1.0 of the 126 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 127 specifies a flexible schema that can be used to implement several 128 common use cases related to the provisioning and management of domain 129 name registrations and applications during the launch of a domain 130 name registry. 132 It is typical for domain registries to operate in special modes 133 during their initial launch to facilitate allocation of domain names, 134 often according to special rules. This document uses the term 135 "launch phase" and the shorter form "launch" to refer to such a 136 period. 138 The EPP domain name mapping [RFC5731] is designed for the steady- 139 state operation of a registry. During a launch period, the model in 140 place may be different from what is defined in the EPP domain name 141 mapping [RFC5731]. For example, registries often accept multiple 142 applications for the same domain name during the "Sunrise" launch 143 phase, referred to as a Launch Application. A Launch Registration 144 refers to a registration made during a launch phase when the server 145 uses a "first-come, first-served" model. Even in a "first-come, 146 first-served" model, additional steps and information might be 147 required, such as trademark information. In addition, the 148 [I-D.ietf-eppext-tmch-smd] defines a registry interface for the 149 Trademark Claims or "claims" launch phase that includes support for 150 presenting a Trademark Claims Notice to the Registrant. This 151 document proposes an extension to the domain name mapping in order to 152 provide a uniform interface for the management of Launch Applications 153 and Launch Registrations in launch phases. 155 1.1. Conventions Used in This Document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 XML is case sensitive. Unless stated otherwise, XML specifications 162 and examples provided in this document MUST be interpreted in the 163 character case presented in order to develop a conforming 164 implementation. 166 In examples, "C:" represents lines sent by a protocol client and "S:" 167 represents lines returned by a protocol server. Indentation and 168 white space in examples are provided only to illustrate element 169 relationships and are not a REQUIRED feature of this protocol. 171 "launch-1.0" is used as an abbreviation for 172 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 173 "launch" is used, but implementations MUST NOT depend on it and 174 instead employ a proper namespace-aware XML parser and serializer to 175 interpret and output the XML documents. 177 "signedMark-1.0" is used as an abbreviation for 178 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 179 [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is used, 180 but implementations MUST NOT depend on it and instead employ a proper 181 namespace-aware XML parser and serializer to interpret and output the 182 XML documents. 184 "mark-1.0" is used as an abbreviation for 185 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 186 [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is used, 187 but implementations MUST NOT depend on it and instead employ a proper 188 namespace-aware XML parser and serializer to interpret and output the 189 XML documents. 191 2. Object Attributes 193 This extension adds additional elements to the EPP domain name 194 mapping [RFC5731]. Only those new elements are described here. 196 2.1. Application Identifier 198 Servers MAY allow multiple applications, referred to as a Launch 199 Application, of the same domain name during its launch phase 200 operations. Upon receiving a valid request to create a Launch 201 Application, the server MUST create an application object 202 corresponding to the request, assign an application identifier for 203 the Launch Application, set the [RFC5731] pendingCreate status, and 204 return the application identifier to the client with the 205 element. In order to facilitate correlation, 206 all subsequent launch operations on the Launch Application MUST be 207 qualified by the previously assigned application identifier using the 208 element. 210 If the command processes a request synchronously 211 without the use of an intermediate Launch Application, then an 212 application identifier MAY not be needed. 214 2.2. Validator Identifier 216 The Validator Identifier is the unique identifier for a Trademark 217 Validator that validates marks and has a repository of validated 218 marks. The OPTIONAL "validatorID" attribute is used to define the 219 Validator Identifier of the Trademark Validator. Registries MAY 220 support more than one Third Party Trademark Validator. The Internet 221 Corporation for Assigned Names and Numbers (ICANN) Trademark 222 Clearinghouse (TMCH) is the default Trademark Validator and is 223 reserved the Validator Identifier of "tmch". If the ICANN TMCH is 224 not used or multiple Trademark Validators are used, the Validator 225 Identifier MUST be defined using the "validatorID" attribute. 227 The Validator Identifier MAY be related to one or more issuer 228 identifiers of the element and the element defined 229 in [I-D.ietf-eppext-tmch-smd]. Both the Validator Identifier and the 230 Issuer Identifier used MUST be unique. The list of validator 231 identifiers and the relationship to issuer identifiers is out of 232 scope for this document. 234 The Validator Identifier MAY define a non-Trademark Validator that 235 supports a form of claims. 237 2.3. Launch Phases 239 The server MAY support multiple launch phases sequentially or 240 simultaneously. The element MUST be included by the 241 client to define the target launch phase of the command. The server 242 SHOULD validate the phase and MAY validate the sub-phase of the 243 element against the active phase and OPTIONAL sub- 244 phase of the server on a create command, and return an EPP error 245 result code of 2306 if there is a mismatch. 247 The following launch phase values are defined: 249 sunrise The phase during which trademark holders can submit 250 registrations or applications with trademark information that can 251 be validated by the server. 252 landrush A post-Sunrise phase when non-trademark holders are allowed 253 to register domain names with steps taken to address a large 254 volume of initial registrations. 255 claims The Trademark Claims phase, as defined in the TMCH Functional 256 Specification [I-D.lozano-tmch-func-spec], in which a Claims 257 Notice must be displayed to a prospective registrant of a domain 258 name that matches trademarks. 259 open A post-launch phase that is also referred to as "steady state". 260 Servers MAY require additional trademark protection during this 261 phase. 262 custom A custom server launch phase that is defined using the "name" 263 attribute. 265 For extensibility, the element includes an OPTIONAL 266 "name" attribute that can define a sub-phase, or the full name of the 267 phase when the element has the "custom" value. For 268 example, the "claims" launch phase could have two sub-phases that 269 include "landrush" and "open". 271 Launch phases MAY overlap to support the "claims" launch phase, 272 defined in the TMCH Functional Specification 273 [I-D.lozano-tmch-func-spec], and to support a traditional "landrush" 274 launch phase. The overlap of the "claims" and "landrush" launch 275 phases SHOULD be handled by setting "claims" as the 276 value and setting "landrush" as the sub-phase with the "name" 277 attribute. For example, the element SHOULD be 278 claims. 280 2.4. Status Values 282 A Launch Application or Launch Registration object MAY have a launch 283 status value. The element is used to convey the 284 launch status pertaining to the object, beyond what is specified in 285 the object mapping. A Launch Application or Launch Registration MUST 286 set the [RFC5731] "pendingCreate" status if a launch status is 287 supported and the launch status is not one of the final statuses, 288 including the "allocated" and "rejected" statuses. 290 The following status values are defined using the required "s" 291 attribute: 293 pendingValidation: The initial state of a newly-created application 294 or registration object. The application or registration requires 295 validation, but the validation process has not yet completed. 296 validated: The application or registration meets relevant registry 297 rules. 298 invalid: The application or registration does not validate according 299 to registry rules. Server policies permitting, it may transition 300 back into "pendingValidation" for revalidation, after 301 modifications are made to ostensibly correct attributes that 302 caused the validation failure. 303 pendingAllocation: The allocation of the application or registration 304 is pending based on the results of some out-of-band process (for 305 example, an auction). 306 allocated: The object corresponding to the application or 307 registration has been provisioned. Is a possible end state of an 308 application or registration object. 309 rejected: The application or registration object was not 310 provisioned. Is a possible end state of an application or 311 registration object. 312 custom: A custom status that is defined using the "name" attribute. 314 Each status value MAY be accompanied by a string of human-readable 315 text that describes the rationale for the status applied to the 316 object. The OPTIONAL "lang" attribute MAY be present to identify the 317 language if the negotiated value is something other than the default 318 value of "en" (English). 320 For extensibility the element includes an OPTIONAL 321 "name" attribute that can define a sub-status or the full name of the 322 status when the status value is "custom". The server SHOULD NOT use 323 the "custom" status value. 325 Status values MAY be skipped. For example, an application or 326 registration MAY immediately start at the "allocated" status or an 327 application or registration MAY skip the "pendingAllocation" status. 328 If the launch phase does not require validation of a request, an 329 application or registration MAY immediately skip to 330 "pendingAllocation". 332 2.4.1. State Transition 334 | request 335 | 336 | +--------------------------+ 337 | | | 338 v v | 339 +-------------------+ | 340 | | | 341 | pendingValidation +--------------+ | 342 | | | | 343 +---------+---------+ | | 344 | | | 345 | | | 346 v v | 347 +-----------+ +---------+ | 348 | | | | | 349 | validated | | invalid +--+ 350 | | | | 351 +-----+-----+ +----+----+ 352 | | 353 | | 354 v | 355 +-------------------+ | 356 | | | 357 | pendingAllocation +-----------+ | 358 | | | | 359 +---------+---------+ | | 360 | | | 361 | | | 362 | | | 363 | | | 364 | | | 365 v v v 366 +---------+ +--------+ 367 / \ / \ 368 | allocated | | rejected | 369 \ / \ / 370 +---------+ +--------+ 372 Figure 1 374 2.5. Poll Messaging 376 A Launch Application MUST and a Launch Registration MAY be handled as 377 a domain name of [RFC5731] in "pendingCreate" status, with the launch 378 status values defined in Section 2.4. As a Launch Application or 379 Launch Registration transitions between the status values defined in 380 Section 2.4, the server SHOULD insert poll messages, per [RFC5730], 381 for the applicable intermediate statuses, including the 382 "pendingValidation", "validated", "pendingAllocation, and "invalid" 383 statuses, using the element with the 384 extension. The element MAY contain 385 non-mandatory information, like contact and name server information. 386 Also, further extensions that would normally be included in the 387 response of a command, per [RFC5731], MAY be included. 388 For the final statuses, including the "allocated" and "rejected" 389 statuses, the server MUST insert a poll message, per 390 [RFC5731], with the extension. 392 The following is an example poll message for a Launch Application 393 that has transitioned to the "pendingAllocation" state. 395 S: 396 S: 397 S: 398 S: 399 S: Command completed successfully; ack to dequeue 400 S: 401 S: 402 S: 2013-04-04T22:01:00.0Z 403 S: Application pendingAllocation. 404 S: 405 S: 406 S: 408 S: domain.example 409 S: ... 410 S: 411 S: 412 S: 413 S: 415 S: sunrise 416 S: abc123 417 S: 418 S: 419 S: 420 S: 421 S: ABC-12345 422 S: 54322-XYZ 423 S: 424 S: 425 S: 426 The following is an example poll message for an 427 "allocated" Launch Application. 429 S: 430 S: 431 S: 432 S: 433 S: Command completed successfully; ack to dequeue 434 S: 435 S: 436 S: 2013-04-04T22:01:00.0Z 437 S: Application successfully allocated. 438 S: 439 S: 440 S: 442 S: domain.example 443 S: 444 S: ABC-12345 445 S: 54321-XYZ 446 S: 447 S: 2013-04-04T22:00:00.0Z 448 S: 449 S: 450 S: 451 S: 453 S: sunrise 454 S: abc123 455 S: 456 S: 457 S: 458 S: 459 S: BCD-23456 460 S: 65432-WXY 461 S: 462 S: 463 S: 464 The following is an example poll message for an 465 "allocated" Launch Registration. 467 S: 468 S: 469 S: 470 S: 471 S: Command completed successfully; ack to dequeue 472 S: 473 S: 474 S: 2013-04-04T22:01:00.0Z 475 S: Registration successfully allocated. 476 S: 477 S: 478 S: 480 S: domain.example 481 S: 482 S: ABC-12345 483 S: 54321-XYZ 484 S: 485 S: 2013-04-04T22:00:00.0Z 486 S: 487 S: 488 S: 489 S: 491 S: sunrise 492 S: 493 S: 494 S: 495 S: 496 S: BCD-23456 497 S: 65432-WXY 498 S: 499 S: 500 S: 502 2.6. Mark Validation Models 504 A server MUST support at least one of the following models for 505 validating trademark information: 507 code Use of a mark code by itself to validate that the mark matches 508 the domain name. This model is supported using the 509 element with just the element. 510 mark The mark information is passed without any other validation 511 element. The server will use some custom form of validation to 512 validate that the mark information is authentic. This model is 513 supported using the element with just the 514 (Section 2.6.2) element. 515 code with mark: A code is used along with the mark information by 516 the server to validate the mark utilizing an external party. The 517 code represents some form of secret that matches the mark 518 information passed. This model is supported using the 519 element that contains both the and 520 the (Section 2.6.2) elements. 521 signed mark: The mark information is digitally signed as described 522 in the Digital Signature (Section 2.6.3) section. The digital 523 signature can be directly validated by the server using the public 524 key of the external party that created the signed mark using its 525 private key. This model is supported using the 526 (Section 2.6.3.1) and (Section 2.6.3.2) 527 elements. 529 More than one , (Section 2.6.3.1), 530 or (Section 2.6.3.2) element MAY be 531 specified. The maximum number of marks per domain name is up to 532 server policy. 534 2.6.1. element 536 The element that is used by the "code", "mark", and 537 "code with mark" validation models, has the following child elements: 539 : OPTIONAL mark code used to validate the 540 (Section 2.6.2) information. The mark code is be a mark-specific 541 secret that the server can verify against a third party. The 542 OPTIONAL "validatorID" attribute is the Validator Identifier 543 (Section 2.2) whose value indicates which Trademark Validator that 544 the code originated from, with no default value. 545 : OPTIONAL mark information with child elements defined 546 in the Mark (Section 2.6.2) section. 548 The following is an example element with both a 549 and (Section 2.6.2) element. 551 552 553 49FD46E6C4B45C55D4AC 554 555 ... 556 557 559 2.6.2. element 561 A element describes an applicant's prior right to a given 562 domain name that is used with the "mark", "mark with code", and the 563 "signed mark" validation models. The element is defined 564 in [I-D.ietf-eppext-tmch-smd]. A new mark format can be supported by 565 creating a new XML schema for the mark that has an element that 566 substitutes for the element from 567 [I-D.ietf-eppext-tmch-smd]. 569 2.6.3. Digital Signature 571 Digital signatures MAY be used by the server to validate either the 572 mark information, when using the "signed mark" validation model with 573 the (Section 2.6.3.1) element or the 574 (Section 2.6.3.2) element. 576 2.6.3.1. element 578 The element contains the digitally signed mark 579 information. The element is defined in 580 [I-D.ietf-eppext-tmch-smd]. A new signed mark format can be 581 supported by creating a new XML schema for the signed mark that has 582 an element that substitutes for the element 583 from [I-D.ietf-eppext-tmch-smd]. 585 2.6.3.2. element 587 The element contains an encoded form of the 588 digitally signed (Section 2.6.3.1) element. The 589 element is defined in 590 [I-D.ietf-eppext-tmch-smd]. A new encoded signed mark format can be 591 supported by creating a new XML schema for the encoded signed mark 592 that has an element that substitutes for the 593 element from [I-D.ietf-eppext-tmch-smd]. 595 3. EPP Command Mapping 597 A detailed description of the EPP syntax and semantics can be found 598 in the EPP core protocol specification [RFC5730]. The command 599 mappings described here are specifically for use in the Launch Phase 600 Extension. 602 This mapping is designed to be flexible, requiring only a minimum set 603 of required elements. 605 While it is meant to serve several use cases, it does not prescribe 606 any interpretation by the client or server. Such processing is 607 typically highly policy-dependent and therefore specific to 608 implementations. 610 Operations on application objects are done via one or more of the 611 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 612 Registries MAY choose to support a subset of the operations. 614 3.1. EPP Command 616 There are three forms of the extension to the EPP command: 617 the Claims Check Form (Section 3.1.1), the Availability Check Form 618 (Section 3.1.2), and the Trademark Check Form (Section 3.1.3). The 619 element "type" attribute defines the form, with the 620 value of "claims" for the Claims Check Form (Section 3.1.1), with the 621 value of "avail" for the Availability Check Form (Section 3.1.2), and 622 with the value of "trademark" for the Trademark Check Form 623 (Section 3.1.3). The default value of the "type" attribute is 624 "claims". The forms supported by the server is determined by server 625 policy. The server MUST return an EPP error result code of 2307 if 626 it receives a check form that is not supported. 628 3.1.1. Claims Check Form 630 The Claims Check Form defines a new command called the Claims Check 631 Command that is used to determine whether or not there are any 632 matching trademarks, in the specified launch phase, for each domain 633 name passed in the command, that requires the use of the "Claims 634 Create Form" on a Domain Create Command. The availability check 635 information defined in the EPP domain name mapping [RFC5731] MUST NOT 636 be returned for the Claims Check Command. This form is the default 637 form and MAY be explicitly identified by setting the 638 "type" attribute to "claims". 640 Instead of returning whether the domain name is available, the Claims 641 Check Command will return whether or not at least one matching 642 trademark exists for the domain name, that requires the use of the 643 "Claims Create Form" on a Domain Create Command. If there is at 644 least one matching trademark that exists for the domain name, a 645 element is returned. The client MAY then use the 646 value of the element to obtain information needed 647 to generate the Trademark Claims Notice from Trademark Validator 648 based on the Validator Identifier (Section 2.2). The unique notice 649 identifier of the Trademark Claims Notice MUST be passed in the 650 element of the extension to the Create Command 651 (Section 3.3). 653 The elements in the EPP command of EPP domain 654 name mapping [RFC5731] define the domain names to check for matching 655 trademarks. The element contains the following child 656 elements: 658 Contains the value of the active launch phase of the 659 server. The server SHOULD validate the value against the active 660 server launch phase. 662 Example Claims Check command using the domain command and the 663 extension with the "type" explicitly set to "claims", 664 to determine if "domain1.example", "domain2.example", and 665 "domain3.example" require claims notices during the "claims" launch 666 phase: 668 C: 669 C: 670 C: 671 C: 672 C: 674 C: domain1.example 675 C: domain2.example 676 C: domain3.example 677 C: 678 C: 679 C: 680 C: 683 C: claims 684 C: 685 C: 686 C: ABC-12345 687 C: 688 C: 690 If the command has been processed successfully, the EPP 691 MUST contain an element that 692 identifies the launch namespace. The element 693 contains the following child elements: 695 The phase that mirrors the element 696 included in the . 697 One or more elements that contain the 698 following child elements: 700 Contains the fully qualified name of the queried 701 domain name. This element MUST contain an "exists" attribute 702 whose value indicates if a matching trademark exists for the 703 domain name that requires the use of the "Claims Create Form" 704 on a Domain Create Command. A value of "1" (or "true") means 705 that a matching trademark does exist and that the "Claims 706 Create Form" is required on a Domain Create Command. A value 707 of "0" (or "false") means that a matching trademark does not 708 exist or that the "Claims Create Form" is NOT required on a 709 Domain Create Command. 710 Zero or more OPTIONAL claim keys that MAY be 711 passed to a third-party trademark validator such as the 712 Trademark Clearinghouse (TMCH) for querying the information 713 needed to generate a Trademark Claims Notice. The 714 is used as the key for the query in place 715 of the domain name to securely query the service without 716 using a well-known value like a domain name. The OPTIONAL 717 "validatorID" attribute is the Validator Identifier 718 (Section 2.2) whose value indicates which Trademark Validator 719 to query for the Claims Notice information, with the default 720 being the ICANN TMCH. The "validatorID" attribute MAY 721 reference a non-trademark claims clearinghouse identifer to 722 support other forms of claims notices. 724 Example Claims Check response when a claims notice is not required 725 for the domain name domain1.example, a claims notice is required for 726 the domain name domain2.example in the "tmch", and a claims notice is 727 required for the domain name domain3.example in the "tmch" and 728 "custom-tmch", for the "claims" launch phase: 730 S: 731 S: 732 S: 733 S: 734 S: Command completed successfully 735 S: 736 S: 737 S: 739 S: claims 740 S: 741 S: domain1.example 742 S: 743 S: 744 S: domain2.example 745 S: 746 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 747 S: 748 S: 749 S: 750 S: domain3.example 751 S: 752 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 753 S: 754 S: 755 S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 756 S: 757 S: 758 S: 759 S: 760 S: 761 S: ABC-12345 762 S: 54321-XYZ 763 S: 764 S: 765 S: 767 3.1.2. Availability Check Form 769 The Availability Check Form defines additional elements to extend the 770 EPP command described in the EPP domain name mapping 771 [RFC5731]. No additional elements are defined for the EPP 772 response. This form MUST be identified by setting the 773 "type" attribute to "avail". 775 The EPP command is used to determine if an object can be 776 provisioned within a repository. Domain names may be made available 777 only in unique launch phases, whilst remaining unavailable for 778 concurrent launch phases. In addition to the elements expressed in 779 the , the command is extended with the 780 element that contains the following child elements: 782 The launch phase to which domain name availability 783 should be determined. 785 Example Availability Check Form command using the domain 786 command and the extension with the "type" set to 787 "avail", to determine the availability of two domain names in the 788 "idn-release" custom launch phase: 790 C: 791 C: 792 C: 793 C: 794 C: 796 C: domain1.example 797 C: domain2.example 798 C: 799 C: 800 C: 801 C: 804 C: custom 805 C: 806 C: 807 C: ABC-12345 808 C: 809 C: 811 The Availability Check Form does not define any extension to the 812 response of an domain command. After processing the command, 813 the server replies with a standard EPP response as defined in the EPP 814 domain name mapping [RFC5731]. 816 3.1.3. Trademark Check Form 818 The Trademark Check Form defines a new command called the Trademark 819 Check Command that is used to determine whether or not there are any 820 matching trademarks for each domain name passed in the command, 821 independent of the active launch phase of the server and whether the 822 "Claims Create Form" is required on a Domain Create Command. The 823 availability check information defined in the EPP domain name mapping 824 [RFC5731] MUST NOT be returned for the Claims Check Command. This 825 form MUST be identified by setting the "type" 826 attribute to "trademark". 828 Instead of returning whether the domain name is available, the 829 Trademark Check Command will return whether or not at least one 830 matching trademark exists for the domain name. If there is at least 831 one matching trademark that exists for the domain name, a 832 element is returned. The client MAY then use the 833 value of the element to obtain Trademark Claims 834 Notice information from Trademark Validator based on the Validator 835 Identifier (Section 2.2). 837 The elements in the EPP command of EPP domain 838 name mapping [RFC5731] define the domain names to check for matching 839 trademarks. The element does not contain any child 840 elements with the "Trademark Check Form": 842 Example Trademark Check command using the domain command and 843 the extension with the "type" set to "trademark", to 844 determine if "domain1.example", "domain2.example", and 845 "domain3.example" have any matching trademarks: 847 C: 848 C: 849 C: 850 C: 851 C: 853 C: domain1.example 854 C: domain2.example 855 C: domain3.example 856 C: 857 C: 858 C: 859 C: 862 C: 863 C: ABC-12345 864 C: 865 C: 867 If the command has been processed successfully, the EPP 868 MUST contain an element that 869 identifies the launch namespace. The element 870 contains the following child elements: 872 One or more elements that contain the 873 following child elements: 875 Contains the fully qualified name of the queried 876 domain name. This element MUST contain an "exists" attribute 877 whose value indicates if a matching trademark exists for the 878 domain name. A value of "1" (or "true") means that a 879 matching trademark does exist. A value of "0" (or "false") 880 means that a matching trademark does not exist. 881 Zero or more OPTIONAL claim keys that MAY be 882 passed to a third-party trademark validator such as the 883 Trademark Clearinghouse (TMCH) for querying the information 884 needed to generate a Trademark Claims Notice. The 885 is used as the key for the query in place 886 of the domain name to securely query the service without 887 using a well-known value like a domain name. The OPTIONAL 888 "validatorID" attribute is the Validator Identifier 889 (Section 2.2) whose value indicates which Trademark Validator 890 to query for the Claims Notice information, with the default 891 being the ICANN TMCH. The "validatorID" attribute MAY 892 reference a non-trademark claims clearinghouse identifer to 893 support other forms of claims notices. 895 Example Trademark Check response when no matching trademarks are 896 found for the domain name domain1.example, matching trademarks are 897 found for the domain name domain2.example in the "tmch", matching 898 trademarks are found for domain name domain3.example in the "tmch" 899 and "custom-tmch", for the "claims" launch phase: 901 S: 902 S: 903 S: 904 S: 905 S: Command completed successfully 906 S: 907 S: 908 S: 910 S: 911 S: domain1.example 912 S: 913 S: 914 S: domain2.example 915 S: 916 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 917 S: 918 S: 919 S: 920 S: domain3.example 921 S: 922 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 923 S: 924 S: 925 S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 926 S: 927 S: 928 S: 929 S: 930 S: 931 S: ABC-12345 932 S: 54321-XYZ 933 S: 934 S: 935 S: 937 3.2. EPP Command 939 This extension defines additional elements to extend the EPP 940 command and response to be used in conjunction with the EPP domain 941 name mapping [RFC5731]. 943 The EPP command is used to retrieve information for a launch 944 phase registration or application. The Application Identifier 945 (Section 2.1) returned in the element of the create 946 response (Section 3.3) is used for retrieving information for a 947 Launch Application. A element is sent along with the 948 regular domain command. The element includes an 949 OPTIONAL "includeMark" boolean attribute, with a default value of 950 "false", to indicate whether or not to include the mark in the 951 response. The element contains the following child 952 elements: 954 The phase during which the application or 955 registration was submitted or is associated with. Server policy 956 defines the phases that are supported. 957 OPTIONAL application identifier of the Launch 958 Application. 960 Example domain command with the extension to 961 retrieve information for the sunrise application for domain.example 962 and application identifier "abc123": 964 C: 965 C: 966 C: 967 C: 968 C: 970 C: domain.example 971 C: 972 C: 973 C: 974 C: 977 C: sunrise 978 C: abc123 979 C: 980 C: 981 C: ABC-12345 982 C: 983 C: 984 Example domain command with the extension to 985 retrieve information for the sunrise registration for domain.example: 987 C: 988 C: 989 C: 990 C: 991 C: 993 C: domain.example 994 C: 995 C: 996 C: 997 C: 999 C: sunrise 1000 C: 1001 C: 1002 C: ABC-12345 1003 C: 1004 C: 1006 If the query was successful, the server replies with a 1007 element along with the regular EPP . The 1008 contains the following child elements: 1010 The phase during which the application was submitted, 1011 or is associated with, that matches the associated command 1012 . 1013 OPTIONAL Application Identifier of the Launch 1014 Application. 1015 OPTIONAL status of the Launch Application using one 1016 of the supported status values (Section 2.4). 1017 Zero or more (Section 2.6.2) elements. 1019 Example domain response using the extension 1020 with the mark information: 1022 S: 1023 S: 1024 S: 1025 S: 1026 S: Command completed successfully 1027 S: 1028 S: 1029 S: 1031 S: domain.example 1032 S: EXAMPLE1-REP 1033 S: 1034 S: jd1234 1035 S: sh8013 1036 S: sh8013 1037 S: ClientX 1038 S: ClientY 1039 S: 2012-04-03T22:00:00.0Z 1040 S: 1041 S: 2fooBAR 1042 S: 1043 S: 1044 S: 1045 S: 1046 S: 1048 S: sunrise 1049 S: abc123 1050 S: 1051 S: 1053 S: ... 1054 S: 1055 S: 1056 S: 1057 S: 1058 S: ABC-12345 1059 S: 54321-XYZ 1060 S: 1061 S: 1062 S: 1064 3.3. EPP Command 1066 There are four forms of the extension to the EPP command 1067 that include the Sunrise Create Form (Section 3.3.1), the Claims 1068 Create Form (Section 3.3.2), the General Create Form (Section 3.3.3), 1069 and the Mixed Create Form (Section 3.3.4). The form is dependent on 1070 the supported launch phases (Section 2.3) as defined below. 1072 sunrise The EPP command with the "sunrise" launch phase is 1073 used to submit a registration with trademark information that can 1074 be verified by the server with the value. The 1075 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 1076 launch phase. 1077 landrush The EPP command with the "landrush" launch phase 1078 MAY use the General Create Form (Section 3.3.3) to explicitly 1079 specify the phase and optionally define the expected type of 1080 object to create. 1081 claims The EPP command with the "claims" launch phase is 1082 used to pass the information associated with the presentation and 1083 acceptance of the Claims Notice. The Claims Create Form 1084 (Section 3.3.2) is used and the General Create Form 1085 (Section 3.3.3) MAY be used for the "claims" launch phase. 1086 open The EPP command with the "open" launch phase is 1087 undefined but the form supported is up to server policy. Use of 1088 the Claims Create Form (Section 3.3.2) MAY be used to pass the 1089 information associated with the presentation and acceptance of the 1090 Claims Notice if required for the domain name. 1091 custom The EPP command with the "custom" launch phase is 1092 undefined but the form supported is up to server policy. 1094 3.3.1. Sunrise Create Form 1096 The Sunrise Create Form of the extension to the EPP domain name 1097 mapping [RFC5731] includes the verifiable trademark information that 1098 the server uses to match against the domain name to authorize the 1099 domain create. A server MUST support one of four models in Claim 1100 Validation Models (Section 2.6) to verify the trademark information 1101 passed by the client. 1103 A element is sent along with the regular 1104 domain command. The element has an OPTIONAL "type" 1105 attribute that defines the expected type of object ("application" or 1106 "registration") to create. The server SHOULD validate the "type" 1107 attribute, when passed, against the type of object that will be 1108 created. The element contains the following child 1109 elements: 1111 The identifier for the launch phase. 1113 or or 1115 Zero or more elements. The 1116 child elements are defined in the 1117 element (Section 2.6.1) section. 1118 Zero or more elements. The 1119 child elements are defined in the 1120 element (Section 2.6.3.1) section. 1121 Zero or more 1122 elements. The child elements are 1123 defined in the element 1124 (Section 2.6.3.2) section. 1126 The following is an example domain command using the 1127 extension, following the "code" validation model, 1128 with multiple sunrise codes: 1130 C: 1131 C: 1132 C: 1133 C: 1134 C: 1136 C: domain.example 1137 C: jd1234 1138 C: sh8013 1139 C: sh8013 1140 C: 1141 C: 2fooBAR 1142 C: 1143 C: 1144 C: 1145 C: 1146 C: 1148 C: sunrise 1149 C: 1150 C: 1151 C: 49FD46E6C4B45C55D4AC 1152 C: 1153 C: 1154 C: 49FD46E6C4B45C55D4AD 1155 C: 1156 C: 1157 C: 1158 C: 49FD46E6C4B45C55D4AE 1159 C: 1160 C: 1161 C: 1162 C: ABC-12345 1163 C: 1164 C: 1165 The following is an example domain command using the 1166 extension, following the "mark" validation model, 1167 with the mark information: 1169 C: 1170 C: 1171 C: 1172 C: 1173 C: 1175 C: domainone.example 1176 C: jd1234 1177 C: sh8013 1178 C: sh8013 1179 C: 1180 C: 2fooBAR 1181 C: 1182 C: 1183 C: 1184 C: 1185 C: 1187 C: sunrise 1188 C: 1189 C: 1191 C: ... 1192 C: 1193 C: 1194 C: 1195 C: 1196 C: ABC-12345 1197 C: 1198 C: 1199 The following is an example domain command using the 1200 extension, following the "code with mark" validation 1201 model, with a code and mark information: 1203 C: 1204 C: 1205 C: 1206 C: 1207 C: 1209 C: domain.example 1210 C: jd1234 1211 C: sh8013 1212 C: sh8013 1213 C: 1214 C: 2fooBAR 1215 C: 1216 C: 1217 C: 1218 C: 1219 C: 1221 C: sunrise 1222 C: 1223 C: 1224 C: 49FD46E6C4B45C55D4AC 1225 C: 1227 C: ... 1228 C: 1229 C: 1230 C: 1231 C: 1232 C: ABC-12345 1233 C: 1234 C: 1235 The following is an example domain command using the 1236 extension, following the "signed mark" validation 1237 model, with the signed mark information for a sunrise application: 1239 C: 1240 C: 1241 C: 1242 C: 1243 C: 1245 C: domainone.example 1246 C: jd1234 1247 C: sh8013 1248 C: sh8013 1249 C: 1250 C: 2fooBAR 1251 C: 1252 C: 1253 C: 1254 C: 1255 C: 1258 C: sunrise 1259 C: 1261 C: ... 1262 C: 1263 C: 1264 C: 1265 C: ABC-12345 1266 C: 1267 C: 1268 The following is an example domain command using the 1269 extension, following the "signed mark" validation 1270 model, with the base64 encoded signed mark information: 1272 C: 1273 C: 1274 C: 1275 C: 1276 C: 1278 C: domainone.example 1279 C: jd1234 1280 C: sh8013 1281 C: sh8013 1282 C: 1283 C: 2fooBAR 1284 C: 1285 C: 1286 C: 1287 C: 1288 C: 1290 C: sunrise 1291 C: 1293 C: ... 1294 C: 1295 C: 1296 C: 1297 C: ABC-12345 1298 C: 1299 C: 1301 3.3.2. Claims Create Form 1303 The Claims Create Form of the extension to the EPP domain name 1304 mapping [RFC5731] includes the information related to the 1305 registrant's acceptance of the Claims Notice. 1307 A element is sent along with the regular 1308 domain command. The element has an OPTIONAL "type" 1309 attribute that defines the expected type of object ("application" or 1310 "registration") to create. The server SHOULD validate the "type" 1311 attribute, when passed, against the type of object that will be 1312 created. The element contains the following child 1313 elements: 1315 Contains the value of the active launch phase of the 1316 server. The server SHOULD validate the value against the active 1317 server launch phase. 1318 One or more elements that contain 1319 the following child elements: 1321 Unique notice identifier for the Claims 1322 Notice. The element has an OPTIONAL 1323 "validatorID" attribute is the Validator Identifier 1324 (Section 2.2) whose value indicates which Trademark Validator 1325 is the source of the claims notice, with the default being 1326 the ICANN TMCH. 1327 Expiry of the claims notice. 1328 Contains the date and time that the claims 1329 notice was accepted. 1331 The following is an example domain command using the 1332 extension with the information for 1333 the "tmch" and the "custom-tmch" validators, for the "claims" launch 1334 phase: 1336 C: 1337 C: 1338 C: 1339 C: 1340 C: 1342 C: domain.example 1343 C: jd1234 1344 C: sh8013 1345 C: sh8013 1346 C: 1347 C: 2fooBAR 1348 C: 1349 C: 1350 C: 1351 C: 1352 C: 1354 C: claims 1355 C: 1356 C: 1357 C: 370d0b7c9223372036854775807 1358 C: 2014-06-19T10:00:00.0Z 1359 C: 1360 C: 2014-06-19T09:00:00.0Z 1361 C: 1362 C: 1363 C: 1364 C: 1365 C: 470d0b7c9223654313275808 1366 C: 2014-06-19T10:00:00.0Z 1367 C: 1368 C: 2014-06-19T09:00:30.0Z 1369 C: 1370 C: 1371 C: 1372 C: 1373 C: ABC-12345 1374 C: 1375 C: 1377 3.3.3. General Create Form 1379 The General Create Form of the extension to the EPP domain name 1380 mapping [RFC5731] includes the launch phase and optionally the object 1381 type to create. The OPTIONAL "type" attribute defines the expected 1382 type of object ("application" or "registration") to create. The 1383 server SHOULD validate the "type" attribute, when passed, against the 1384 type of object that will be created. 1386 A element is sent along with the regular 1387 domain command. The element contains the following 1388 child elements: 1390 Contains the value of the active launch phase of the 1391 server. The server SHOULD validate the value against the active 1392 server launch phase. 1394 The following is an example domain command using the 1395 extension for a "landrush" launch phase application: 1397 C: 1398 C: 1399 C: 1400 C: 1401 C: 1403 C: domain.example 1404 C: jd1234 1405 C: sh8013 1406 C: sh8013 1407 C: 1408 C: 2fooBAR 1409 C: 1410 C: 1411 C: 1412 C: 1413 C: 1416 C: landrush 1417 C: 1418 C: 1419 C: ABC-12345 1420 C: 1421 C: 1423 3.3.4. Mixed Create Form 1425 The Mixed Create Form supports a mix of the create forms, where for 1426 example the Sunrise Create Form (Section 3.3.1) and the Claims Create 1427 Form (Section 3.3.2) MAY be supported in a single command by 1428 including both the verified trademark information and the information 1429 related to the registrant's acceptance of the Claims Notice. The 1430 server MAY support the Mixed Create Form. The "custom" launch phase 1431 SHOULD be used when using the Mixed Create Form. 1433 The following is an example domain command using the 1434 extension, with using a mix of the Sunrise Create 1435 Form (Section 3.3.1) and the Claims Create Form (Section 3.3.2) by 1436 including both a mark and a notice: 1438 C: 1439 C: 1440 C: 1441 C: 1442 C: 1444 C: domainone.example 1445 C: jd1234 1446 C: sh8013 1447 C: sh8013 1448 C: 1449 C: 2fooBAR 1450 C: 1451 C: 1452 C: 1453 C: 1454 C: 1457 C: custom 1458 C: 1459 C: 1461 C: ... 1462 C: 1463 C: 1464 C: 1465 C: 1466 C: 49FD46E6C4B45C55D4AC 1467 C: 1468 C: 2012-06-19T10:00:10.0Z 1469 C: 1470 C: 2012-06-19T09:01:30.0Z 1471 C: 1472 C: 1473 C: 1474 C: 1475 C: ABC-12345 1476 C: 1477 C: 1479 3.3.5. Create Response 1481 If the create was successful, the server MAY reply with the 1482 element along with the regular EPP to 1483 indicate the server generated Application Identifier (Section 2.1), 1484 when multiple applications of a given domain name are supported; 1485 otherwise no extension is included with the regular EPP . 1486 The element contains the following child elements: 1488 The phase of the application that mirrors the 1489 element included in the . 1490 The application identifier of the 1491 application. 1493 An example response when multiple overlapping applications are 1494 supported by the server: 1496 S: 1497 S: 1498 S: 1499 S: 1500 S: Command completed successfully; action pending 1501 S: 1502 S: 1503 S: 1505 S: domain.example 1506 S: 2010-08-10T15:38:26.623854Z 1507 S: 1508 S: 1509 S: 1510 S: 1512 S: sunrise 1513 S: 2393-9323-E08C-03B1 1514 S: 1515 S: 1516 S: 1517 S: 1518 S: ABC-12345 1519 S: 54321-XYZ 1520 S: 1521 S: 1522 S: 1524 3.4. EPP Command 1526 This extension defines additional elements to extend the EPP 1527 command to be used in conjunction with the domain name mapping. 1529 A client MUST NOT pass the extension on an EPP command to a 1530 server that does not support launch applications. A server that does 1531 not support launch applications during its launch phase MUST return 1532 an EPP error result code of 2102 when receiving an EPP 1533 command with the extension. 1535 Registry policies permitting, clients may update an application 1536 object by submitting an EPP command along with a 1537 element to indicate the application object to be 1538 updated. The element contains the following child 1539 elements: 1541 The phase during which the application was submitted 1542 or is associated with. 1543 The application identifier for which the 1544 client wishes to update. 1546 The following is an example domain command with the 1547 extension to add and remove a name server of a 1548 sunrise application with the application identifier "abc123": 1550 C: 1551 C: 1552 C: 1553 C: 1554 C: 1556 C: domain.example 1557 C: 1558 C: 1559 C: ns2.domain.example 1560 C: 1561 C: 1562 C: 1563 C: 1564 C: ns1.domain.example 1565 C: 1566 C: 1567 C: 1568 C: 1569 C: 1570 C: 1572 C: sunrise 1573 C: abc123 1574 C: 1575 C: 1576 C: ABC-12345 1577 C: 1578 C: 1580 This extension does not define any extension to the response of an 1581 domain command. After processing the command, the server 1582 replies with a standard EPP response as defined in the EPP domain 1583 name mapping [RFC5731]. 1585 3.5. EPP Command 1587 This extension defines additional elements to extend the EPP 1588 command to be used in conjunction with the domain name mapping. 1590 A client MUST NOT pass the extension on an EPP command to a 1591 server that does not support launch applications. A server that does 1592 not support launch applications during its launch phase MUST return 1593 an EPP error result code of 2102 when receiving an EPP 1594 command with the extension. 1596 Registry policies permitting, clients MAY withdraw an application by 1597 submitting an EPP command along with a 1598 element to indicate the application object to be deleted. The 1599 element contains the following child elements: 1601 The phase during which the application was submitted 1602 or is associated with. 1603 The application identifier for which the 1604 client wishes to delete. 1606 The following is an example domain command with the 1607 extension: 1609 C: 1610 C: 1611 C: 1612 C: 1613 C: 1615 C: domain.example 1616 C: 1617 C: 1618 C: 1619 C: 1621 C: sunrise 1622 C: abc123 1623 C: 1624 C: 1625 C: ABC-12345 1626 C: 1627 C: 1629 This extension does not define any extension to the response of a 1630 domain command. After processing the command, the server 1631 replies with a standard EPP response as defined in the EPP domain 1632 name mapping [RFC5731]. 1634 3.6. EPP Command 1636 This extension does not define any extension to the EPP 1637 command or response described in the EPP domain name mapping 1638 [RFC5731]. 1640 3.7. EPP Command 1642 This extension does not define any extension to the EPP 1643 command or response described in the EPP domain name mapping 1644 [RFC5731]. 1646 4. Formal Syntax 1648 One schema is presented here that is the EPP Launch Phase Mapping 1649 schema. 1651 The formal syntax presented here is a complete schema representation 1652 of the object mapping suitable for automated validation of EPP XML 1653 instances. The BEGIN and END tags are not part of the schema; they 1654 are used to note the beginning and ending of the schema for URI 1655 registration purposes. 1657 4.1. Launch Schema 1659 Copyright (c) 2012 IETF Trust and the persons identified as authors 1660 of the code. All rights reserved. 1662 Redistribution and use in source and binary forms, with or without 1663 modification, are permitted provided that the following conditions 1664 are met: 1666 o Redistributions of source code must retain the above copyright 1667 notice, this list of conditions and the following disclaimer. 1668 o Redistributions in binary form must reproduce the above copyright 1669 notice, this list of conditions and the following disclaimer in 1670 the documentation and/or other materials provided with the 1671 distribution. 1672 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1673 names of specific contributors, may be used to endorse or promote 1674 products derived from this software without specific prior written 1675 permission. 1677 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1678 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1679 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1680 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1681 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1682 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1683 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1684 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1685 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1686 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1687 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1689 BEGIN 1690 1691 1700 1703 1704 1705 1707 1708 1709 Extensible Provisioning Protocol v1.0 1710 domain name extension schema 1711 for the launch phase processing. 1712 1713 1715 1718 1719 1720 1721 1722 1724 1727 1728 1729 1731 1733 1734 1736 1739 1740 1741 1743 1749 1750 1751 1752 1753 1754 1755 1757 1760 1761 1762 1763 1764 1765 1766 1767 1768 1770 1773 1774 1775 1776 1777 1779 1780 1781 1782 1785 1786 1787 1789 1792 1793 1794 1795 1796 1798 1799 1800 1801 1803 1804 1805 1807 1810 1811 1812 1813 1814 1816 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1831 1834 1835 1836 1837 1839 1841 1842 1843 1844 1846 1850 1851 1852 1854 1856 1857 1859 1862 1863 1864 1865 1866 1868 1870 1872 1873 1876 1877 1878 1880 1883 1884 1885 1886 1887 1888 1890 1893 1894 1895 1896 1897 1898 1899 1901 1904 1905 1906 1908 1909 1911 1913 1917 1918 1919 1920 1921 1922 1923 1924 1927 1928 1929 1930 1933 1934 1936 1938 1941 1942 1943 1945 1948 1949 1950 1952 1954 1955 1957 1958 1959 1960 1962 1963 1965 1966 1967 1968 1970 1971 1973 1975 1976 1977 1978 1980 1981 1982 1984 1987 1988 1989 1990 1993 1995 1997 1998 2000 2001 END 2003 5. IANA Considerations 2005 5.1. XML Namespace 2007 This document uses URNs to describe XML namespaces and XML schemas 2008 conforming to a registry mechanism described in [RFC3688]. 2010 Registration request for the launch namespace: 2012 URI: urn:ietf:params:xml:ns:launch-1.0 2013 Registrant Contact: See the "Author's Address" section of this 2014 document. 2015 XML: None. Namespace URIs do not represent an XML specification. 2017 Registration request for the launch XML schema: 2019 URI: urn:ietf:params:xml:schema:launch-1.0 2020 Registrant Contact: See the "Author's Address" section of this 2021 document. 2022 XML: See the "Formal Syntax" section of this document. 2024 5.2. EPP Extension Registry 2026 The EPP extension described in this document should be registered by 2027 the IANA in the EPP Extension Registry described in [RFC7451]. The 2028 details of the registration are as follows: 2030 Name of Extension: "Launch Phase Mapping for the Extensible 2031 Provisioning Protocol (EPP)" 2033 Document status: Standards Track 2035 Reference: (insert reference to RFC version of this document) 2037 Registrant Name and Email Address: IESG, 2039 TLDs: Any 2041 IPR Disclosure: None 2043 Status: Active 2045 Notes: None 2047 6. Implementation Status 2049 Note to RFC Editor: Please remove this section and the reference to 2050 RFC 6982 [RFC6982] before publication. 2052 This section records the status of known implementations of the 2053 protocol defined by this specification at the time of posting of this 2054 Internet-Draft, and is based on a proposal described in RFC 6982 2055 [RFC6982]. The description of implementations in this section is 2056 intended to assist the IETF in its decision processes in progressing 2057 drafts to RFCs. Please note that the listing of any individual 2058 implementation here does not imply endorsement by the IETF. 2059 Furthermore, no effort has been spent to verify the information 2060 presented here that was supplied by IETF contributors. This is not 2061 intended as, and must not be construed to be, a catalog of available 2062 implementations or their features. Readers are advised to note that 2063 other implementations may exist. 2065 According to RFC 6982 [RFC6982], "this will allow reviewers and 2066 working groups to assign due consideration to documents that have the 2067 benefit of running code, which may serve as evidence of valuable 2068 experimentation and feedback that have made the implemented protocols 2069 more mature. It is up to the individual working groups to use this 2070 information as they see fit". 2072 6.1. Verisign EPP SDK 2074 Organization: Verisign Inc. 2076 Name: Verisign EPP SDK 2078 Description: The Verisign EPP SDK includes both a full client 2079 implementation and a full server stub implementation of draft-ietf- 2080 eppext-launchphase. 2082 Level of maturity: Production 2084 Coverage: All aspects of the protocol are implemented. 2086 Licensing: GNU Lesser General Public License 2088 Contact: jgould@verisign.com 2090 URL: http://www.verisigninc.com/en_US/channel-resources/domain- 2091 registry-products/epp-sdks 2093 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 2095 Organization: Verisign Inc. 2097 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 2098 System (SRS) 2100 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 2101 Registry System (SRS) implements the server-side of draft-ietf- 2102 eppext-launchphase for a variety of Top Level Domains (TLD's). 2104 Level of maturity: Production 2106 Coverage: The "signed mark" Mark Validation Model, the Claims Check 2107 Form for the EPP Command, the Sunrise and Claims Forms for 2108 the EPP Command of Launch Registrations and Launch 2109 Applications. For Launch Applications the Poll Messaging, the EPP 2110 Command, the EPP Command, and the EPP 2111 Command is covered. 2113 Licensing: Proprietary 2115 Contact: jgould@verisign.com 2117 6.3. Verisign .COM / .NET SRS 2119 Organization: Verisign Inc. 2121 Name: Verisign .COM / .NET Shared Registry System (SRS) 2123 Description: The Verisign Shared Registry System (SRS) for .COM, .NET 2124 and other IDN TLD's implements the server-side of draft-ietf-eppext- 2125 launchphase. 2127 Level of maturity: Operational Test Environment (OTE) 2129 Coverage: The "signed mark" Mark Validation Model, the Claims Check 2130 Form for the EPP Command, the Sunrise and Claims Forms for 2131 the EPP Command of Launch Registrations. 2133 Licensing: Proprietary 2135 Contact: jgould@verisign.com 2137 6.4. REngin v3.7 2139 Organization: Domain Name Services (Pty) Ltd 2141 Name: REngin v3.7 2143 Description: Server side implementation only 2145 Level of maturity: Production 2147 Coverage: All features from version 12 have been implemented 2149 Licensing: Proprietary Licensing with Maintenance Contracts 2151 Contact: info@dnservices.co.za 2153 URL: https://www.registry.net.za and soon http://dnservices.co.za 2155 6.5. RegistryEngine EPP Service 2157 Organization: CentralNic 2159 Name: RegistryEngine EPP Service 2161 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 2162 SLDs 2163 Level of maturity: Deployed in CentralNic's production environment as 2164 well as two other gTLD registry systems, and two ccTLD registry 2165 systems. 2167 Coverage: Majority of elements including TMCH sunrise, landrush and 2168 TM claims as well as sunrise applications validated using codes. 2170 Licensing: Proprietary In-House software 2172 Contact: epp@centralnic.com 2174 URL: https://www.centralnic.com 2176 6.6. Neustar EPP SDK 2178 Organization: Neustar 2180 Name: Neustar EPP SDK 2182 Description: The Neustar EPP SDK includes client implementation of 2183 draft-ietf-eppext-launchphase in both Java and C++. 2185 Level of maturity: Production 2187 Coverage: All aspects of the protocol are implemented. 2189 Licensing: GNU Lesser General Public License 2191 Contact: trung.tran@neustar.biz 2193 6.7. gTLD Shared Registry System 2195 Organization: Stichting Internet Domeinnaamregistratie Nederland 2196 (SIDN) 2198 Name: gTLD Shared Registry System 2200 Description: The gTLD SRS implements the server side of the draft- 2201 ietf-eppext-launchphase. 2203 Level of maturity: (soon) Production 2205 Coverage: The following parts of the draft are supported: 2207 Signed mark validation model using Digital Signature 2208 (Section 2.6.3) 2209 Claims Check Form (Section 3.1.1) 2210 Sunrise Create Form (Section 3.3.1) 2211 Claims Create Form (Section 3.3.2) 2213 The parts of the document not described here are not implemented. 2215 Licensing: Proprietary 2217 Contact: rik.ribbers@sidn.nl 2219 7. Security Considerations 2221 The mapping extensions described in this document do not provide any 2222 security services beyond those described by EPP [RFC5730], the EPP 2223 domain name mapping [RFC5731], and protocol layers used by EPP. The 2224 security considerations described in these other specifications apply 2225 to this specification as well. 2227 Updates to, and deletion of an application object must be restricted 2228 to clients authorized to perform the said operation on the object. 2230 As information contained within an application, or even the mere fact 2231 that an application exists may be confidential. Any attempt to 2232 operate on an application object by an unauthorized client MUST be 2233 rejected with an EPP 2201 (authorization error) return code. Server 2234 policy may allow operation with filtered output by clients 2235 other than the sponsoring client, in which case the 2236 and response SHOULD be filtered to include only 2237 fields that are publicly accessible. 2239 8. Acknowledgements 2241 The authors wish to acknowledge the efforts of the leading 2242 participants of the Community TMCH Model that led to many of the 2243 changes to this document, which include Chris Wright, Jeff Neuman, 2244 Jeff Eckhaus, and Will Shorter. 2246 Special suggestions that have been incorporated into this document 2247 were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Michael 2248 Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus 2249 Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell, 2250 Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung 2251 Tran, Ulrich Wisser and Sharon Wodjenski. 2253 9. Normative References 2255 [I-D.ietf-eppext-tmch-smd] 2256 Lozano, G., "Mark and Signed Mark Objects Mapping", draft- 2257 ietf-eppext-tmch-smd-02 (work in progress), July 2015. 2259 [I-D.lozano-tmch-func-spec] 2260 Lozano, G., "TMCH functional specifications", draft- 2261 lozano-tmch-func-spec-10 (work in progress), July 2015. 2263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2264 Requirement Levels", BCP 14, RFC 2119, 2265 DOI 10.17487/RFC2119, March 1997, 2266 . 2268 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2269 DOI 10.17487/RFC3688, January 2004, 2270 . 2272 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2273 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 2274 . 2276 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2277 Domain Name Mapping", STD 69, RFC 5731, 2278 DOI 10.17487/RFC5731, August 2009, 2279 . 2281 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2282 Code: The Implementation Status Section", RFC 6982, 2283 DOI 10.17487/RFC6982, July 2013, 2284 . 2286 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 2287 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 2288 February 2015, . 2290 Appendix A. Change History 2292 A.1. Change from 00 to 01 2294 1. Changed to use camel case for the XML elements. 2295 2. Replaced "cancelled" status to "rejected" status. 2296 3. Added the child elements of the element. 2297 4. Removed the XML schema and replaced with "[TBD]". 2299 A.2. Change from 01 to 02 2301 1. Added support for both the ICANN and ARI/Neustar TMCH models. 2302 2. Changed the namespace URI and prefix to use "launch" instead of 2303 "launchphase". 2304 3. Added definition of multiple claim validation models. 2305 4. Added the and 2306 elements. 2308 5. Added support for Claims Info Command 2310 A.3. Change from 02 to 03 2312 1. Removed XSI namespace per Keith Gaughan's suggestion on the 2313 provreg list. 2314 2. Added extensibility to the launch:status element and added the 2315 pendingAuction status per Trung Tran's feedback on the provreg 2316 list. 2317 3. Added support for the Claims Check Command, updated the location 2318 and contents of the signedNotice, and replaced most references of 2319 Claim to Mark based on the work being done on the ARI/Neustar 2320 launch model. 2322 A.4. Change from 03 to 04 2324 1. Removed references to the ICANN model. 2325 2. Removed support for the Claims Info Command. 2326 3. Removed use of the signedClaim. 2327 4. Revised the method for referring to the signedClaim from the XML 2328 Signature using the IDREF URI. 2329 5. Split the launch-1.0.xsd into three XML schemas including launch- 2330 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 2331 6. Split the "claims" launch phase to the "claims1" and "claims2" 2332 launch phases. 2333 7. Added support for the encodedSignedMark with base64 encoded 2334 signedMark. 2335 8. Changed the elements in the createNoticeType to include the 2336 noticeID, timestamp, and the source elements. 2337 9. Added the class and effectiveDate elements to mark. 2339 A.5. Change from 04 to 05 2341 1. Removed reference to in the example. 2342 2. Incorporated feedback from Bernhard Reutner-Fischer on the 2343 provreg mail list. 2344 3. Added missing launch XML prefix to applicationIDType reference in 2345 the idContainerType of the Launch Schema. 2346 4. Added missing description of the element in the 2347 element. 2348 5. Updated note on replication of the EPP contact mapping elements 2349 in the Mark Contact section. 2351 A.6. Change from 05 to 06 2353 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 2354 replaced with reference to draft-lozano-smd, that contains the 2355 definition for the mark, signed marked, and encoded signed mark. 2357 2. Split the into and 2358 based on feedback from Trung Tran. 2359 3. Added the "includeMark" optional attribute to the 2360 element to enable the client to request whether or not to include 2361 the mark in the info response. 2362 4. Fixed state diagram to remove redundant transition from "invalid" 2363 to "rejected"; thanks Klaus Malorny. 2365 A.7. Change from 06 to 07 2367 1. Proof-read grammar and spelling. 2368 2. Changed "pendingAuction" status to "pendingAllocation", changed 2369 "pending" to "pendingValidation" status, per proposal from Trung 2370 Tran and seconded by Rubens Kuhl. 2371 3. Added text related to the use of RFC 5731 pendingCreate to the 2372 Application Identifier section. 2373 4. Added the Poll Messaging section to define the use of poll 2374 messaging for intermediate state transitions and pending action 2375 poll messaging for final state transitions. 2377 A.8. Change from 07 to 08 2379 1. Added support for use of the launch statuses and poll messaging 2380 for Launch Registrations based on feedback from Sharon Wodjenski 2381 and Trung Tran. 2382 2. Incorporated changes based on updates or clarifications in draft- 2383 lozano-tmch-func-spec-01, which include: 2385 1. Removed the unused element. 2386 2. Removed the element. 2387 3. Added the element based on the required 2388 element. 2390 A.9. Change from 08 to 09 2392 1. Made element optional in to allow 2393 passing just the in per request 2394 from Ben Levac. 2395 2. Added optional "type" attribute in to enable the 2396 client to explicitly define the desired type of object 2397 (application or registration) to create to all forms of the 2398 create extension. 2399 3. Added text that the server SHOULD validate the 2400 element in the Launch Phases section. 2401 4. Add the "General Create Form" to the create command extension to 2402 support the request from Ben Levac. 2403 5. Updated the text for the Poll Messaging section based on feedback 2404 from Klaus Malorny. 2406 6. Replaced the "claims1" and "claims2" phases with the "claims" 2407 phase based on discussion on the provreg list. 2408 7. Added support for a mixed create model (Sunrise Create Model and 2409 Claims Create Model), where a trademark (encoded signed mark, 2410 etc.) and notice can be passed, based on a request from James 2411 Mitchell. 2412 8. Added text for the handling of the overlapping "claims" and 2413 "landrush" launch phases. 2414 9. Added support for two check forms (claims check form and 2415 availability check form) based on a request from James Mitchell. 2416 The availability check form was based on the text in draft-rbp- 2417 application-epp-mapping. 2419 A.10. Change from 09 to 10 2421 1. Changed noticeIDType from base64Binary to token to be compatible 2422 with draft-lozano-tmch-func-spec-05. 2423 2. Changed codeType from base64Binary to token to be more generic. 2424 3. Updated based on feedback from Alexander Mayrhofer, which 2425 include: 2427 1. Changed "extension to the domain name extension" to 2428 "extension to the domain name mapping". 2429 2. Changed use of 2004 return code to 2306 return code when 2430 phase passed mismatches active phase and sub-phase. 2431 3. Changed description of "allocated" and "rejected" statuses. 2432 4. Moved sentence on a synchronous command 2433 without the use of an intermediate application, then an 2434 Application Identifier MAY not be needed to the Application 2435 Identifier section. 2436 5. Restructured the Mark Validation Models section to include 2437 the " element" sub-section, the 2438 " element" sub-section, and the Digital Signature 2439 sub-section. 2440 6. Changed "Registries may" to "Registries MAY". 2441 7. Changed "extensed" to "extended" in "Availability Check 2442 Form" section. 2443 8. Broke the mix of create forms in the "EPP Command" 2444 section to a fourth "Mixed Create Form" with its own sub- 2445 section. 2446 9. Removed "displayed or" from "displayed or accepted" in the 2447 description. 2448 10. Replaced "given domain name is supported" with "given domain 2449 name are supported" in the "Create Response" section. 2450 11. Changed the reference of 2303 (object does not exist) in the 2451 "Security Considerations" section to 2201 (authorization 2452 error). 2454 12. Added arrow from "invalid" status to "pendingValidation" 2455 status and "pendingAllocation" status to "rejected" status 2456 in the State Transition Diagram. 2457 4. Added the "C:" and "S:" example prefixes and related text in the 2458 "Conventions Used in This Document" section. 2460 A.11. Change from 10 to 11 2462 1. Moved the claims check response element under 2463 the element instead of the element based on 2464 the request from Francisco Obispo. 2466 A.12. Change from 11 to 12 2468 1. Added support for multiple validator identifiers for claims 2469 notices and marks based on a request and text provided by Mike 2470 O'Connell. 2471 2. Removed domain:exDate element from example in section 3.3.5 based 2472 on a request from Seth Goldman on the provreg list. 2473 3. Added clarifying text for clients not passing the launch 2474 extension on update and delete commands to servers that do not 2475 support launch applications based on a request from Sharon 2476 Wodjenski on the provreg list. 2478 A.13. Change from 12 to WG 00 2480 1. Changed to eppext working group draft by changing draft-tan-epp- 2481 launchphase to draft-ietf-eppext-launchphase and by changing 2482 references of draft-lozano-tmch-smd to draft-ietf-eppext-tmch- 2483 smd. 2485 A.14. Change WG 00 to WG 01 2487 1. Removed text associated with support for the combining of status 2488 values based on feedback from Patrick Mevzek on the provreg 2489 mailing list, discussion on the eppext mailing list, and 2490 discussion at the eppext IETF meeting on March 6, 2014. 2492 A.15. Change WG 01 to WG 02 2494 1. Changed the element to be zero or more elements 2495 and the element to be one or more elements in the 2496 Claims Create Form. These changes were needed to be able to 2497 support more than one concurrent claims services. 2499 A.16. Change WG 02 to WG 03 2501 1. Added the "Implementation Status" section based on an action item 2502 from the eppext IETF-91 meeting. 2503 2. Moved Section 7 "IANA Considerations" and Section 9 "Security 2504 Considerations" before Section 5 "Acknowledgements". Moved 2505 "Change Log" Section to end. 2506 3. Updated the text for the Claims Check Form and the Claims Create 2507 Form to support checking for the need of the claims notice and 2508 passing the claims notice outside of the "claims" phase. 2509 4. Added the new Trademark Check Form to support determining whether 2510 or not a trademark exists that matches the domain name 2511 independent of whether a claims notice is required on create. 2512 This was based on a request from Trung Tran and a discussion on 2513 the eppext mailing list. 2515 A.17. Change WG 03 to WG 04 2517 1. Amended XML Namespace section of IANA Considerations, added EPP 2518 Extension Registry section. 2520 A.18. Change WG 04 to WG 05 2522 1. Added a missing comma to the descripton of the 2523 element, based on feedback from Keith Gaughan on the eppext 2524 mailing list. 2525 2. Added the SIDN implementation status information. 2526 3. Fixed a few indentation issues in the samples. 2528 A.19. Change WG 05 to WG 06 2530 1. Removed duplicate "TMCH Functional Specification" URIs based on 2531 feedback from Scott Hollenbeck on the eppext mailing list. 2532 2. Changed references of example?.tld to domain?.example to be 2533 consistent with RFC 6761 based on feedback from Scott Hollenbeck 2534 on the eppext mailing list. 2535 3. A template was added to section 5 to register the XML schema in 2536 addition to the namespace based on feedback from Scott Hollenbeck 2537 on the eppext mailing list. 2539 Authors' Addresses 2540 James Gould 2541 VeriSign, Inc. 2542 12061 Bluemont Way 2543 Reston, VA 20190 2544 US 2546 Email: jgould@verisign.com 2547 URI: http://www.verisigninc.com 2549 Wil Tan 2550 Cloud Registry 2551 Suite 32 Seabridge House 2552 377 Kent St 2553 Sydney, NSW 2000 2554 AU 2556 Phone: +61 414 710899 2557 Email: wil@cloudregistry.net 2558 URI: http://www.cloudregistry.net 2560 Gavin Brown 2561 CentralNic Ltd 2562 35-39 Mooregate 2563 London, England EC2R 6AR 2564 GB 2566 Phone: +44 20 33 88 0600 2567 Email: gavin.brown@centralnic.com 2568 URI: https://www.centralnic.com