idnits 2.17.1 draft-ietf-eppext-launchphase-07.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 (November 2, 2015) is 3097 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 (-01) exists of draft-ietf-eppext-tmch-func-spec-00 == Outdated reference: A later version (-06) exists of draft-ietf-eppext-tmch-smd-03 ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 3 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: May 5, 2016 Cloud Registry 6 G. Brown 7 CentralNic Ltd 8 November 2, 2015 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-ietf-eppext-launchphase-07 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 May 5, 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 . . . . . . . . . . . . . . . . . . 57 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 A.20. Change WG 06 to WG 07 . . . . . . . . . . . . . . . . . . 60 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 124 1. Introduction 126 This document describes an extension mapping for version 1.0 of the 127 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 128 specifies a flexible schema that can be used to implement several 129 common use cases related to the provisioning and management of domain 130 name registrations and applications during the launch of a domain 131 name registry. 133 It is typical for domain registries to operate in special modes 134 during their initial launch to facilitate allocation of domain names, 135 often according to special rules. This document uses the term 136 "launch phase" and the shorter form "launch" to refer to such a 137 period. 139 The EPP domain name mapping [RFC5731] is designed for the steady- 140 state operation of a registry. During a launch period, the model in 141 place may be different from what is defined in the EPP domain name 142 mapping [RFC5731]. For example, registries often accept multiple 143 applications for the same domain name during the "Sunrise" launch 144 phase, referred to as a Launch Application. A Launch Registration 145 refers to a registration made during a launch phase when the server 146 uses a "first-come, first-served" model. Even in a "first-come, 147 first-served" model, additional steps and information might be 148 required, such as trademark information. In addition, the 149 [I-D.ietf-eppext-tmch-smd] defines a registry interface for the 150 Trademark Claims or "claims" launch phase that includes support for 151 presenting a Trademark Claims Notice to the Registrant. This 152 document proposes an extension to the domain name mapping in order to 153 provide a uniform interface for the management of Launch Applications 154 and Launch Registrations in launch phases. 156 1.1. Conventions Used in This Document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 XML is case sensitive. Unless stated otherwise, XML specifications 163 and examples provided in this document MUST be interpreted in the 164 character case presented in order to develop a conforming 165 implementation. 167 In examples, "C:" represents lines sent by a protocol client and "S:" 168 represents lines returned by a protocol server. Indentation and 169 white space in examples are provided only to illustrate element 170 relationships and are not a REQUIRED feature of this protocol. 172 "launch-1.0" is used as an abbreviation for 173 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 174 "launch" is used, but implementations MUST NOT depend on it and 175 instead employ a proper namespace-aware XML parser and serializer to 176 interpret and output the XML documents. 178 "signedMark-1.0" is used as an abbreviation for 179 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 180 [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is used, 181 but implementations MUST NOT depend on it and instead employ a proper 182 namespace-aware XML parser and serializer to interpret and output the 183 XML documents. 185 "mark-1.0" is used as an abbreviation for 186 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 187 [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is used, 188 but implementations MUST NOT depend on it and instead employ a proper 189 namespace-aware XML parser and serializer to interpret and output the 190 XML documents. 192 2. Object Attributes 194 This extension adds additional elements to the EPP domain name 195 mapping [RFC5731]. Only those new elements are described here. 197 2.1. Application Identifier 199 Servers MAY allow multiple applications, referred to as a Launch 200 Application, of the same domain name during its launch phase 201 operations. Upon receiving a valid request to create a Launch 202 Application, the server MUST create an application object 203 corresponding to the request, assign an application identifier for 204 the Launch Application, set the [RFC5731] pendingCreate status, and 205 return the application identifier to the client with the 206 element. In order to facilitate correlation, 207 all subsequent launch operations on the Launch Application MUST be 208 qualified by the previously assigned application identifier using the 209 element. 211 If the command processes a request synchronously 212 without the use of an intermediate Launch Application, then an 213 application identifier MAY not be needed. 215 2.2. Validator Identifier 217 The Validator Identifier is the unique identifier for a Trademark 218 Validator that validates marks and has a repository of validated 219 marks. The OPTIONAL "validatorID" attribute is used to define the 220 Validator Identifier of the Trademark Validator. Registries MAY 221 support more than one Third Party Trademark Validator. The Internet 222 Corporation for Assigned Names and Numbers (ICANN) Trademark 223 Clearinghouse (TMCH) is the default Trademark Validator and is 224 reserved the Validator Identifier of "tmch". If the ICANN TMCH is 225 not used or multiple Trademark Validators are used, the Validator 226 Identifier MUST be defined using the "validatorID" attribute. 228 The Validator Identifier MAY be related to one or more issuer 229 identifiers of the element and the element defined 230 in [I-D.ietf-eppext-tmch-smd]. Both the Validator Identifier and the 231 Issuer Identifier used MUST be unique. The list of validator 232 identifiers and the relationship to issuer identifiers is out of 233 scope for this document. 235 The Validator Identifier MAY define a non-Trademark Validator that 236 supports a form of claims. 238 2.3. Launch Phases 240 The server MAY support multiple launch phases sequentially or 241 simultaneously. The element MUST be included by the 242 client to define the target launch phase of the command. The server 243 SHOULD validate the phase and MAY validate the sub-phase of the 244 element against the active phase and OPTIONAL sub- 245 phase of the server on a create command, and return an EPP error 246 result code of 2306 if there is a mismatch. 248 The following launch phase values are defined: 250 sunrise The phase during which trademark holders can submit 251 registrations or applications with trademark information that can 252 be validated by the server. 253 landrush A post-Sunrise phase when non-trademark holders are allowed 254 to register domain names with steps taken to address a large 255 volume of initial registrations. 256 claims The Trademark Claims phase, as defined in the TMCH Functional 257 Specification [I-D.ietf-eppext-tmch-func-spec], in which a Claims 258 Notice must be displayed to a prospective registrant of a domain 259 name that matches trademarks. 260 open A post-launch phase that is also referred to as "steady state". 261 Servers MAY require additional trademark protection during this 262 phase. 263 custom A custom server launch phase that is defined using the "name" 264 attribute. 266 For extensibility, the element includes an OPTIONAL 267 "name" attribute that can define a sub-phase, or the full name of the 268 phase when the element has the "custom" value. For 269 example, the "claims" launch phase could have two sub-phases that 270 include "landrush" and "open". 272 Launch phases MAY overlap to support the "claims" launch phase, 273 defined in the TMCH Functional Specification 274 [I-D.ietf-eppext-tmch-func-spec], and to support a traditional 275 "landrush" launch phase. The overlap of the "claims" and "landrush" 276 launch phases SHOULD be handled by setting "claims" as the 277 value and setting "landrush" as the sub-phase with the 278 "name" attribute. For example, the element SHOULD be 279 claims. 281 2.4. Status Values 283 A Launch Application or Launch Registration object MAY have a launch 284 status value. The element is used to convey the 285 launch status pertaining to the object, beyond what is specified in 286 the object mapping. A Launch Application or Launch Registration MUST 287 set the [RFC5731] "pendingCreate" status if a launch status is 288 supported and the launch status is not one of the final statuses, 289 including the "allocated" and "rejected" statuses. 291 The following status values are defined using the required "s" 292 attribute: 294 pendingValidation: The initial state of a newly-created application 295 or registration object. The application or registration requires 296 validation, but the validation process has not yet completed. 297 validated: The application or registration meets relevant registry 298 rules. 299 invalid: The application or registration does not validate according 300 to registry rules. Server policies permitting, it may transition 301 back into "pendingValidation" for revalidation, after 302 modifications are made to ostensibly correct attributes that 303 caused the validation failure. 304 pendingAllocation: The allocation of the application or registration 305 is pending based on the results of some out-of-band process (for 306 example, an auction). 307 allocated: The object corresponding to the application or 308 registration has been provisioned. Is a possible end state of an 309 application or registration object. 310 rejected: The application or registration object was not 311 provisioned. Is a possible end state of an application or 312 registration object. 313 custom: A custom status that is defined using the "name" attribute. 315 Each status value MAY be accompanied by a string of human-readable 316 text that describes the rationale for the status applied to the 317 object. The OPTIONAL "lang" attribute MAY be present to identify the 318 language if the negotiated value is something other than the default 319 value of "en" (English). 321 For extensibility the element includes an OPTIONAL 322 "name" attribute that can define a sub-status or the full name of the 323 status when the status value is "custom". The server SHOULD NOT use 324 the "custom" status value. 326 Status values MAY be skipped. For example, an application or 327 registration MAY immediately start at the "allocated" status or an 328 application or registration MAY skip the "pendingAllocation" status. 329 If the launch phase does not require validation of a request, an 330 application or registration MAY immediately skip to 331 "pendingAllocation". 333 2.4.1. State Transition 335 | request 336 | 337 | +--------------------------+ 338 | | | 339 v v | 340 +-------------------+ | 341 | | | 342 | pendingValidation +--------------+ | 343 | | | | 344 +---------+---------+ | | 345 | | | 346 | | | 347 v v | 348 +-----------+ +---------+ | 349 | | | | | 350 | validated | | invalid +--+ 351 | | | | 352 +-----+-----+ +----+----+ 353 | | 354 | | 355 v | 356 +-------------------+ | 357 | | | 358 | pendingAllocation +-----------+ | 359 | | | | 360 +---------+---------+ | | 361 | | | 362 | | | 363 | | | 364 | | | 365 | | | 366 v v v 367 +---------+ +--------+ 368 / \ / \ 369 | allocated | | rejected | 370 \ / \ / 371 +---------+ +--------+ 373 Figure 1 375 2.5. Poll Messaging 377 A Launch Application MUST and a Launch Registration MAY be handled as 378 a domain name of [RFC5731] in "pendingCreate" status, with the launch 379 status values defined in Section 2.4. As a Launch Application or 380 Launch Registration transitions between the status values defined in 381 Section 2.4, the server SHOULD insert poll messages, per [RFC5730], 382 for the applicable intermediate statuses, including the 383 "pendingValidation", "validated", "pendingAllocation, and "invalid" 384 statuses, using the element with the 385 extension. The element MAY contain 386 non-mandatory information, like contact and name server information. 387 Also, further extensions that would normally be included in the 388 response of a command, per [RFC5731], MAY be included. 389 For the final statuses, including the "allocated" and "rejected" 390 statuses, the server MUST insert a poll message, per 391 [RFC5731], with the extension. 393 The following is an example poll message for a Launch Application 394 that has transitioned to the "pendingAllocation" state. 396 S: 397 S: 398 S: 399 S: 400 S: Command completed successfully; ack to dequeue 401 S: 402 S: 403 S: 2013-04-04T22:01:00.0Z 404 S: Application pendingAllocation. 405 S: 406 S: 407 S: 409 S: domain.example 410 S: ... 411 S: 412 S: 413 S: 414 S: 416 S: sunrise 417 S: abc123 418 S: 419 S: 420 S: 421 S: 422 S: ABC-12345 423 S: 54322-XYZ 424 S: 425 S: 426 S: 427 The following is an example poll message for an 428 "allocated" Launch Application. 430 S: 431 S: 432 S: 433 S: 434 S: Command completed successfully; ack to dequeue 435 S: 436 S: 437 S: 2013-04-04T22:01:00.0Z 438 S: Application successfully allocated. 439 S: 440 S: 441 S: 443 S: domain.example 444 S: 445 S: ABC-12345 446 S: 54321-XYZ 447 S: 448 S: 2013-04-04T22:00:00.0Z 449 S: 450 S: 451 S: 452 S: 454 S: sunrise 455 S: abc123 456 S: 457 S: 458 S: 459 S: 460 S: BCD-23456 461 S: 65432-WXY 462 S: 463 S: 464 S: 465 The following is an example poll message for an 466 "allocated" Launch Registration. 468 S: 469 S: 470 S: 471 S: 472 S: Command completed successfully; ack to dequeue 473 S: 474 S: 475 S: 2013-04-04T22:01:00.0Z 476 S: Registration successfully allocated. 477 S: 478 S: 479 S: 481 S: domain.example 482 S: 483 S: ABC-12345 484 S: 54321-XYZ 485 S: 486 S: 2013-04-04T22:00:00.0Z 487 S: 488 S: 489 S: 490 S: 492 S: sunrise 493 S: 494 S: 495 S: 496 S: 497 S: BCD-23456 498 S: 65432-WXY 499 S: 500 S: 501 S: 503 2.6. Mark Validation Models 505 A server MUST support at least one of the following models for 506 validating trademark information: 508 code Use of a mark code by itself to validate that the mark matches 509 the domain name. This model is supported using the 510 element with just the element. 511 mark The mark information is passed without any other validation 512 element. The server will use some custom form of validation to 513 validate that the mark information is authentic. This model is 514 supported using the element with just the 515 (Section 2.6.2) element. 516 code with mark: A code is used along with the mark information by 517 the server to validate the mark utilizing an external party. The 518 code represents some form of secret that matches the mark 519 information passed. This model is supported using the 520 element that contains both the and 521 the (Section 2.6.2) elements. 522 signed mark: The mark information is digitally signed as described 523 in the Digital Signature (Section 2.6.3) section. The digital 524 signature can be directly validated by the server using the public 525 key of the external party that created the signed mark using its 526 private key. This model is supported using the 527 (Section 2.6.3.1) and (Section 2.6.3.2) 528 elements. 530 More than one , (Section 2.6.3.1), 531 or (Section 2.6.3.2) element MAY be 532 specified. The maximum number of marks per domain name is up to 533 server policy. 535 2.6.1. element 537 The element that is used by the "code", "mark", and 538 "code with mark" validation models, has the following child elements: 540 : OPTIONAL mark code used to validate the 541 (Section 2.6.2) information. The mark code is be a mark-specific 542 secret that the server can verify against a third party. The 543 OPTIONAL "validatorID" attribute is the Validator Identifier 544 (Section 2.2) whose value indicates which Trademark Validator that 545 the code originated from, with no default value. 546 : OPTIONAL mark information with child elements defined 547 in the Mark (Section 2.6.2) section. 549 The following is an example element with both a 550 and (Section 2.6.2) element. 552 553 554 49FD46E6C4B45C55D4AC 555 556 ... 557 558 560 2.6.2. element 562 A element describes an applicant's prior right to a given 563 domain name that is used with the "mark", "mark with code", and the 564 "signed mark" validation models. The element is defined 565 in [I-D.ietf-eppext-tmch-smd]. A new mark format can be supported by 566 creating a new XML schema for the mark that has an element that 567 substitutes for the element from 568 [I-D.ietf-eppext-tmch-smd]. 570 2.6.3. Digital Signature 572 Digital signatures MAY be used by the server to validate either the 573 mark information, when using the "signed mark" validation model with 574 the (Section 2.6.3.1) element or the 575 (Section 2.6.3.2) element. 577 2.6.3.1. element 579 The element contains the digitally signed mark 580 information. The element is defined in 581 [I-D.ietf-eppext-tmch-smd]. A new signed mark format can be 582 supported by creating a new XML schema for the signed mark that has 583 an element that substitutes for the element 584 from [I-D.ietf-eppext-tmch-smd]. 586 2.6.3.2. element 588 The element contains an encoded form of the 589 digitally signed (Section 2.6.3.1) element. The 590 element is defined in 591 [I-D.ietf-eppext-tmch-smd]. A new encoded signed mark format can be 592 supported by creating a new XML schema for the encoded signed mark 593 that has an element that substitutes for the 594 element from [I-D.ietf-eppext-tmch-smd]. 596 3. EPP Command Mapping 598 A detailed description of the EPP syntax and semantics can be found 599 in the EPP core protocol specification [RFC5730]. The command 600 mappings described here are specifically for use in the Launch Phase 601 Extension. 603 This mapping is designed to be flexible, requiring only a minimum set 604 of required elements. 606 While it is meant to serve several use cases, it does not prescribe 607 any interpretation by the client or server. Such processing is 608 typically highly policy-dependent and therefore specific to 609 implementations. 611 Operations on application objects are done via one or more of the 612 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 613 Registries MAY choose to support a subset of the operations. 615 3.1. EPP Command 617 There are three forms of the extension to the EPP command: 618 the Claims Check Form (Section 3.1.1), the Availability Check Form 619 (Section 3.1.2), and the Trademark Check Form (Section 3.1.3). The 620 element "type" attribute defines the form, with the 621 value of "claims" for the Claims Check Form (Section 3.1.1), with the 622 value of "avail" for the Availability Check Form (Section 3.1.2), and 623 with the value of "trademark" for the Trademark Check Form 624 (Section 3.1.3). The default value of the "type" attribute is 625 "claims". The forms supported by the server is determined by server 626 policy. The server MUST return an EPP error result code of 2307 if 627 it receives a check form that is not supported. 629 3.1.1. Claims Check Form 631 The Claims Check Form defines a new command called the Claims Check 632 Command that is used to determine whether or not there are any 633 matching trademarks, in the specified launch phase, for each domain 634 name passed in the command, that requires the use of the "Claims 635 Create Form" on a Domain Create Command. The availability check 636 information defined in the EPP domain name mapping [RFC5731] MUST NOT 637 be returned for the Claims Check Command. This form is the default 638 form and MAY be explicitly identified by setting the 639 "type" attribute to "claims". 641 Instead of returning whether the domain name is available, the Claims 642 Check Command will return whether or not at least one matching 643 trademark exists for the domain name, that requires the use of the 644 "Claims Create Form" on a Domain Create Command. If there is at 645 least one matching trademark that exists for the domain name, a 646 element is returned. The client MAY then use the 647 value of the element to obtain information needed 648 to generate the Trademark Claims Notice from Trademark Validator 649 based on the Validator Identifier (Section 2.2). The unique notice 650 identifier of the Trademark Claims Notice MUST be passed in the 651 element of the extension to the Create Command 652 (Section 3.3). 654 The elements in the EPP command of EPP domain 655 name mapping [RFC5731] define the domain names to check for matching 656 trademarks. The element contains the following child 657 elements: 659 Contains the value of the active launch phase of the 660 server. The server SHOULD validate the value against the active 661 server launch phase. 663 Example Claims Check command using the domain command and the 664 extension with the "type" explicitly set to "claims", 665 to determine if "domain1.example", "domain2.example", and 666 "domain3.example" require claims notices during the "claims" launch 667 phase: 669 C: 670 C: 671 C: 672 C: 673 C: 675 C: domain1.example 676 C: domain2.example 677 C: domain3.example 678 C: 679 C: 680 C: 681 C: 684 C: claims 685 C: 686 C: 687 C: ABC-12345 688 C: 689 C: 691 If the command has been processed successfully, the EPP 692 MUST contain an element that 693 identifies the launch namespace. The element 694 contains the following child elements: 696 The phase that mirrors the element 697 included in the . 698 One or more elements that contain the 699 following child elements: 701 Contains the fully qualified name of the queried 702 domain name. This element MUST contain an "exists" attribute 703 whose value indicates if a matching trademark exists for the 704 domain name that requires the use of the "Claims Create Form" 705 on a Domain Create Command. A value of "1" (or "true") means 706 that a matching trademark does exist and that the "Claims 707 Create Form" is required on a Domain Create Command. A value 708 of "0" (or "false") means that a matching trademark does not 709 exist or that the "Claims Create Form" is NOT required on a 710 Domain Create Command. 711 Zero or more OPTIONAL claim keys that MAY be 712 passed to a third-party trademark validator such as the 713 Trademark Clearinghouse (TMCH) for querying the information 714 needed to generate a Trademark Claims Notice. The 715 is used as the key for the query in place 716 of the domain name to securely query the service without 717 using a well-known value like a domain name. The OPTIONAL 718 "validatorID" attribute is the Validator Identifier 719 (Section 2.2) whose value indicates which Trademark Validator 720 to query for the Claims Notice information, with the default 721 being the ICANN TMCH. The "validatorID" attribute MAY 722 reference a non-trademark claims clearinghouse identifer to 723 support other forms of claims notices. 725 Example Claims Check response when a claims notice is not required 726 for the domain name domain1.example, a claims notice is required for 727 the domain name domain2.example in the "tmch", and a claims notice is 728 required for the domain name domain3.example in the "tmch" and 729 "custom-tmch", for the "claims" launch phase: 731 S: 732 S: 733 S: 734 S: 735 S: Command completed successfully 736 S: 737 S: 738 S: 740 S: claims 741 S: 742 S: domain1.example 743 S: 744 S: 745 S: domain2.example 746 S: 747 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 748 S: 749 S: 750 S: 751 S: domain3.example 752 S: 753 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 754 S: 755 S: 756 S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 757 S: 758 S: 759 S: 760 S: 761 S: 762 S: ABC-12345 763 S: 54321-XYZ 764 S: 765 S: 766 S: 768 3.1.2. Availability Check Form 770 The Availability Check Form defines additional elements to extend the 771 EPP command described in the EPP domain name mapping 772 [RFC5731]. No additional elements are defined for the EPP 773 response. This form MUST be identified by setting the 774 "type" attribute to "avail". 776 The EPP command is used to determine if an object can be 777 provisioned within a repository. Domain names may be made available 778 only in unique launch phases, whilst remaining unavailable for 779 concurrent launch phases. In addition to the elements expressed in 780 the , the command is extended with the 781 element that contains the following child elements: 783 The launch phase to which domain name availability 784 should be determined. 786 Example Availability Check Form command using the domain 787 command and the extension with the "type" set to 788 "avail", to determine the availability of two domain names in the 789 "idn-release" custom launch phase: 791 C: 792 C: 793 C: 794 C: 795 C: 797 C: domain1.example 798 C: domain2.example 799 C: 800 C: 801 C: 802 C: 805 C: custom 806 C: 807 C: 808 C: ABC-12345 809 C: 810 C: 812 The Availability Check Form does not define any extension to the 813 response of an domain command. After processing the command, 814 the server replies with a standard EPP response as defined in the EPP 815 domain name mapping [RFC5731]. 817 3.1.3. Trademark Check Form 819 The Trademark Check Form defines a new command called the Trademark 820 Check Command that is used to determine whether or not there are any 821 matching trademarks for each domain name passed in the command, 822 independent of the active launch phase of the server and whether the 823 "Claims Create Form" is required on a Domain Create Command. The 824 availability check information defined in the EPP domain name mapping 825 [RFC5731] MUST NOT be returned for the Claims Check Command. This 826 form MUST be identified by setting the "type" 827 attribute to "trademark". 829 Instead of returning whether the domain name is available, the 830 Trademark Check Command will return whether or not at least one 831 matching trademark exists for the domain name. If there is at least 832 one matching trademark that exists for the domain name, a 833 element is returned. The client MAY then use the 834 value of the element to obtain Trademark Claims 835 Notice information from Trademark Validator based on the Validator 836 Identifier (Section 2.2). 838 The elements in the EPP command of EPP domain 839 name mapping [RFC5731] define the domain names to check for matching 840 trademarks. The element does not contain any child 841 elements with the "Trademark Check Form": 843 Example Trademark Check command using the domain command and 844 the extension with the "type" set to "trademark", to 845 determine if "domain1.example", "domain2.example", and 846 "domain3.example" have any matching trademarks: 848 C: 849 C: 850 C: 851 C: 852 C: 854 C: domain1.example 855 C: domain2.example 856 C: domain3.example 857 C: 858 C: 859 C: 860 C: 863 C: 864 C: ABC-12345 865 C: 866 C: 868 If the command has been processed successfully, the EPP 869 MUST contain an element that 870 identifies the launch namespace. The element 871 contains the following child elements: 873 One or more elements that contain the 874 following child elements: 876 Contains the fully qualified name of the queried 877 domain name. This element MUST contain an "exists" attribute 878 whose value indicates if a matching trademark exists for the 879 domain name. A value of "1" (or "true") means that a 880 matching trademark does exist. A value of "0" (or "false") 881 means that a matching trademark does not exist. 882 Zero or more OPTIONAL claim keys that MAY be 883 passed to a third-party trademark validator such as the 884 Trademark Clearinghouse (TMCH) for querying the information 885 needed to generate a Trademark Claims Notice. The 886 is used as the key for the query in place 887 of the domain name to securely query the service without 888 using a well-known value like a domain name. The OPTIONAL 889 "validatorID" attribute is the Validator Identifier 890 (Section 2.2) whose value indicates which Trademark Validator 891 to query for the Claims Notice information, with the default 892 being the ICANN TMCH. The "validatorID" attribute MAY 893 reference a non-trademark claims clearinghouse identifer to 894 support other forms of claims notices. 896 Example Trademark Check response when no matching trademarks are 897 found for the domain name domain1.example, matching trademarks are 898 found for the domain name domain2.example in the "tmch", matching 899 trademarks are found for domain name domain3.example in the "tmch" 900 and "custom-tmch", for the "claims" launch phase: 902 S: 903 S: 904 S: 905 S: 906 S: Command completed successfully 907 S: 908 S: 909 S: 911 S: 912 S: domain1.example 913 S: 914 S: 915 S: domain2.example 916 S: 917 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 918 S: 919 S: 920 S: 921 S: domain3.example 922 S: 923 S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 924 S: 925 S: 926 S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 927 S: 928 S: 929 S: 930 S: 931 S: 932 S: ABC-12345 933 S: 54321-XYZ 934 S: 935 S: 936 S: 938 3.2. EPP Command 940 This extension defines additional elements to extend the EPP 941 command and response to be used in conjunction with the EPP domain 942 name mapping [RFC5731]. 944 The EPP command is used to retrieve information for a launch 945 phase registration or application. The Application Identifier 946 (Section 2.1) returned in the element of the create 947 response (Section 3.3) is used for retrieving information for a 948 Launch Application. A element is sent along with the 949 regular domain command. The element includes an 950 OPTIONAL "includeMark" boolean attribute, with a default value of 951 "false", to indicate whether or not to include the mark in the 952 response. The element contains the following child 953 elements: 955 The phase during which the application or 956 registration was submitted or is associated with. Server policy 957 defines the phases that are supported. 958 OPTIONAL application identifier of the Launch 959 Application. 961 Example domain command with the extension to 962 retrieve information for the sunrise application for domain.example 963 and application identifier "abc123": 965 C: 966 C: 967 C: 968 C: 969 C: 971 C: domain.example 972 C: 973 C: 974 C: 975 C: 978 C: sunrise 979 C: abc123 980 C: 981 C: 982 C: ABC-12345 983 C: 984 C: 985 Example domain command with the extension to 986 retrieve information for the sunrise registration for domain.example: 988 C: 989 C: 990 C: 991 C: 992 C: 994 C: domain.example 995 C: 996 C: 997 C: 998 C: 1000 C: sunrise 1001 C: 1002 C: 1003 C: ABC-12345 1004 C: 1005 C: 1007 If the query was successful, the server replies with a 1008 element along with the regular EPP . The 1009 contains the following child elements: 1011 The phase during which the application was submitted, 1012 or is associated with, that matches the associated command 1013 . 1014 OPTIONAL Application Identifier of the Launch 1015 Application. 1016 OPTIONAL status of the Launch Application using one 1017 of the supported status values (Section 2.4). 1018 Zero or more (Section 2.6.2) elements. 1020 Example domain response using the extension 1021 with the mark information: 1023 S: 1024 S: 1025 S: 1026 S: 1027 S: Command completed successfully 1028 S: 1029 S: 1030 S: 1032 S: domain.example 1033 S: EXAMPLE1-REP 1034 S: 1035 S: jd1234 1036 S: sh8013 1037 S: sh8013 1038 S: ClientX 1039 S: ClientY 1040 S: 2012-04-03T22:00:00.0Z 1041 S: 1042 S: 2fooBAR 1043 S: 1044 S: 1045 S: 1046 S: 1047 S: 1049 S: sunrise 1050 S: abc123 1051 S: 1052 S: 1054 S: ... 1055 S: 1056 S: 1057 S: 1058 S: 1059 S: ABC-12345 1060 S: 54321-XYZ 1061 S: 1062 S: 1063 S: 1065 3.3. EPP Command 1067 There are four forms of the extension to the EPP command 1068 that include the Sunrise Create Form (Section 3.3.1), the Claims 1069 Create Form (Section 3.3.2), the General Create Form (Section 3.3.3), 1070 and the Mixed Create Form (Section 3.3.4). The form is dependent on 1071 the supported launch phases (Section 2.3) as defined below. 1073 sunrise The EPP command with the "sunrise" launch phase is 1074 used to submit a registration with trademark information that can 1075 be verified by the server with the value. The 1076 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 1077 launch phase. 1078 landrush The EPP command with the "landrush" launch phase 1079 MAY use the General Create Form (Section 3.3.3) to explicitly 1080 specify the phase and optionally define the expected type of 1081 object to create. 1082 claims The EPP command with the "claims" launch phase is 1083 used to pass the information associated with the presentation and 1084 acceptance of the Claims Notice. The Claims Create Form 1085 (Section 3.3.2) is used and the General Create Form 1086 (Section 3.3.3) MAY be used for the "claims" launch phase. 1087 open The EPP command with the "open" launch phase is 1088 undefined but the form supported is up to server policy. Use of 1089 the Claims Create Form (Section 3.3.2) MAY be used to pass the 1090 information associated with the presentation and acceptance of the 1091 Claims Notice if required for the domain name. 1092 custom The EPP command with the "custom" launch phase is 1093 undefined but the form supported is up to server policy. 1095 3.3.1. Sunrise Create Form 1097 The Sunrise Create Form of the extension to the EPP domain name 1098 mapping [RFC5731] includes the verifiable trademark information that 1099 the server uses to match against the domain name to authorize the 1100 domain create. A server MUST support one of four models in Claim 1101 Validation Models (Section 2.6) to verify the trademark information 1102 passed by the client. 1104 A element is sent along with the regular 1105 domain command. The element has an OPTIONAL "type" 1106 attribute that defines the expected type of object ("application" or 1107 "registration") to create. The server SHOULD validate the "type" 1108 attribute, when passed, against the type of object that will be 1109 created. The element contains the following child 1110 elements: 1112 The identifier for the launch phase. 1114 or or 1116 Zero or more elements. The 1117 child elements are defined in the 1118 element (Section 2.6.1) section. 1119 Zero or more elements. The 1120 child elements are defined in the 1121 element (Section 2.6.3.1) section. 1122 Zero or more 1123 elements. The child elements are 1124 defined in the element 1125 (Section 2.6.3.2) section. 1127 The following is an example domain command using the 1128 extension, following the "code" validation model, 1129 with multiple sunrise codes: 1131 C: 1132 C: 1133 C: 1134 C: 1135 C: 1137 C: domain.example 1138 C: jd1234 1139 C: sh8013 1140 C: sh8013 1141 C: 1142 C: 2fooBAR 1143 C: 1144 C: 1145 C: 1146 C: 1147 C: 1149 C: sunrise 1150 C: 1151 C: 1152 C: 49FD46E6C4B45C55D4AC 1153 C: 1154 C: 1155 C: 49FD46E6C4B45C55D4AD 1156 C: 1157 C: 1158 C: 1159 C: 49FD46E6C4B45C55D4AE 1160 C: 1161 C: 1162 C: 1163 C: ABC-12345 1164 C: 1165 C: 1166 The following is an example domain command using the 1167 extension, following the "mark" validation model, 1168 with the mark information: 1170 C: 1171 C: 1172 C: 1173 C: 1174 C: 1176 C: domainone.example 1177 C: jd1234 1178 C: sh8013 1179 C: sh8013 1180 C: 1181 C: 2fooBAR 1182 C: 1183 C: 1184 C: 1185 C: 1186 C: 1188 C: sunrise 1189 C: 1190 C: 1192 C: ... 1193 C: 1194 C: 1195 C: 1196 C: 1197 C: ABC-12345 1198 C: 1199 C: 1200 The following is an example domain command using the 1201 extension, following the "code with mark" validation 1202 model, with a code and mark information: 1204 C: 1205 C: 1206 C: 1207 C: 1208 C: 1210 C: domain.example 1211 C: jd1234 1212 C: sh8013 1213 C: sh8013 1214 C: 1215 C: 2fooBAR 1216 C: 1217 C: 1218 C: 1219 C: 1220 C: 1222 C: sunrise 1223 C: 1224 C: 1225 C: 49FD46E6C4B45C55D4AC 1226 C: 1228 C: ... 1229 C: 1230 C: 1231 C: 1232 C: 1233 C: ABC-12345 1234 C: 1235 C: 1236 The following is an example domain command using the 1237 extension, following the "signed mark" validation 1238 model, with the signed mark information for a sunrise application: 1240 C: 1241 C: 1242 C: 1243 C: 1244 C: 1246 C: domainone.example 1247 C: jd1234 1248 C: sh8013 1249 C: sh8013 1250 C: 1251 C: 2fooBAR 1252 C: 1253 C: 1254 C: 1255 C: 1256 C: 1259 C: sunrise 1260 C: 1262 C: ... 1263 C: 1264 C: 1265 C: 1266 C: ABC-12345 1267 C: 1268 C: 1269 The following is an example domain command using the 1270 extension, following the "signed mark" validation 1271 model, with the base64 encoded signed mark information: 1273 C: 1274 C: 1275 C: 1276 C: 1277 C: 1279 C: domainone.example 1280 C: jd1234 1281 C: sh8013 1282 C: sh8013 1283 C: 1284 C: 2fooBAR 1285 C: 1286 C: 1287 C: 1288 C: 1289 C: 1291 C: sunrise 1292 C: 1294 C: ... 1295 C: 1296 C: 1297 C: 1298 C: ABC-12345 1299 C: 1300 C: 1302 3.3.2. Claims Create Form 1304 The Claims Create Form of the extension to the EPP domain name 1305 mapping [RFC5731] includes the information related to the 1306 registrant's acceptance of the Claims Notice. 1308 A element is sent along with the regular 1309 domain command. The element has an OPTIONAL "type" 1310 attribute that defines the expected type of object ("application" or 1311 "registration") to create. The server SHOULD validate the "type" 1312 attribute, when passed, against the type of object that will be 1313 created. The element contains the following child 1314 elements: 1316 Contains the value of the active launch phase of the 1317 server. The server SHOULD validate the value against the active 1318 server launch phase. 1319 One or more elements that contain 1320 the following child elements: 1322 Unique notice identifier for the Claims 1323 Notice. The element has an OPTIONAL 1324 "validatorID" attribute is the Validator Identifier 1325 (Section 2.2) whose value indicates which Trademark Validator 1326 is the source of the claims notice, with the default being 1327 the ICANN TMCH. 1328 Expiry of the claims notice. 1329 Contains the date and time that the claims 1330 notice was accepted. 1332 The following is an example domain command using the 1333 extension with the information for 1334 the "tmch" and the "custom-tmch" validators, for the "claims" launch 1335 phase: 1337 C: 1338 C: 1339 C: 1340 C: 1341 C: 1343 C: domain.example 1344 C: jd1234 1345 C: sh8013 1346 C: sh8013 1347 C: 1348 C: 2fooBAR 1349 C: 1350 C: 1351 C: 1352 C: 1353 C: 1355 C: claims 1356 C: 1357 C: 1358 C: 370d0b7c9223372036854775807 1359 C: 2014-06-19T10:00:00.0Z 1360 C: 1361 C: 2014-06-19T09:00:00.0Z 1362 C: 1363 C: 1364 C: 1365 C: 1366 C: 470d0b7c9223654313275808 1367 C: 2014-06-19T10:00:00.0Z 1368 C: 1369 C: 2014-06-19T09:00:30.0Z 1370 C: 1371 C: 1372 C: 1373 C: 1374 C: ABC-12345 1375 C: 1376 C: 1378 3.3.3. General Create Form 1380 The General Create Form of the extension to the EPP domain name 1381 mapping [RFC5731] includes the launch phase and optionally the object 1382 type to create. The OPTIONAL "type" attribute defines the expected 1383 type of object ("application" or "registration") to create. The 1384 server SHOULD validate the "type" attribute, when passed, against the 1385 type of object that will be created. 1387 A element is sent along with the regular 1388 domain command. The element contains the following 1389 child elements: 1391 Contains the value of the active launch phase of the 1392 server. The server SHOULD validate the value against the active 1393 server launch phase. 1395 The following is an example domain command using the 1396 extension for a "landrush" launch phase application: 1398 C: 1399 C: 1400 C: 1401 C: 1402 C: 1404 C: domain.example 1405 C: jd1234 1406 C: sh8013 1407 C: sh8013 1408 C: 1409 C: 2fooBAR 1410 C: 1411 C: 1412 C: 1413 C: 1414 C: 1417 C: landrush 1418 C: 1419 C: 1420 C: ABC-12345 1421 C: 1422 C: 1424 3.3.4. Mixed Create Form 1426 The Mixed Create Form supports a mix of the create forms, where for 1427 example the Sunrise Create Form (Section 3.3.1) and the Claims Create 1428 Form (Section 3.3.2) MAY be supported in a single command by 1429 including both the verified trademark information and the information 1430 related to the registrant's acceptance of the Claims Notice. The 1431 server MAY support the Mixed Create Form. The "custom" launch phase 1432 SHOULD be used when using the Mixed Create Form. 1434 The following is an example domain command using the 1435 extension, with using a mix of the Sunrise Create 1436 Form (Section 3.3.1) and the Claims Create Form (Section 3.3.2) by 1437 including both a mark and a notice: 1439 C: 1440 C: 1441 C: 1442 C: 1443 C: 1445 C: domainone.example 1446 C: jd1234 1447 C: sh8013 1448 C: sh8013 1449 C: 1450 C: 2fooBAR 1451 C: 1452 C: 1453 C: 1454 C: 1455 C: 1458 C: custom 1459 C: 1460 C: 1462 C: ... 1463 C: 1464 C: 1465 C: 1466 C: 1467 C: 49FD46E6C4B45C55D4AC 1468 C: 1469 C: 2012-06-19T10:00:10.0Z 1470 C: 1471 C: 2012-06-19T09:01:30.0Z 1472 C: 1473 C: 1474 C: 1475 C: 1476 C: ABC-12345 1477 C: 1478 C: 1480 3.3.5. Create Response 1482 If the create was successful, the server MAY reply with the 1483 element along with the regular EPP to 1484 indicate the server generated Application Identifier (Section 2.1), 1485 when multiple applications of a given domain name are supported; 1486 otherwise no extension is included with the regular EPP . 1487 The element contains the following child elements: 1489 The phase of the application that mirrors the 1490 element included in the . 1491 The application identifier of the 1492 application. 1494 An example response when multiple overlapping applications are 1495 supported by the server: 1497 S: 1498 S: 1499 S: 1500 S: 1501 S: Command completed successfully; action pending 1502 S: 1503 S: 1504 S: 1506 S: domain.example 1507 S: 2010-08-10T15:38:26.623854Z 1508 S: 1509 S: 1510 S: 1511 S: 1513 S: sunrise 1514 S: 2393-9323-E08C-03B1 1515 S: 1516 S: 1517 S: 1518 S: 1519 S: ABC-12345 1520 S: 54321-XYZ 1521 S: 1522 S: 1523 S: 1525 3.4. EPP Command 1527 This extension defines additional elements to extend the EPP 1528 command to be used in conjunction with the domain name mapping. 1530 A client MUST NOT pass the extension on an EPP command to a 1531 server that does not support launch applications. A server that does 1532 not support launch applications during its launch phase MUST return 1533 an EPP error result code of 2102 when receiving an EPP 1534 command with the extension. 1536 Registry policies permitting, clients may update an application 1537 object by submitting an EPP command along with a 1538 element to indicate the application object to be 1539 updated. The element contains the following child 1540 elements: 1542 The phase during which the application was submitted 1543 or is associated with. 1544 The application identifier for which the 1545 client wishes to update. 1547 The following is an example domain command with the 1548 extension to add and remove a name server of a 1549 sunrise application with the application identifier "abc123": 1551 C: 1552 C: 1553 C: 1554 C: 1555 C: 1557 C: domain.example 1558 C: 1559 C: 1560 C: ns2.domain.example 1561 C: 1562 C: 1563 C: 1564 C: 1565 C: ns1.domain.example 1566 C: 1567 C: 1568 C: 1569 C: 1570 C: 1571 C: 1573 C: sunrise 1574 C: abc123 1575 C: 1576 C: 1577 C: ABC-12345 1578 C: 1579 C: 1581 This extension does not define any extension to the response of an 1582 domain command. After processing the command, the server 1583 replies with a standard EPP response as defined in the EPP domain 1584 name mapping [RFC5731]. 1586 3.5. EPP Command 1588 This extension defines additional elements to extend the EPP 1589 command to be used in conjunction with the domain name mapping. 1591 A client MUST NOT pass the extension on an EPP command to a 1592 server that does not support launch applications. A server that does 1593 not support launch applications during its launch phase MUST return 1594 an EPP error result code of 2102 when receiving an EPP 1595 command with the extension. 1597 Registry policies permitting, clients MAY withdraw an application by 1598 submitting an EPP command along with a 1599 element to indicate the application object to be deleted. The 1600 element contains the following child elements: 1602 The phase during which the application was submitted 1603 or is associated with. 1604 The application identifier for which the 1605 client wishes to delete. 1607 The following is an example domain command with the 1608 extension: 1610 C: 1611 C: 1612 C: 1613 C: 1614 C: 1616 C: domain.example 1617 C: 1618 C: 1619 C: 1620 C: 1622 C: sunrise 1623 C: abc123 1624 C: 1625 C: 1626 C: ABC-12345 1627 C: 1628 C: 1630 This extension does not define any extension to the response of a 1631 domain command. After processing the command, the server 1632 replies with a standard EPP response as defined in the EPP domain 1633 name mapping [RFC5731]. 1635 3.6. EPP Command 1637 This extension does not define any extension to the EPP 1638 command or response described in the EPP domain name mapping 1639 [RFC5731]. 1641 3.7. EPP Command 1643 This extension does not define any extension to the EPP 1644 command or response described in the EPP domain name mapping 1645 [RFC5731]. 1647 4. Formal Syntax 1649 One schema is presented here that is the EPP Launch Phase Mapping 1650 schema. 1652 The formal syntax presented here is a complete schema representation 1653 of the object mapping suitable for automated validation of EPP XML 1654 instances. The BEGIN and END tags are not part of the schema; they 1655 are used to note the beginning and ending of the schema for URI 1656 registration purposes. 1658 4.1. Launch Schema 1660 Copyright (c) 2012 IETF Trust and the persons identified as authors 1661 of the code. All rights reserved. 1663 Redistribution and use in source and binary forms, with or without 1664 modification, are permitted provided that the following conditions 1665 are met: 1667 o Redistributions of source code must retain the above copyright 1668 notice, this list of conditions and the following disclaimer. 1669 o Redistributions in binary form must reproduce the above copyright 1670 notice, this list of conditions and the following disclaimer in 1671 the documentation and/or other materials provided with the 1672 distribution. 1673 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1674 names of specific contributors, may be used to endorse or promote 1675 products derived from this software without specific prior written 1676 permission. 1678 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1679 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1680 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1681 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1682 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1683 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1684 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1685 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1686 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1687 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1688 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1690 BEGIN 1691 1692 1701 1704 1705 1706 1708 1709 1710 Extensible Provisioning Protocol v1.0 1711 domain name extension schema 1712 for the launch phase processing. 1713 1714 1716 1719 1720 1721 1722 1723 1725 1728 1729 1730 1732 1734 1735 1737 1740 1741 1742 1744 1750 1751 1752 1753 1754 1755 1756 1758 1761 1762 1763 1764 1765 1766 1767 1768 1769 1771 1774 1775 1776 1777 1778 1780 1781 1782 1783 1786 1787 1788 1790 1793 1794 1795 1796 1797 1799 1800 1801 1802 1804 1805 1806 1808 1811 1812 1813 1814 1815 1817 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1832 1835 1836 1837 1838 1840 1842 1843 1844 1845 1847 1851 1852 1853 1855 1857 1858 1860 1863 1864 1865 1866 1867 1869 1871 1873 1874 1877 1878 1879 1881 1884 1885 1886 1887 1888 1889 1891 1894 1895 1896 1897 1898 1899 1900 1902 1905 1906 1907 1909 1910 1912 1914 1918 1919 1920 1921 1922 1923 1924 1925 1928 1929 1930 1931 1934 1935 1937 1939 1942 1943 1944 1946 1949 1950 1951 1953 1955 1956 1958 1959 1960 1961 1963 1964 1966 1967 1968 1969 1971 1972 1974 1976 1977 1978 1979 1981 1982 1983 1985 1988 1989 1990 1991 1994 1996 1998 1999 2001 2002 END 2004 5. IANA Considerations 2006 5.1. XML Namespace 2008 This document uses URNs to describe XML namespaces and XML schemas 2009 conforming to a registry mechanism described in [RFC3688]. 2011 Registration request for the launch namespace: 2013 URI: urn:ietf:params:xml:ns:launch-1.0 2014 Registrant Contact: See the "Author's Address" section of this 2015 document. 2016 XML: None. Namespace URIs do not represent an XML specification. 2018 Registration request for the launch XML schema: 2020 URI: urn:ietf:params:xml:schema:launch-1.0 2021 Registrant Contact: See the "Author's Address" section of this 2022 document. 2023 XML: See the "Formal Syntax" section of this document. 2025 5.2. EPP Extension Registry 2027 The EPP extension described in this document should be registered by 2028 the IANA in the EPP Extension Registry described in [RFC7451]. The 2029 details of the registration are as follows: 2031 Name of Extension: "Launch Phase Mapping for the Extensible 2032 Provisioning Protocol (EPP)" 2034 Document status: Standards Track 2036 Reference: (insert reference to RFC version of this document) 2038 Registrant Name and Email Address: IESG, 2040 TLDs: Any 2042 IPR Disclosure: None 2044 Status: Active 2046 Notes: None 2048 6. Implementation Status 2050 Note to RFC Editor: Please remove this section and the reference to 2051 RFC 6982 [RFC6982] before publication. 2053 This section records the status of known implementations of the 2054 protocol defined by this specification at the time of posting of this 2055 Internet-Draft, and is based on a proposal described in RFC 6982 2056 [RFC6982]. The description of implementations in this section is 2057 intended to assist the IETF in its decision processes in progressing 2058 drafts to RFCs. Please note that the listing of any individual 2059 implementation here does not imply endorsement by the IETF. 2060 Furthermore, no effort has been spent to verify the information 2061 presented here that was supplied by IETF contributors. This is not 2062 intended as, and must not be construed to be, a catalog of available 2063 implementations or their features. Readers are advised to note that 2064 other implementations may exist. 2066 According to RFC 6982 [RFC6982], "this will allow reviewers and 2067 working groups to assign due consideration to documents that have the 2068 benefit of running code, which may serve as evidence of valuable 2069 experimentation and feedback that have made the implemented protocols 2070 more mature. It is up to the individual working groups to use this 2071 information as they see fit". 2073 6.1. Verisign EPP SDK 2075 Organization: Verisign Inc. 2077 Name: Verisign EPP SDK 2079 Description: The Verisign EPP SDK includes both a full client 2080 implementation and a full server stub implementation of draft-ietf- 2081 eppext-launchphase. 2083 Level of maturity: Production 2085 Coverage: All aspects of the protocol are implemented. 2087 Licensing: GNU Lesser General Public License 2089 Contact: jgould@verisign.com 2091 URL: http://www.verisigninc.com/en_US/channel-resources/domain- 2092 registry-products/epp-sdks 2094 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 2096 Organization: Verisign Inc. 2098 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 2099 System (SRS) 2101 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 2102 Registry System (SRS) implements the server-side of draft-ietf- 2103 eppext-launchphase for a variety of Top Level Domains (TLD's). 2105 Level of maturity: Production 2107 Coverage: The "signed mark" Mark Validation Model, the Claims Check 2108 Form for the EPP Command, the Sunrise and Claims Forms for 2109 the EPP Command of Launch Registrations and Launch 2110 Applications. For Launch Applications the Poll Messaging, the EPP 2111 Command, the EPP Command, and the EPP 2112 Command is covered. 2114 Licensing: Proprietary 2116 Contact: jgould@verisign.com 2118 6.3. Verisign .COM / .NET SRS 2120 Organization: Verisign Inc. 2122 Name: Verisign .COM / .NET Shared Registry System (SRS) 2124 Description: The Verisign Shared Registry System (SRS) for .COM, .NET 2125 and other IDN TLD's implements the server-side of draft-ietf-eppext- 2126 launchphase. 2128 Level of maturity: Operational Test Environment (OTE) 2130 Coverage: The "signed mark" Mark Validation Model, the Claims Check 2131 Form for the EPP Command, the Sunrise and Claims Forms for 2132 the EPP Command of Launch Registrations. 2134 Licensing: Proprietary 2136 Contact: jgould@verisign.com 2138 6.4. REngin v3.7 2140 Organization: Domain Name Services (Pty) Ltd 2142 Name: REngin v3.7 2144 Description: Server side implementation only 2146 Level of maturity: Production 2148 Coverage: All features from version 12 have been implemented 2150 Licensing: Proprietary Licensing with Maintenance Contracts 2152 Contact: info@dnservices.co.za 2154 URL: https://www.registry.net.za and soon http://dnservices.co.za 2156 6.5. RegistryEngine EPP Service 2158 Organization: CentralNic 2160 Name: RegistryEngine EPP Service 2162 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 2163 SLDs 2164 Level of maturity: Deployed in CentralNic's production environment as 2165 well as two other gTLD registry systems, and two ccTLD registry 2166 systems. 2168 Coverage: Majority of elements including TMCH sunrise, landrush and 2169 TM claims as well as sunrise applications validated using codes. 2171 Licensing: Proprietary In-House software 2173 Contact: epp@centralnic.com 2175 URL: https://www.centralnic.com 2177 6.6. Neustar EPP SDK 2179 Organization: Neustar 2181 Name: Neustar EPP SDK 2183 Description: The Neustar EPP SDK includes client implementation of 2184 draft-ietf-eppext-launchphase in both Java and C++. 2186 Level of maturity: Production 2188 Coverage: All aspects of the protocol are implemented. 2190 Licensing: GNU Lesser General Public License 2192 Contact: trung.tran@neustar.biz 2194 6.7. gTLD Shared Registry System 2196 Organization: Stichting Internet Domeinnaamregistratie Nederland 2197 (SIDN) 2199 Name: gTLD Shared Registry System 2201 Description: The gTLD SRS implements the server side of the draft- 2202 ietf-eppext-launchphase. 2204 Level of maturity: (soon) Production 2206 Coverage: The following parts of the draft are supported: 2208 Signed mark validation model using Digital Signature 2209 (Section 2.6.3) 2210 Claims Check Form (Section 3.1.1) 2211 Sunrise Create Form (Section 3.3.1) 2212 Claims Create Form (Section 3.3.2) 2214 The parts of the document not described here are not implemented. 2216 Licensing: Proprietary 2218 Contact: rik.ribbers@sidn.nl 2220 7. Security Considerations 2222 The mapping extensions described in this document do not provide any 2223 security services beyond those described by EPP [RFC5730], the EPP 2224 domain name mapping [RFC5731], and protocol layers used by EPP. The 2225 security considerations described in these other specifications apply 2226 to this specification as well. 2228 Updates to, and deletion of an application object must be restricted 2229 to clients authorized to perform the said operation on the object. 2231 As information contained within an application, or even the mere fact 2232 that an application exists may be confidential. Any attempt to 2233 operate on an application object by an unauthorized client MUST be 2234 rejected with an EPP 2201 (authorization error) return code. Server 2235 policy may allow operation with filtered output by clients 2236 other than the sponsoring client, in which case the 2237 and response SHOULD be filtered to include only 2238 fields that are publicly accessible. 2240 8. Acknowledgements 2242 The authors wish to acknowledge the efforts of the leading 2243 participants of the Community TMCH Model that led to many of the 2244 changes to this document, which include Chris Wright, Jeff Neuman, 2245 Jeff Eckhaus, and Will Shorter. 2247 Special suggestions that have been incorporated into this document 2248 were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Michael 2249 Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus 2250 Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell, 2251 Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung 2252 Tran, Ulrich Wisser and Sharon Wodjenski. 2254 9. Normative References 2256 [I-D.ietf-eppext-tmch-func-spec] 2257 Lozano, G., "TMCH functional specifications", draft-ietf- 2258 eppext-tmch-func-spec-00 (work in progress), October 2015. 2260 [I-D.ietf-eppext-tmch-smd] 2261 Lozano, G., "Mark and Signed Mark Objects Mapping", draft- 2262 ietf-eppext-tmch-smd-03 (work in progress), September 2263 2015. 2265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2266 Requirement Levels", BCP 14, RFC 2119, 2267 DOI 10.17487/RFC2119, March 1997, 2268 . 2270 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2271 DOI 10.17487/RFC3688, January 2004, 2272 . 2274 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2275 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 2276 . 2278 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2279 Domain Name Mapping", STD 69, RFC 5731, 2280 DOI 10.17487/RFC5731, August 2009, 2281 . 2283 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2284 Code: The Implementation Status Section", RFC 6982, 2285 DOI 10.17487/RFC6982, July 2013, 2286 . 2288 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 2289 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 2290 February 2015, . 2292 Appendix A. Change History 2294 A.1. Change from 00 to 01 2296 1. Changed to use camel case for the XML elements. 2297 2. Replaced "cancelled" status to "rejected" status. 2298 3. Added the child elements of the element. 2299 4. Removed the XML schema and replaced with "[TBD]". 2301 A.2. Change from 01 to 02 2303 1. Added support for both the ICANN and ARI/Neustar TMCH models. 2304 2. Changed the namespace URI and prefix to use "launch" instead of 2305 "launchphase". 2306 3. Added definition of multiple claim validation models. 2308 4. Added the and 2309 elements. 2310 5. Added support for Claims Info Command 2312 A.3. Change from 02 to 03 2314 1. Removed XSI namespace per Keith Gaughan's suggestion on the 2315 provreg list. 2316 2. Added extensibility to the launch:status element and added the 2317 pendingAuction status per Trung Tran's feedback on the provreg 2318 list. 2319 3. Added support for the Claims Check Command, updated the location 2320 and contents of the signedNotice, and replaced most references of 2321 Claim to Mark based on the work being done on the ARI/Neustar 2322 launch model. 2324 A.4. Change from 03 to 04 2326 1. Removed references to the ICANN model. 2327 2. Removed support for the Claims Info Command. 2328 3. Removed use of the signedClaim. 2329 4. Revised the method for referring to the signedClaim from the XML 2330 Signature using the IDREF URI. 2331 5. Split the launch-1.0.xsd into three XML schemas including launch- 2332 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 2333 6. Split the "claims" launch phase to the "claims1" and "claims2" 2334 launch phases. 2335 7. Added support for the encodedSignedMark with base64 encoded 2336 signedMark. 2337 8. Changed the elements in the createNoticeType to include the 2338 noticeID, timestamp, and the source elements. 2339 9. Added the class and effectiveDate elements to mark. 2341 A.5. Change from 04 to 05 2343 1. Removed reference to in the example. 2344 2. Incorporated feedback from Bernhard Reutner-Fischer on the 2345 provreg mail list. 2346 3. Added missing launch XML prefix to applicationIDType reference in 2347 the idContainerType of the Launch Schema. 2348 4. Added missing description of the element in the 2349 element. 2350 5. Updated note on replication of the EPP contact mapping elements 2351 in the Mark Contact section. 2353 A.6. Change from 05 to 06 2355 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 2356 replaced with reference to draft-lozano-smd, that contains the 2357 definition for the mark, signed marked, and encoded signed mark. 2358 2. Split the into and 2359 based on feedback from Trung Tran. 2360 3. Added the "includeMark" optional attribute to the 2361 element to enable the client to request whether or not to include 2362 the mark in the info response. 2363 4. Fixed state diagram to remove redundant transition from "invalid" 2364 to "rejected"; thanks Klaus Malorny. 2366 A.7. Change from 06 to 07 2368 1. Proof-read grammar and spelling. 2369 2. Changed "pendingAuction" status to "pendingAllocation", changed 2370 "pending" to "pendingValidation" status, per proposal from Trung 2371 Tran and seconded by Rubens Kuhl. 2372 3. Added text related to the use of RFC 5731 pendingCreate to the 2373 Application Identifier section. 2374 4. Added the Poll Messaging section to define the use of poll 2375 messaging for intermediate state transitions and pending action 2376 poll messaging for final state transitions. 2378 A.8. Change from 07 to 08 2380 1. Added support for use of the launch statuses and poll messaging 2381 for Launch Registrations based on feedback from Sharon Wodjenski 2382 and Trung Tran. 2383 2. Incorporated changes based on updates or clarifications in draft- 2384 lozano-tmch-func-spec-01, which include: 2386 1. Removed the unused element. 2387 2. Removed the element. 2388 3. Added the element based on the required 2389 element. 2391 A.9. Change from 08 to 09 2393 1. Made element optional in to allow 2394 passing just the in per request 2395 from Ben Levac. 2396 2. Added optional "type" attribute in to enable the 2397 client to explicitly define the desired type of object 2398 (application or registration) to create to all forms of the 2399 create extension. 2401 3. Added text that the server SHOULD validate the 2402 element in the Launch Phases section. 2403 4. Add the "General Create Form" to the create command extension to 2404 support the request from Ben Levac. 2405 5. Updated the text for the Poll Messaging section based on feedback 2406 from Klaus Malorny. 2407 6. Replaced the "claims1" and "claims2" phases with the "claims" 2408 phase based on discussion on the provreg list. 2409 7. Added support for a mixed create model (Sunrise Create Model and 2410 Claims Create Model), where a trademark (encoded signed mark, 2411 etc.) and notice can be passed, based on a request from James 2412 Mitchell. 2413 8. Added text for the handling of the overlapping "claims" and 2414 "landrush" launch phases. 2415 9. Added support for two check forms (claims check form and 2416 availability check form) based on a request from James Mitchell. 2417 The availability check form was based on the text in draft-rbp- 2418 application-epp-mapping. 2420 A.10. Change from 09 to 10 2422 1. Changed noticeIDType from base64Binary to token to be compatible 2423 with draft-lozano-tmch-func-spec-05. 2424 2. Changed codeType from base64Binary to token to be more generic. 2425 3. Updated based on feedback from Alexander Mayrhofer, which 2426 include: 2428 1. Changed "extension to the domain name extension" to 2429 "extension to the domain name mapping". 2430 2. Changed use of 2004 return code to 2306 return code when 2431 phase passed mismatches active phase and sub-phase. 2432 3. Changed description of "allocated" and "rejected" statuses. 2433 4. Moved sentence on a synchronous command 2434 without the use of an intermediate application, then an 2435 Application Identifier MAY not be needed to the Application 2436 Identifier section. 2437 5. Restructured the Mark Validation Models section to include 2438 the " element" sub-section, the 2439 " element" sub-section, and the Digital Signature 2440 sub-section. 2441 6. Changed "Registries may" to "Registries MAY". 2442 7. Changed "extensed" to "extended" in "Availability Check 2443 Form" section. 2444 8. Broke the mix of create forms in the "EPP Command" 2445 section to a fourth "Mixed Create Form" with its own sub- 2446 section. 2447 9. Removed "displayed or" from "displayed or accepted" in the 2448 description. 2450 10. Replaced "given domain name is supported" with "given domain 2451 name are supported" in the "Create Response" section. 2452 11. Changed the reference of 2303 (object does not exist) in the 2453 "Security Considerations" section to 2201 (authorization 2454 error). 2455 12. Added arrow from "invalid" status to "pendingValidation" 2456 status and "pendingAllocation" status to "rejected" status 2457 in the State Transition Diagram. 2458 4. Added the "C:" and "S:" example prefixes and related text in the 2459 "Conventions Used in This Document" section. 2461 A.11. Change from 10 to 11 2463 1. Moved the claims check response element under 2464 the element instead of the element based on 2465 the request from Francisco Obispo. 2467 A.12. Change from 11 to 12 2469 1. Added support for multiple validator identifiers for claims 2470 notices and marks based on a request and text provided by Mike 2471 O'Connell. 2472 2. Removed domain:exDate element from example in section 3.3.5 based 2473 on a request from Seth Goldman on the provreg list. 2474 3. Added clarifying text for clients not passing the launch 2475 extension on update and delete commands to servers that do not 2476 support launch applications based on a request from Sharon 2477 Wodjenski on the provreg list. 2479 A.13. Change from 12 to WG 00 2481 1. Changed to eppext working group draft by changing draft-tan-epp- 2482 launchphase to draft-ietf-eppext-launchphase and by changing 2483 references of draft-lozano-tmch-smd to draft-ietf-eppext-tmch- 2484 smd. 2486 A.14. Change WG 00 to WG 01 2488 1. Removed text associated with support for the combining of status 2489 values based on feedback from Patrick Mevzek on the provreg 2490 mailing list, discussion on the eppext mailing list, and 2491 discussion at the eppext IETF meeting on March 6, 2014. 2493 A.15. Change WG 01 to WG 02 2495 1. Changed the element to be zero or more elements 2496 and the element to be one or more elements in the 2497 Claims Create Form. These changes were needed to be able to 2498 support more than one concurrent claims services. 2500 A.16. Change WG 02 to WG 03 2502 1. Added the "Implementation Status" section based on an action item 2503 from the eppext IETF-91 meeting. 2504 2. Moved Section 7 "IANA Considerations" and Section 9 "Security 2505 Considerations" before Section 5 "Acknowledgements". Moved 2506 "Change Log" Section to end. 2507 3. Updated the text for the Claims Check Form and the Claims Create 2508 Form to support checking for the need of the claims notice and 2509 passing the claims notice outside of the "claims" phase. 2510 4. Added the new Trademark Check Form to support determining whether 2511 or not a trademark exists that matches the domain name 2512 independent of whether a claims notice is required on create. 2513 This was based on a request from Trung Tran and a discussion on 2514 the eppext mailing list. 2516 A.17. Change WG 03 to WG 04 2518 1. Amended XML Namespace section of IANA Considerations, added EPP 2519 Extension Registry section. 2521 A.18. Change WG 04 to WG 05 2523 1. Added a missing comma to the descripton of the 2524 element, based on feedback from Keith Gaughan on the eppext 2525 mailing list. 2526 2. Added the SIDN implementation status information. 2527 3. Fixed a few indentation issues in the samples. 2529 A.19. Change WG 05 to WG 06 2531 1. Removed duplicate "TMCH Functional Specification" URIs based on 2532 feedback from Scott Hollenbeck on the eppext mailing list. 2533 2. Changed references of example?.tld to domain?.example to be 2534 consistent with RFC 6761 based on feedback from Scott Hollenbeck 2535 on the eppext mailing list. 2536 3. A template was added to section 5 to register the XML schema in 2537 addition to the namespace based on feedback from Scott Hollenbeck 2538 on the eppext mailing list. 2540 A.20. Change WG 06 to WG 07 2542 1. Changed reference of lozano-tmch-func-spec to ietf-eppext-tmch- 2543 func-spec. 2545 Authors' Addresses 2547 James Gould 2548 VeriSign, Inc. 2549 12061 Bluemont Way 2550 Reston, VA 20190 2551 US 2553 Email: jgould@verisign.com 2554 URI: http://www.verisigninc.com 2556 Wil Tan 2557 Cloud Registry 2558 Suite 32 Seabridge House 2559 377 Kent St 2560 Sydney, NSW 2000 2561 AU 2563 Phone: +61 414 710899 2564 Email: wil@cloudregistry.net 2565 URI: http://www.cloudregistry.net 2567 Gavin Brown 2568 CentralNic Ltd 2569 35-39 Mooregate 2570 London, England EC2R 6AR 2571 GB 2573 Phone: +44 20 33 88 0600 2574 Email: gavin.brown@centralnic.com 2575 URI: https://www.centralnic.com