idnits 2.17.1 draft-tan-epp-launchphase-08.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 (March 28, 2013) is 4045 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Tan 3 Internet-Draft Cloud Registry 4 Intended status: Standards Track G. Brown 5 Expires: September 29, 2013 CentralNic Ltd 6 J. Gould 7 VeriSign, Inc. 8 March 28, 2013 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-tan-epp-launchphase-08 13 Abstract 15 This document describes an Extensible Provisioning Protocol (EPP) 16 extension mapping for the provisioning and management of domain name 17 applications during the launch of a domain name registry. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 29, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Application Identifier . . . . . . . . . . . . . . . . . . 4 57 2.2. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3.1. State Transition . . . . . . . . . . . . . . . . . . . 7 60 2.4. Poll Messaging . . . . . . . . . . . . . . . . . . . . . . 8 61 2.5. Mark Validation Models . . . . . . . . . . . . . . . . . . 10 62 2.5.1. element . . . . . . . . . . . . . . 11 63 2.6. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 2.7. Digital Signature . . . . . . . . . . . . . . . . . . . . 12 65 2.7.1. element . . . . . . . . . . . . . . . 12 66 2.7.2. element . . . . . . . . . . . 12 67 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12 68 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 13 69 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 17 70 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 21 71 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 21 72 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 27 73 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 29 74 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 31 75 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 32 76 3.7. EPP Command . . . . . . . . . . . . . . . . . . 32 77 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 33 78 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 33 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 80 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 39 81 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 39 82 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 39 83 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 40 84 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 40 85 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 40 86 6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . . 40 87 6.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . . 41 88 6.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . . 41 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 91 9. Normative References . . . . . . . . . . . . . . . . . . . . . 42 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 94 1. Introduction 96 This document describes an extension mapping for version 1.0 of the 97 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 98 specifies a flexible schema that can be used to implement several 99 common use cases related to the provisioning and management of domain 100 name applications during the launch of a domain name registry. 102 It is typical for domain registries to operate in special modes 103 during their initial launch to facilitate allocation of domain names, 104 often according to special rules. This document uses the term 105 "launch phase" and the shorter form "launch" to refer to such a 106 period. 108 The EPP domain name mapping [RFC5731] is designed for the steady- 109 state operation of a registry. During a launch period, the model in 110 place may be different from what is defined in EPP domain name 111 mapping [RFC5731]. For example, registries often accept multiple 112 applications for the same domain name during the "Sunrise" launch 113 phase, referred to as a Launch Application. A Launch Registration 114 refers to a registration made during a launch phase when the server 115 uses a "first-come, first-served" model. Even in a "first-come, 116 first-served" model, additional steps and information might be 117 required to support an application, such as trademark information. 118 In addition, the TMCH Functional Specification [1] defines a registry 119 interface for the Trademark Claims or "claims" launch phase that 120 includes support for presenting a Trademark Claims Notice to the 121 Registrant. This document proposes an extension to the domain name 122 extension in order to unambiguously manage the various launch phases 123 known. 125 1.1. Conventions Used in This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 XML is case sensitive. Unless stated otherwise, XML specifications 132 and examples provided in this document MUST be interpreted in the 133 character case presented in order to develop a conforming 134 implementation. 136 "launch-1.0" is used as an abbreviation for 137 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 138 "launch" is used, but implementations MUST NOT depend on it and 139 instead employ a proper namespace-aware XML parser and serializer to 140 interpret and output the XML documents. 142 "signedMark-1.0" is used as an abbreviation for 143 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 144 [draft-lozano-smd]. The XML namespace prefix "smd" is used, but 145 implementations MUST NOT depend on it and instead employ a proper 146 namespace-aware XML parser and serializer to interpret and output the 147 XML documents. 149 "mark-1.0" is used as an abbreviation for 150 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 151 [draft-lozano-smd]. The XML namespace prefix "mark" is used, but 152 implementations MUST NOT depend on it and instead employ a proper 153 namespace-aware XML parser and serializer to interpret and output the 154 XML documents. 156 2. Object Attributes 158 This extension adds additional elements to the EPP domain name 159 mapping [RFC5731]. Only those new elements are described here. 161 2.1. Application Identifier 163 Servers MAY allow multiple applications, referred to as a Launch 164 Application, of the same domain name during its launch phase 165 operations. Upon receiving a valid request to create a Launch 166 Application, the server MUST create an application object 167 corresponding to the request, assign an application identifier for 168 the Launch Application, set the [RFC5731] pendingCreate status, and 169 return the application identifier to the client with the element. In order to facilitate correlation, all 171 subsequent launch operations on the Launch Application MUST be 172 qualified by the previously assigned application identifier using the 173 element. 175 2.2. Launch Phases 177 The server MAY support multiple launch phases sequentially or 178 simultaneously. The element MUST be included by the 179 client to define the target launch phase of the command. 181 The following launch phase values are defined: 182 sunrise The phase during which trademark holders can submit 183 registrations or applications with trademark information that can 184 be validated by the server. 186 landrush A post-Sunrise phase when non-trademark holders are allowed 187 to register domain names with steps taken to address a large 188 volume of initial registrations. 189 claims1 The Trademark Claims Phase 1, as defined by Trademark 190 Clearinghouse model, in which a full, detailed Claims Notice must 191 be displayed to prospective registrants of domain names that match 192 trademarks. 193 claims2 The Trademark Claims Phase 2, as defined by Trademark 194 Clearinghouse model, in which a short, educational Claims Notice 195 must be displayed to prospective registrants of domain names that 196 match trademarks that have opted in. 197 open A post-launch phase that is also referred to as "steady state". 198 Servers MAY require additional trademark protection during this 199 phase. 200 custom A custom server launch phase that is defined using the "name" 201 attribute. 203 For extensibility, the element includes an OPTIONAL 204 "name" attribute that can define a sub-phase or the full name of the 205 phase when the element has the "custom" value. For 206 example, the "claims1" launch phase could have two sub-phases that 207 include "landrush" and "open". 209 2.3. Status Values 211 A Launch Application or Launch Registration object MAY have a launch 212 status value. The element is used to convey the 213 launch status pertaining to the object, beyond what is specified in 214 the object mapping. A Launch Application or Launch Registration MUST 215 set the [RFC5731] pendingCreate status if a launch status is 216 supported and the launch status is not one of the final statuses, 217 including the "allocated" and "rejected" statuses. 219 The following status values are defined using the required "s" 220 attribute: 221 pendingValidation: The initial state of a newly-created application 222 or registration object. The application or registration requires 223 validation, but the validation process has not yet completed. 224 validated: The application or registration meets relevant registry 225 rules. 226 invalid: The application or registration does not validate according 227 to registry rules. 228 pendingAllocation: The allocation of the application or registration 229 is pending based on the results of some out-of-band process (for 230 example, an auction). 232 allocated: One of two possible end states of an application or 233 registration object; the object corresponding to the application 234 or registration has been provisioned. 235 rejected: The other possible end state; the application or 236 registration object was not provisioned. 237 custom: A custom status that is defined using the "name" attribute. 239 Each status value MAY be accompanied by a string of human-readable 240 text that describes the rationale for the status applied to the 241 object. The OPTIONAL "lang" attribute MAY be present to identify the 242 language if the negotiated value is something other than the default 243 value of "en" (English). 245 For extensibility the element includes an OPTIONAL 246 "name" attribute that can define a sub-status or the full name of the 247 status when the status value is "custom". The server SHOULD NOT use 248 the "custom" status value. 250 Certain status values MAY be combined. For example, an application 251 or registration may be both "invalid" and "rejected". Additionally, 252 certain statuses MAY be skipped. For example, an application or 253 registration MAY immediately start at the "allocated" status or an 254 application or registration MAY skip the "pendingAllocation" status. 255 If the launch phase does not require validation of a request, an 256 application or registration MAY immediately skip to 257 "pendingAllocation". If the command processes a 258 request synchronously without the use of an intermediate application, 259 then an Application Identifier (Section 2.1) MAY not be needed along 260 with the application status. 262 2.3.1. State Transition 264 | request 265 | 266 v 267 +-------------------+ 268 | | 269 | pendingValidation | 270 | | 271 +---------+---------+ 272 | 273 | 274 +-----------+-----------+ 275 | | 276 | | 277 v v 278 +-----------+ +---------+ 279 | | | | 280 | validated | | invalid | 281 | | | | 282 +-----+-----+ +----+----+ 283 | | 284 | | 285 v | 286 +-------------------+ | 287 | | | 288 | pendingAllocation | | 289 | | | 290 +-------------------+ | 291 | | 292 | | 293 +-----------------------+ 294 | | 295 | | 296 v v 297 +---------+ +--------+ 298 / \ / \ 299 | allocated | | rejected | 300 \ / \ / 301 +---------+ +--------+ 303 Figure 1 305 2.4. Poll Messaging 307 A Launch Application MUST and a Launch Registration MAY be handled as 308 a domain name of [RFC5731] in "pendingCreate" status, with the launch 309 status values defined in Section 2.3. As a Launch Application or 310 Launch Registration transitions between the status values defined in 311 Section 2.3, the server SHOULD insert poll messages, per [RFC5730], 312 for the applicable intermediate statuses, including the 313 "pendingValidation", "validated", "pendingAllocation, and "invalid" 314 statuses, using the element with the extension. The server MUST insert a poll 316 message, per [RFC5731], with the extension for the 317 final statuses, including the "allocated" and "rejected" statuses. 319 The following is an example poll message for a Launch Application 320 that has transitioned to the "pendingAllocation" state. 322 323 324 325 326 Command completed successfully; ack to dequeue 327 328 329 2013-04-04T22:01:00.0Z 330 Application pendingAllocation. 331 332 333 335 example.tld 336 ... 337 338 339 340 342 sunrise 343 abc123 344 345 346 347 348 ABC-12345 349 54322-XYZ 350 351 352 353 The following is an example poll message for an 354 "allocated" Launch Application. 356 357 358 359 360 Command completed successfully; ack to dequeue 361 362 363 2013-04-04T22:01:00.0Z 364 Application successfully allocated. 365 366 367 369 example.tld 370 371 ABC-12345 372 54321-XYZ 373 374 2013-04-04T22:00:00.0Z 375 376 377 378 380 sunrise 381 abc123 382 383 384 385 386 BCD-23456 387 65432-WXY 388 389 390 391 The following is an example poll message for an 392 "allocated" Launch Registration. 394 395 396 397 398 Command completed successfully; ack to dequeue 399 400 401 2013-04-04T22:01:00.0Z 402 Registration successfully allocated. 403 404 405 407 example.tld 408 409 ABC-12345 410 54321-XYZ 411 412 2013-04-04T22:00:00.0Z 413 414 415 416 418 sunrise 419 420 421 422 423 BCD-23456 424 65432-WXY 425 426 427 429 2.5. Mark Validation Models 431 A server MUST support at least one of the following models for 432 validating trademark information: 434 code Use of a mark code by itself to validate that the mark matches 435 the domain name. This model is supported using the element with just the element. 438 mark The mark information is passed without any other validation 439 element. The server will use some custom form of validation to 440 validate that the mark information is authentic. This model is 441 supported using the element with just the (Section 2.6) element. 443 code with mark: A code is used along with the mark information by 444 the server to validate the mark utilizing an external party. The 445 code represents some form of secret that matches the mark 446 information passed. This model is supported using the element that contains both the and the 448 (Section 2.6) elements. 449 signed mark: The mark information is digitally signed as described 450 in the Digital Signature (Section 2.7) section. The digital 451 signature can be directly validated by the server using the public 452 key of the external party that created the signed mark using its 453 private key. This model is supported using the 454 (Section 2.7.1) and (Section 2.7.2) 455 elements. 457 More than one , (Section 2.7.1), or 458 (Section 2.7.2) element MAY be specified. 459 The maximum number of marks per domain name is up to server policy. 461 2.5.1. element 463 The element that is used by the "code", "mark", and 464 "code with mark" validation models, has the following child elements: 466 : OPTIONAL mark code used to validate the 467 (Section 2.6) information. The mark code is be a mark-specific 468 secret that the server can verify against a third party. 469 : OPTIONAL mark information with child elements defined 470 in the Mark (Section 2.6) section. 472 The following is an example element with both a 473 and (Section 2.6) element. 475 476 49FD46E6C4B45C55D4AC 477 478 ... 479 480 482 2.6. Mark 484 A element describes an applicant's prior right to a given 485 domain name that is used with the "mark", "mark with code", and the 486 "signed mark" validation models. The element is defined 487 in [draft-lozano-smd]. A new mark format can be supported by 488 creating a new XML schema for the mark that has an element that 489 substitutes for the element from 490 [draft-lozano-smd]. 492 2.7. Digital Signature 494 Digital signatures MAY be used by the server to validate either the 495 mark information, when using the "signed mark" validation model with 496 the (Section 2.7.1) element or the (Section 2.7.2) element. 499 2.7.1. element 501 The element contains the digitally signed mark 502 information. The element is defined in 503 [draft-lozano-smd]. A new signed mark format can be supported by 504 creating a new XML schema for the signed mark that has an element 505 that substitutes for the element from 506 [draft-lozano-smd]. 508 2.7.2. element 510 The element contains an encoded form of the 511 digitally signed (Section 2.7.1) element. The element is defined in [draft-lozano-smd]. A new 513 encoded signed mark format can be supported by creating a new XML 514 schema for the encoded signed mark that has an element that 515 substitutes for the element from 516 [draft-lozano-smd]. 518 3. EPP Command Mapping 520 A detailed description of the EPP syntax and semantics can be found 521 in the EPP core protocol specification [RFC5730]. The command 522 mappings described here are specifically for use in the Launch Phase 523 Extension. 525 This mapping is designed to be flexible, requiring only a minimum set 526 of required elements. 528 While it is meant to serve several use cases, it does not prescribe 529 any interpretation by the client or server. Such processing is 530 typically highly policy-dependent and therefore specific to 531 implementations. 533 Operations on application objects are done via one or more of the 534 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 535 Registries may choose to support a subset of the operations. 537 3.1. EPP Command 539 This extension defines additional elements to extend the EPP 540 command and response to be used in conjunction with the EPP domain 541 name mapping [RFC5731]. 543 This extension defines a new command called the Claims Check Command 544 that is used to determine whether or not there are any matching 545 trademarks, in the specified launch phase, for each domain name 546 passed in the command. The availability check information defined in 547 the EPP domain name mapping [RFC5731] MUST NOT be returned for the 548 Claims Check Command. 550 Instead of returning whether the domain name is available, the Claims 551 Check Command will return whether or not at least one matching 552 trademark exists for the domain name. If there is at least one 553 matching trademark that exists for the domain name, a element is returned. The client may then use the value of 555 the element to obtain information needed to 556 generate the trademark Claims Notice from a third-party trademark 557 validator such as the Trademark Clearinghouse (TMCH). The third 558 party trademark validator should also return a unique notice 559 identifier that can be passed in the element of the 560 extension to the Create Command (Section 3.3). 562 The elements in the EPP command of EPP domain 563 name mapping [RFC5731] define the domain names to check for matching 564 trademarks. The element contains the following child 565 elements: 567 The launch phase, with a value of either "claims1" or 568 "claims2" to indicate that the command is a Claims Check Command. 569 The "claims1" Claims Check Command will match the 570 against the full list of trademark labels. The "claims2" Claims 571 Check Command will match the against the list of 572 trademark labels that opted into the "claims2" launch phase. 574 Example Claims Check command using the domain command and the 575 extension to determine if "example1.tld" and 576 "example2.tld" have any matching trademarks during the "claims1" 577 launch phase: 579 580 581 582 583 585 example1.tld 586 example2.tld 587 588 589 590 592 claims1 593 594 595 ABC-12345 596 597 599 Example Claims Check Command using the domain command and the 600 extension to determine if "example3.tld" and 601 "example4.tld" have any matching trademarks that opted into the 602 "claims2" launch phase: 604 605 606 607 608 610 example3.tld 611 example4.tld 612 613 614 615 617 claims2 618 619 620 ABC-12345 621 623 625 If the command has been processed successfully, the EPP 626 element MUST contain a child element that 627 identifies the launch namespace. The element 628 contains the following child elements: 630 The launch phase, with a value of either "claims1" or 631 "claims2", which matches the associated Claims Check Command 632 . 633 One or more elements that contain the 634 following child elements: 636 Contains the fully qualified name of the queried 637 domain name. This element MUST contain an "exists" attribute 638 whose value indicates if a matching trademark exists for the 639 domain name. A value of "1" (or "true") means that a 640 matching trademark does exist for the claims launch phase. A 641 value of "0" (or "false") means that a matching trademark 642 does not exist. 643 An OPTIONAL claim key that MAY be passed to a 644 third-party trademark validator such as the Trademark 645 Clearinghouse (TMCH) for querying the information needed to 646 generate a Trademark Claims Notice. The is 647 used as the key for the query in place of the domain name to 648 securely query the service without using a well-known value 649 like a domain name. 651 Example Claims Check response when no matching trademarks are found 652 for the domain name example1.tld and matching trademarks are found 653 for the domain name example2.tld for the "claims1" launch phase: 655 656 657 658 659 Command completed successfully 660 661 662 664 claims1 665 666 example1.tld 667 668 669 example2.tld 670 abc123 671 672 673 674 675 ABC-12345 676 54321-XYZ 677 678 679 680 Example Claims Check response when no matching trademarks are found 681 for the domain name example3.tld and matching trademarks are found 682 for the domain name example4.tld for the "claims2" launch phase: 684 685 686 687 688 Command completed successfully 689 690 691 693 claims2 694 695 example3.tld 696 697 698 example4.tld 699 abc123 700 701 702 703 704 ABC-12345 705 54321-XYZ 706 707 708 710 3.2. EPP Command 712 This extension defines additional elements to extend the EPP 713 command and response to be used in conjunction with the EPP domain 714 name mapping [RFC5731]. 716 The EPP command is used to retrieve information for a launch 717 phase registration or application. The Application Identifier 718 (Section 2.1) returned in the element of the create 719 response (Section 3.3) is used for retrieving information for a 720 Launch Application. A element is sent along with the 721 regular domain command. The element includes an 722 OPTIONAL "includeMark" boolean attribute, with a default value of 723 "false", to indicate whether or not to include the mark in the 724 response. The element contains the following child 725 elements: 727 The phase during which the application or 728 registration was submitted or is associated with. Server policy 729 defines the phases that are supported. 730 OPTIONAL application identifier of the Launch 731 Application. 733 Example domain command with the extension to 734 retrieve information for the sunrise application for example.tld and 735 application identifier "abc123": 737 738 739 740 741 743 example.tld 744 745 746 747 750 sunrise 751 abc123 752 753 754 ABC-12345 755 756 757 Example domain command with the extension to 758 retrieve information for the sunrise registration for example.tld: 760 761 762 763 764 766 example.tld 767 768 769 770 772 sunrise 773 774 775 ABC-12345 776 777 779 If the query was successful, the server replies with a element along with the regular EPP . The contains the following child elements: 783 The phase during which the application was submitted, 784 or is associated with, that matches the associated command 785 . 786 OPTIONAL Application Identifier of the Launch 787 Application. 788 OPTIONAL status of the Launch Application using one 789 of the supported status values (Section 2.3). 790 Zero or more (Section 2.6) elements. 792 Example domain response using the extension 793 with the mark information: 795 796 797 798 799 Command completed successfully 800 801 802 804 example.tld 805 EXAMPLE1-REP 806 807 jd1234 808 sh8013 809 sh8013 810 ClientX 811 ClientY 812 2012-04-03T22:00:00.0Z 813 814 2fooBAR 815 816 817 818 819 821 sunrise 822 abc123 823 824 826 ... 827 828 829 830 831 ABC-12345 832 54321-XYZ 833 834 835 837 3.3. EPP Command 839 There are two forms of the extension to the EPP command that 840 are dependent on the supported launch phases (Section 2.2) as defined 841 below: 843 sunrise The EPP command with the "sunrise" launch phase is 844 used to submit a registration with trademark information that can 845 be verified by the server with the value. The 846 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 847 launch phase. Optionally, the server can support multiple 848 overlapping applications that are chosen asynchronously with a 849 server generated Application Identifier (Section 2.1) for later 850 reference. 851 landrush The EPP command with the "landrush" launch phase 852 is undefined but the form supported is up to server policy. 853 claims1 The EPP command with the "claims1" launch phase is 854 used to pass the information associated with the presentation and 855 acceptance of the "claims1" Claims Notice. The Claims Create Form 856 (Section 3.3.2) is used for the "claims1" launch phase. 857 claims2 The EPP command with the "claims2" launch phase is 858 used to pass the information associated with the presentation of 859 the "claims2" Claims Notice. The Claims Create Form 860 (Section 3.3.2) is used for the "claims2" launch phase. 861 open The EPP command with the "open" launch phase is 862 undefined but the form supported is up to server policy. 863 custom The EPP command with the "custom" launch phase is 864 undefined but the form supported is up to server policy. 866 3.3.1. Sunrise Create Form 868 The Sunrise Create Form of the extension to the EPP domain name 869 mapping [RFC5731] includes the verifiable trademark information that 870 the server uses to match against the domain name to authorize the 871 domain create. A server MUST support one of four models in Claim 872 Validation Models (Section 2.5) to verify the trademark information 873 passed by the client. 875 A element is sent along with the regular 876 domain command. The element contains the following 877 child elements: 879 The identifier for the launch phase. 880 or or 881 Zero or more elements. The 882 child elements are defined in the element (Section 2.5.1) section. 884 Zero or more elements. The 885 child elements are defined in the element (Section 2.7.1) section. 887 Zero or more 888 elements. The child elements are 889 defined in the element 890 (Section 2.7.2) section. 892 The following is an example domain command using the 893 extension, following the "code" validation model, 894 with multiple sunrise codes: 896 897 898 899 900 902 example.tld 903 jd1234 904 sh8013 905 sh8013 906 907 2fooBAR 908 909 910 911 912 914 sunrise 915 916 49FD46E6C4B45C55D4AC 917 918 919 49FD46E6C4B45C55D4AD 920 921 922 49FD46E6C4B45C55D4AE 923 924 925 926 ABC-12345 927 928 929 The following is an example domain command using the 930 extension, following the "mark" validation model, 931 with the mark information: 933 934 935 936 937 939 exampleone.tld 940 jd1234 941 sh8013 942 sh8013 943 944 2fooBAR 945 946 947 948 949 951 sunrise 952 953 955 ... 956 957 958 959 960 ABC-12345 961 962 963 The following is an example domain command using the 964 extension, following the "code with mark" validation 965 model, with a code and mark information: 967 968 969 970 971 973 example.tld 974 jd1234 975 sh8013 976 sh8013 977 978 2fooBAR 979 980 981 982 983 985 sunrise 986 987 49FD46E6C4B45C55D4AC 988 990 ... 991 992 993 994 995 ABC-12345 996 997 998 The following is an example domain command using the 999 extension, following the "signed mark" validation 1000 model, with the signed mark information: 1002 1003 1004 1005 1006 1008 exampleone.tld 1009 jd1234 1010 sh8013 1011 sh8013 1012 1013 2fooBAR 1014 1015 1016 1017 1018 1020 sunrise 1021 1023 ... 1024 1025 1026 1027 ABC-12345 1028 1029 1030 The following is an example domain command using the 1031 extension, following the "signed mark" validation 1032 model, with the base64 encoded signed mark information: 1034 1035 1036 1037 1038 1040 exampleone.tld 1041 jd1234 1042 sh8013 1043 sh8013 1044 1045 2fooBAR 1046 1047 1048 1049 1050 1052 sunrise 1053 1055 ... 1056 1057 1058 1059 ABC-12345 1060 1061 1063 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1065 server generated Application Identifier (Section 2.1), when multiple 1066 applications of a given domain name is supported; otherwise no 1067 extension is included with the regular EPP . The element contains the following child elements: 1070 The phase of the application that mirrors the 1071 element included in the . 1072 The application identifier of the 1073 application. 1075 An example response when multiple overlapping applications are 1076 supported by the server: 1078 1079 1080 1081 1082 Command completed successfully; action pending 1083 1084 1085 1087 example.tld 1088 2010-08-10T15:38:26.623854Z 1089 2012-08-10T15:38:26.623854Z 1090 1091 1092 1093 1095 sunrise 1096 2393-9323-E08C-03B1 1097 1098 1099 1100 1101 ABC-12345 1102 54321-XYZ 1103 1104 1105 1107 3.3.2. Claims Create Form 1109 The Claims Create Form of the extension to the EPP domain name 1110 mapping [RFC5731] includes the information related to the 1111 registrant's acceptance of the Claims Notice for the "claims1" launch 1112 phase and the display of the Claims Notice for the "claims2" launch 1113 phase. 1115 A element is sent along with the regular 1116 domain command. The element contains the following 1117 child elements: 1119 MUST contain the value of "claims1" or "claim2" to 1120 indicate the claims launch phase. 1121 1122 Unique notice identifier generated by the 1123 source of the Claims Notice information. 1124 Expiry of the claims notice. 1125 Contains the date and time that the Claims 1126 Notice was displayed or accepted. 1128 The following is an example domain command using the 1129 extension with the information for 1130 the "claims1" claims launch phase: 1132 1133 1134 1135 1136 1138 example.tld 1139 jd1234 1140 sh8013 1141 sh8013 1142 1143 2fooBAR 1144 1145 1146 1147 1148 1150 claims1 1151 1152 49FD46E6C4B45C55D4AC 1153 2012-06-19T10:00:10.0Z 1154 1155 2012-06-19T09:01:30.0Z 1156 1157 1158 1159 1160 ABC-12345 1161 1162 1164 This extension does not define any extension to the response of a 1165 domain command for the Claims Create Form. After processing 1166 the command, the server replies with a standard EPP response as 1167 defined in the EPP domain name mapping [RFC5731]. 1169 3.4. EPP Command 1171 This extension defines additional elements to extend the EPP 1172 command to be used in conjunction with the domain name mapping. 1174 A server that does not support multiple applications of a given 1175 domain name with an Application Identifier (Section 2.1) during its 1176 launch phase operations MUST return an EPP error result code of 2102. 1178 Registry policies permitting, clients may update an application 1179 object by submitting an EPP command along with a element to indicate the application object to be updated. 1181 The element contains the following child elements: 1183 The phase during which the application was submitted 1184 or is associated with. 1185 The application identifier for which the 1186 client wishes to update. 1188 This extension does not define any extension to the response of an 1189 domain command. After processing the command, the server 1190 replies with a standard EPP response as defined in the EPP domain 1191 name mapping [RFC5731]. 1193 The following is an example domain command with the extension to add and remove a name server of a sunrise 1195 application with the application identifier "abc123": 1197 1198 1199 1200 1201 1203 example.tld 1204 1205 1206 ns2.example.tld 1207 1208 1209 1210 1211 ns1.example.tld 1212 1213 1214 1215 1216 1217 1219 sunrise 1220 abc123 1221 1222 1223 ABC-12345 1224 1225 1226 An example response that corresponds to the above command: 1228 1229 1230 1231 1232 Command completed successfully 1233 1234 1235 ABC-12345 1236 54321-XYZ 1237 1238 1239 1241 3.5. EPP Command 1243 This extension defines additional elements to extend the EPP 1244 command to be used in conjunction with the domain name mapping. 1246 A server that does not support multiple applications of a given 1247 domain name with an Application Identifier (Section 2.1) during its 1248 launch phase operations MUST return an EPP error result code of 2102. 1250 Registry policies permitting, clients MAY withdraw an application by 1251 submitting an EPP command along with a 1252 element to indicate the application object to be deleted. The 1253 element contains the following child elements: 1255 The phase during which the application was submitted 1256 or is associated with. 1257 The application identifier for which the 1258 client wishes to delete. 1260 This extension does not define any extension to the response of a 1261 domain command. After processing the command, the server 1262 replies with a standard EPP response as defined in the EPP domain 1263 name mapping [RFC5731]. 1265 The following is an example domain command with the extension: 1268 1269 1270 1271 1272 1274 example.tld 1275 1276 1277 1278 1280 sunrise 1281 abc123 1282 1283 1284 ABC-12345 1285 1286 1288 An example response that corresponds to the above command: 1290 1291 1292 1293 1294 Command completed successfully 1295 1296 1297 ABC-12345 1298 54321-XYZ 1299 1300 1301 1303 3.6. EPP Command 1305 This extension does not define any extension to the EPP 1306 command or response described in the EPP domain name mapping 1307 [RFC5731]. 1309 3.7. EPP Command 1311 This extension does not define any extension to the EPP 1312 command or response described in the EPP domain name mapping 1314 [RFC5731]. 1316 4. Formal Syntax 1318 One schema is presented here that is the EPP Launch Phase Mapping 1319 schema. 1321 The formal syntax presented here is a complete schema representation 1322 of the object mapping suitable for automated validation of EPP XML 1323 instances. The BEGIN and END tags are not part of the schema; they 1324 are used to note the beginning and ending of the schema for URI 1325 registration purposes. 1327 4.1. Launch Schema 1329 Copyright (c) 2012 IETF Trust and the persons identified as authors 1330 of the code. All rights reserved. 1332 Redistribution and use in source and binary forms, with or without 1333 modification, are permitted provided that the following conditions 1334 are met: 1336 o Redistributions of source code must retain the above copyright 1337 notice, this list of conditions and the following disclaimer. 1338 o Redistributions in binary form must reproduce the above copyright 1339 notice, this list of conditions and the following disclaimer in 1340 the documentation and/or other materials provided with the 1341 distribution. 1342 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1343 names of specific contributors, may be used to endorse or promote 1344 products derived from this software without specific prior written 1345 permission. 1347 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1348 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1349 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1350 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1351 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1352 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1353 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1354 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1355 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1356 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1357 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1359 BEGIN 1360 1361 1370 1373 1376 1379 1382 1383 1384 Extensible Provisioning Protocol v1.0 1385 domain name extension schema 1386 for the launch phase processing. 1387 1388 1390 1393 1394 1395 1396 1397 1399 1402 1403 1404 1405 1406 1407 1408 1411 1412 1413 1415 1421 1422 1423 1424 1425 1426 1427 1429 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1443 1446 1447 1448 1449 1450 1452 1455 1456 1457 1458 1459 1461 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1476 1479 1480 1481 1482 1484 1486 1487 1488 1489 1491 1495 1496 1497 1499 1501 1502 1503 1506 1507 1508 1509 1510 1512 1514 1516 1518 1519 1520 1522 1525 1526 1527 1528 1529 1530 1531 1533 1536 1537 1538 1539 1540 1542 1545 1546 1547 1548 1551 1552 1554 1556 1559 1560 1561 1563 1566 1567 1568 1569 1571 1572 1574 1575 1576 1577 1579 1580 1582 1583 1584 1585 1587 1588 1589 1591 1594 1595 1596 1598 1601 1603 1605 1606 1608 1609 END 1611 5. Acknowledgements 1613 The authors wish to acknowledge the efforts of the leading 1614 participants of the Community TMCH Model that led to many of the 1615 changes to this document, which include Chris Wright, Jeff Neuman, 1616 Jeff Eckhaus, and Will Shorter. 1618 Special suggestions that have been incorporated into this document 1619 were provided by Jothan Frakes, Keith Gaughan, Jan Jansen, Rubens 1620 Kuhl, Gustavo Lozano, Klaus Malorny, Patrick Mevzek, Bernhard 1621 Reutner-Fischer, Trung Tran, Ulrich Wisser and Sharon Wodjenski. 1623 6. Change History 1625 6.1. Change from 00 to 01 1627 1. Changed to use camel case for the XML elements. 1628 2. Replaced "cancelled" status to "rejected" status. 1629 3. Added the child elements of the element. 1630 4. Removed the XML schema and replaced with "[TBD]". 1632 6.2. Change from 01 to 02 1634 1. Added support for both the ICANN and ARI/Neustar TMCH models. 1635 2. Changed the namespace URI and prefix to use "launch" instead of 1636 "launchphase". 1637 3. Added definition of multiple claim validation models. 1638 4. Added the and 1639 elements. 1640 5. Added support for Claims Info Command 1642 6.3. Change from 02 to 03 1644 1. Removed XSI namespace per Keith Gaughan's suggestion on the 1645 provreg list. 1646 2. Added extensibility to the launch:status element and added the 1647 pendingAuction status per Trung Tran's feedback on the provreg 1648 list. 1649 3. Added support for the Claims Check Command, updated the location 1650 and contents of the signedNotice, and replaced most references of 1651 Claim to Mark based on the work being done on the ARI/Neustar 1652 launch model. 1654 6.4. Change from 03 to 04 1656 1. Removed references to the ICANN model. 1657 2. Removed support for the Claims Info Command. 1658 3. Removed use of the signedClaim. 1659 4. Revised the method for referring to the signedClaim from the XML 1660 Signature using the IDREF URI. 1661 5. Split the launch-1.0.xsd into three XML schemas including launch- 1662 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 1663 6. Split the "claims" launch phase to the "claims1" and "claims2" 1664 launch phases. 1665 7. Added support for the encodedSignedMark with base64 encoded 1666 signedMark. 1667 8. Changed the elements in the createNoticeType to include the 1668 noticeID, timestamp, and the source elements. 1669 9. Added the class and effectiveDate elements to mark. 1671 6.5. Change from 04 to 05 1673 1. Removed reference to in the example. 1674 2. Incorporated feedback from Bernhard Reutner-Fischer on the 1675 provreg mail list. 1676 3. Added missing launch XML prefix to applicationIDType reference in 1677 the idContainerType of the Launch Schema. 1678 4. Added missing description of the element in the element. 1680 5. Updated note on replication of the EPP contact mapping elements 1681 in the Mark Contact section. 1683 6.6. Change from 05 to 06 1685 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 1686 replaced with reference to draft-lozano-smd, that contains the 1687 definition for the mark, signed marked, and encoded signed mark. 1689 2. Split the into and 1690 based on feedback from Trung Tran. 1691 3. Added the "includeMark" optional attribute to the 1692 element to enable the client to request whether or not to include 1693 the mark in the info response. 1694 4. Fixed state diagram to remove redundant transition from "invalid" 1695 to "rejected"; thanks Klaus Malorny. 1697 6.7. Change from 06 to 07 1699 1. Proof-read grammar and spelling. 1700 2. Changed "pendingAuction" status to "pendingAllocation", changed 1701 "pending" to "pendingValidation" status, per proposal from Trung 1702 Tran and seconded by Rubens Kuhl. 1703 3. Added text related to the use of RFC 5731 pendingCreate to the 1704 Application Identifier section. 1705 4. Added the Poll Messaging section to define the use of poll 1706 messaging for intermediate state transitions and pending action 1707 poll messaging for final state transitions. 1709 6.8. Change from 07 to 08 1711 1. Added support for use of the launch statuses and poll messaging 1712 for Launch Registrations based on feedback from Sharon Wodjenski 1713 and Trung Tran. 1714 2. Incorporated changes based on updates or clarifications in 1715 draft-lozano-tmch-func-spec-01, which include: 1716 1. Removed the unused element. 1717 2. Removed the element. 1718 3. Added the element based on the required 1719 element. 1721 7. IANA Considerations 1723 This document uses URNs to describe XML namespaces and XML schemas 1724 conforming to a registry mechanism described in [RFC3688]. Three URI 1725 assignments have been registered by the IANA. 1727 Registration request for the Launch namespace: 1729 URI: urn:ietf:params:xml:ns:launch-1.0 1730 Registrant Contact: See the "Author's Address" section of this 1731 document. 1732 XML: None. Namespace URIs do not represent an XML specification. 1734 8. Security Considerations 1736 The mapping extensions described in this document do not provide any 1737 security services beyond those described by EPP [RFC5730], the EPP 1738 domain name mapping [RFC5731], and protocol layers used by EPP. The 1739 security considerations described in these other specifications apply 1740 to this specification as well. 1742 Updates to, and deletion of an application object must be restricted 1743 to clients authorized to perform the said operation on the object. 1745 As information contained within an application, or even the mere fact 1746 that an application exists may be confidential. Any attempt to 1747 operate on an application object by an unauthorized client MUST be 1748 rejected with an EPP 2303 (object does not exist) or an appropriate 1749 auhorization error. Server policy may allow operation with 1750 filtered output by clients other than the sponsoring client, in which 1751 case the and response SHOULD be 1752 filtered to include only fields that are publicly accessible. 1754 9. Normative References 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, March 1997. 1759 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1760 January 2004. 1762 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1763 STD 69, RFC 5730, August 2009. 1765 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1766 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1768 [draft-lozano-smd] 1769 Lozano, G., "Mark and Signed Mark Objects Mapping". 1771 [1] 1773 Authors' Addresses 1775 Wil Tan 1776 Cloud Registry 1777 Suite 32 Seabridge House 1778 377 Kent St 1779 Sydney, NSW 2000 1780 AU 1782 Phone: +61 414 710899 1783 Email: wil@cloudregistry.net 1784 URI: http://www.cloudregistry.net 1786 Gavin Brown 1787 CentralNic Ltd 1788 35-39 Mooregate 1789 London, England EC2R 6AR 1790 GB 1792 Phone: +44 20 33 88 0600 1793 Email: gavin.brown@centralnic.com 1794 URI: https://www.centralnic.com 1796 James Gould 1797 VeriSign, Inc. 1798 12061 Bluemont Way 1799 Reston, VA 20190 1800 US 1802 Email: jgould@verisign.com 1803 URI: http://www.verisigninc.com