idnits 2.17.1 draft-tan-epp-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 (March 12, 2013) is 4063 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 13, 2013 CentralNic Ltd 6 J. Gould 7 VeriSign, Inc. 8 March 12, 2013 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-tan-epp-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 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 13, 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 . . . . . . . . . . . . . . . . . . 9 62 2.5.1. element . . . . . . . . . . . . . . 10 63 2.6. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 2.7. Digital Signature . . . . . . . . . . . . . . . . . . . . 11 65 2.7.1. element . . . . . . . . . . . . . . . 11 66 2.7.2. element . . . . . . . . . . . 11 67 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 11 68 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 12 69 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 16 70 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 20 71 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 20 72 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 26 73 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 28 74 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 30 75 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 31 76 3.7. EPP Command . . . . . . . . . . . . . . . . . . 31 77 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 32 78 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 32 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 80 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 38 81 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 38 82 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 38 83 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 39 84 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 39 85 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 39 86 6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . . 39 87 6.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . . 40 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 90 9. Normative References . . . . . . . . . . . . . . . . . . . . . 41 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 93 1. Introduction 95 This document describes an extension mapping for version 1.0 of the 96 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 97 specifies a flexible schema that can be used to implement several 98 common use cases related to the provisioning and management of domain 99 name applications during the launch of a domain name registry. 101 It is typical for domain registries to operate in special modes 102 during their initial launch to facilitate allocation of domain names, 103 often according to special rules. This document uses the term 104 "launch phase" and the shorter form "launch" to refer to such a 105 period. 107 The EPP domain name mapping [RFC5731] is designed for the steady- 108 state operation of a registry. During a launch period, the model in 109 place may be different from what is defined in EPP domain name 110 mapping [RFC5731]. For example, registries often accept multiple 111 applications for the same domain name during the "Sunrise" launch 112 phase, referred to as a Launch Application. A Launch Registration 113 refers to a registration made during a launch phase when the server 114 uses a "first-come, first-served" model. Even in a "first-come, 115 first-served" model, additional steps and information might be 116 required to support an application, such as trademark information. 117 In addition, the Proposed Trademark Claims Model [1] defines a 118 registry interface for the Trademark Claims or "claims" launch phase 119 that includes support for presenting a Trademark Claims Notice to the 120 Registrant. This document proposes an extension to the domain name 121 extension in order to unambiguously manage the various launch phases 122 known. 124 1.1. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 XML is case sensitive. Unless stated otherwise, XML specifications 131 and examples provided in this document MUST be interpreted in the 132 character case presented in order to develop a conforming 133 implementation. 135 "launch-1.0" is used as an abbreviation for 136 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 137 "launch" is used, but implementations MUST NOT depend on it and 138 instead employ a proper namespace-aware XML parser and serializer to 139 interpret and output the XML documents. 141 "signedMark-1.0" is used as an abbreviation for 142 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 143 [draft-lozano-smd]. The XML namespace prefix "smd" is used, but 144 implementations MUST NOT depend on it and instead employ a proper 145 namespace-aware XML parser and serializer to interpret and output the 146 XML documents. 148 "mark-1.0" is used as an abbreviation for 149 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 150 [draft-lozano-smd]. The XML namespace prefix "mark" is used, but 151 implementations MUST NOT depend on it and instead employ a proper 152 namespace-aware XML parser and serializer to interpret and output the 153 XML documents. 155 2. Object Attributes 157 This extension adds additional elements to the EPP domain name 158 mapping [RFC5731]. Only those new elements are described here. 160 2.1. Application Identifier 162 Servers MAY allow multiple applications, referred to as a Launch 163 Application, of the same domain name during its launch phase 164 operations. Upon receiving a valid request to create a Launch 165 Application, the server MUST create an application object 166 corresponding to the request, assign an application identifier for 167 the Launch Application, set the [RFC5731] pendingCreate status, and 168 return the application identifier to the client with the element. In order to facilitate correlation, all 170 subsequent launch operations on the Launch Application MUST be 171 qualified by the previously assigned application identifier using the 172 element. 174 2.2. Launch Phases 176 The server MAY support multiple launch phases sequentially or 177 simultaneously. The element MUST be included by the 178 client to define the target launch phase of the command. 180 The following launch phase values are defined: 181 sunrise The phase during which trademark holders can submit 182 registrations or applications with trademark information that can 183 be validated by the server. 185 landrush A post-Sunrise phase when non-trademark holders are allowed 186 to register domain names with steps taken to address a large 187 volume of initial registrations. 188 claims1 The Trademark Claims Phase 1, as defined by Trademark 189 Clearinghouse model, in which a full, detailed Claims Notice must 190 be displayed to prospective registrants of domain names that match 191 trademarks. 192 claims2 The Trademark Claims Phase 2, as defined by Trademark 193 Clearinghouse model, in which a short, educational Claims Notice 194 must be displayed to prospective registrants of domain names that 195 match trademarks that have opted in. 196 open A post-launch phase that is also referred to as "steady state". 197 Servers MAY require additional trademark protection during this 198 phase. 199 custom A custom server launch phase that is defined using the "name" 200 attribute. 202 For extensibility, the element includes an OPTIONAL 203 "name" attribute that can define a sub-phase or the full name of the 204 phase when the element has the "custom" value. For 205 example, the "claims1" launch phase could have two sub-phases that 206 include "landrush" and "open". 208 2.3. Status Values 210 A Launch Application object MAY have a status value. The element is used to convey extended status pertaining to the 212 application object, beyond what is specified in the object mapping 213 for this application object. 215 The following status values are defined using the required "s" 216 attribute: 217 pendingValidation: The initial state of a newly-created application 218 object. The application requires validation, but the validation 219 process has not yet completed. 220 validated: The application meets relevant registry rules. 221 invalid: The application does not validate according to registry 222 rules. 223 pendingAllocation: The allocation of the application is pending 224 based on the results of some out-of-band process (for example, an 225 auction). 226 allocated: One of two possible end states of an application object; 227 the object corresponding to the application has been provisioned. 228 rejected: The other possible end state; the object was not 229 provisioned. 231 custom: A custom status that is defined using the "name" attribute. 233 Each status value MAY be accompanied by a string of human-readable 234 text that describes the rationale for the status applied to the 235 object. The OPTIONAL "lang" attribute MAY be present to identify the 236 language if the negotiated value is something other than the default 237 value of "en" (English). 239 For extensibility the element includes an OPTIONAL 240 "name" attribute that can define a sub-status or the full name of the 241 status when the status value is "custom". The server SHOULD NOT use 242 the "custom" status value. 244 Certain status values MAY be combined. For example, an application 245 may be both invalid and rejected. Additionally, certain statuses MAY 246 be skipped. For example, an application MAY immediately start at the 247 "allocated" status or an application MAY skip the "pendingAllocation" 248 status if the server uses a "first-come, first served" model. If the 249 launch phase does not require validation of a request, an application 250 MAY immediately skip to "pendingAllocation". If the 251 command processes a request synchronously without the use of an 252 intermediate application, then an Application Identifier 253 (Section 2.1) is not needed along with the application status. 255 2.3.1. State Transition 257 | request 258 | 259 v 260 +-------------------+ 261 | | 262 | pendingValidation | 263 | | 264 +---------+---------+ 265 | 266 | 267 +-----------+-----------+ 268 | | 269 | | 270 v v 271 +-----------+ +---------+ 272 | | | | 273 | validated | | invalid | 274 | | | | 275 +-----+-----+ +----+----+ 276 | | 277 | | 278 v | 279 +-------------------+ | 280 | | | 281 | pendingAllocation | | 282 | | | 283 +-------------------+ | 284 | | 285 | | 286 +-----------------------+ 287 | | 288 | | 289 v v 290 +---------+ +--------+ 291 / \ / \ 292 | allocated | | rejected | 293 \ / \ / 294 +---------+ +--------+ 296 Figure 1 298 2.4. Poll Messaging 300 A Launch Application is handled as a domain name of [RFC5731] in 301 "pendingCreate" status, with the Launch Application status values 302 defined in Section 2.3. As a Launch Application transitions between 303 the status values defined in Section 2.3, the server SHOULD insert 304 poll messages, per [RFC5730], for the applicable intermediate 305 statuses, including the "pendingValidation", "validated", 306 "pendingAllocation, and "invalid" statuses, using the element with the extension. The server 308 MUST insert a poll message, per [RFC5731], with the 309 extension for the final statuses, including the 310 "allocated" and "rejected" statuses. 312 The following is an example poll message for a Launch Application 313 that has transitioned to the "pendingAllocation" state. 315 316 317 318 319 Command completed successfully; ack to dequeue 320 321 322 2013-04-04T22:01:00.0Z 323 Application pendingAllocation. 324 325 326 328 example.tld 329 ... 330 331 332 333 335 sunrise 336 abc123 337 338 339 340 341 ABC-12345 342 54322-XYZ 343 344 345 346 The following is an example poll message for an 347 "allocated" Launch Application. 349 350 351 352 353 Command completed successfully; ack to dequeue 354 355 356 2013-04-04T22:01:00.0Z 357 Application successfully allocated. 358 359 360 362 example.tld 363 364 ABC-12345 365 54321-XYZ 366 367 2013-04-04T22:00:00.0Z 368 369 370 371 373 sunrise 374 abc123 375 376 377 378 379 BCD-23456 380 65432-WXY 381 382 383 385 2.5. Mark Validation Models 387 A server MUST support at least one of the following models for 388 validating trademark information: 390 code Use of a mark code by itself to validate that the mark matches 391 the domain name. This model is supported using the element with just the element. 393 mark The mark information is passed without any other validation 394 element. The server will use some custom form of validation to 395 validate that the mark information is authentic. This model is 396 supported using the element with just the (Section 2.6) element. 398 code with mark: A code is used along with the mark information by 399 the server to validate the mark utilizing an external party. The 400 code represents some form of secret that matches the mark 401 information passed. This model is supported using the element that contains both the and the 403 (Section 2.6) elements. 404 signed mark: The mark information is digitally signed as described 405 in the Digital Signature (Section 2.7) section. The digital 406 signature can be directly validated by the server using the public 407 key of the external party that created the signed mark using its 408 private key. This model is supported using the 409 (Section 2.7.1) and (Section 2.7.2) 410 elements. 412 More than one , (Section 2.7.1), or 413 (Section 2.7.2) element MAY be specified. 414 The maximum number of marks per domain name is up to server policy. 416 2.5.1. element 418 The element that is used by the "code", "mark", and 419 "code with mark" validation models, has the following child elements: 421 : OPTIONAL mark code used to validate the 422 (Section 2.6) information. The mark code is be a mark-specific 423 secret that the server can verify against a third party. 424 : OPTIONAL mark information with child elements defined 425 in the Mark (Section 2.6) section. 427 The following is an example element with both a 428 and (Section 2.6) element. 430 431 49FD46E6C4B45C55D4AC 432 433 ... 434 435 437 2.6. Mark 439 A element describes an applicant's prior right to a given 440 domain name that is used with the "mark", "mark with code", and the 441 "signed mark" validation models. The element is defined 442 in [draft-lozano-smd]. A new mark format can be supported by 443 creating a new XML schema for the mark that has an element that 444 substitutes for the element from 445 [draft-lozano-smd]. 447 2.7. Digital Signature 449 Digital signatures MAY be used by the server to validate either the 450 mark information, when using the "signed mark" validation model with 451 the (Section 2.7.1) element or the (Section 2.7.2) element. 454 2.7.1. element 456 The element contains the digitally signed mark 457 information. The element is defined in 458 [draft-lozano-smd]. A new signed mark format can be supported by 459 creating a new XML schema for the signed mark that has an element 460 that substitutes for the element from 461 [draft-lozano-smd]. 463 2.7.2. element 465 The element contains an encoded form of the 466 digitally signed (Section 2.7.1) element. The element is defined in [draft-lozano-smd]. A new 468 encoded signed mark format can be supported by creating a new XML 469 schema for the encoded signed mark that has an element that 470 substitutes for the element from 471 [draft-lozano-smd]. 473 3. EPP Command Mapping 475 A detailed description of the EPP syntax and semantics can be found 476 in the EPP core protocol specification [RFC5730]. The command 477 mappings described here are specifically for use in the Launch Phase 478 Extension. 480 This mapping is designed to be flexible, requiring only a minimum set 481 of required elements. 483 While it is meant to serve several use cases, it does not prescribe 484 any interpretation by the client or server. Such processing is 485 typically highly policy-dependent and therefore specific to 486 implementations. 488 Operations on application objects are done via one or more of the 489 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 490 Registries may choose to support a subset of the operations. 492 3.1. EPP Command 494 This extension defines additional elements to extend the EPP 495 command and response to be used in conjunction with the EPP domain 496 name mapping [RFC5731]. 498 This extension defines a new command called the Claims Check Command 499 that is used to determine whether or not there are any matching 500 trademarks, in the specified launch phase, for each domain name 501 passed in the command. The availability check information defined in 502 the EPP domain name mapping [RFC5731] MUST NOT be returned for the 503 Claims Check Command. 505 Instead of returning whether the domain name is available, the Claims 506 Check Command will return whether or not at least one matching 507 trademark exists for the domain name. If there is at least one 508 matching trademark that exists for the domain name, a element is returned. The client may then use the value of 510 the element to obtain information needed to 511 generate the trademark Claims Notice from a third-party trademark 512 validator such as the Trademark Clearinghouse (TMCH). The third 513 party trademark validator should also return a unique notice 514 identifier that can be passed in the element of the 515 extension to the Create Command (Section 3.3). 517 The elements in the EPP command of EPP domain 518 name mapping [RFC5731] define the domain names to check for matching 519 trademarks. The element contains the following child 520 elements: 522 The launch phase, with a value of either "claims1" or 523 "claims2" to indicate that the command is a Claims Check Command. 524 The "claims1" Claims Check Command will match the 525 against the full list of trademark labels. The "claims2" Claims 526 Check Command will match the against the list of 527 trademark labels that opted into the "claims2" launch phase. 529 Example Claims Check command using the domain command and the 530 extension to determine if "example1.tld" and 531 "example2.tld" have any matching trademarks during the "claims1" 532 launch phase: 534 535 536 537 538 540 example1.tld 541 example2.tld 542 543 544 545 547 claims1 548 549 550 ABC-12345 551 552 554 Example Claims Check Command using the domain command and the 555 extension to determine if "example3.tld" and 556 "example4.tld" have any matching trademarks that opted into the 557 "claims2" launch phase: 559 560 561 562 563 565 example3.tld 566 example4.tld 567 568 569 570 572 claims2 573 574 575 ABC-12345 576 578 580 If the command has been processed successfully, the EPP 581 element MUST contain a child element that 582 identifies the launch namespace. The element 583 contains the following child elements: 585 The launch phase, with a value of either "claims1" or 586 "claims2", which matches the associated Claims Check Command 587 . 588 One or more elements that contain the 589 following child elements: 591 Contains the fully qualified name of the queried 592 domain name. This element MUST contain an "exists" attribute 593 whose value indicates if a matching trademark exists for the 594 domain name. A value of "1" (or "true") means that a 595 matching trademark does exist for the claims launch phase. A 596 value of "0" (or "false") means that a matching trademark 597 does not exist. 598 An OPTIONAL claim key that MAY be passed to a 599 third-party trademark validator such as the Trademark 600 Clearinghouse (TMCH) for querying the information needed to 601 generate a Trademark Claims Notice. The is 602 used as the key for the query in place of the domain name to 603 securely query the service without using a well-known value 604 like a domain name. 606 Example Claims Check response when no matching trademarks are found 607 for the domain name example1.tld and matching trademarks are found 608 for the domain name example2.tld for the "claims1" launch phase: 610 611 612 613 614 Command completed successfully 615 616 617 619 claims1 620 621 example1.tld 622 623 624 example2.tld 625 abc123 626 627 628 629 630 ABC-12345 631 54321-XYZ 632 633 634 635 Example Claims Check response when no matching trademarks are found 636 for the domain name example3.tld and matching trademarks are found 637 for the domain name example4.tld for the "claims2" launch phase: 639 640 641 642 643 Command completed successfully 644 645 646 648 claims2 649 650 example3.tld 651 652 653 example4.tld 654 abc123 655 656 657 658 659 ABC-12345 660 54321-XYZ 661 662 663 665 3.2. EPP Command 667 This extension defines additional elements to extend the EPP 668 command and response to be used in conjunction with the EPP domain 669 name mapping [RFC5731]. 671 The EPP command is used to retrieve information for a launch 672 phase registration or application. The Application Identifier 673 (Section 2.1) returned in the element of the create 674 response (Section 3.3) is used for retrieving information for a 675 Launch Application. A element is sent along with the 676 regular domain command. The element includes an 677 OPTIONAL "includeMark" boolean attribute, with a default value of 678 "false", to indicate whether or not to include the mark in the 679 response. The element contains the following child 680 elements: 682 The phase during which the application or 683 registration was submitted or is associated with. Server policy 684 defines the phases that are supported. 685 OPTIONAL application identifier of the Launch 686 Application. 688 Example domain command with the extension to 689 retrieve information for the sunrise application for example.tld and 690 application identifier "abc123": 692 693 694 695 696 698 example.tld 699 700 701 702 705 sunrise 706 abc123 707 708 709 ABC-12345 710 711 712 Example domain command with the extension to 713 retrieve information for the sunrise registration for example.tld: 715 716 717 718 719 721 example.tld 722 723 724 725 727 sunrise 728 729 730 ABC-12345 731 732 734 If the query was successful, the server replies with a element along with the regular EPP . The contains the following child elements: 738 The phase during which the application was submitted, 739 or is associated with, that matches the associated command 740 . 741 OPTIONAL Application Identifier of the Launch 742 Application. 743 OPTIONAL status of the Launch Application using one 744 of the supported status values (Section 2.3). 745 Zero or more (Section 2.6) elements. 747 Example domain response using the extension 748 with the mark information: 750 751 752 753 754 Command completed successfully 755 756 757 759 example.tld 760 EXAMPLE1-REP 761 762 jd1234 763 sh8013 764 sh8013 765 ClientX 766 ClientY 767 2012-04-03T22:00:00.0Z 768 769 2fooBAR 770 771 772 773 774 776 sunrise 777 abc123 778 779 781 ... 782 783 784 785 786 ABC-12345 787 54321-XYZ 788 789 790 792 3.3. EPP Command 794 There are two forms of the extension to the EPP command that 795 are dependent on the supported launch phases (Section 2.2) as defined 796 below: 798 sunrise The EPP command with the "sunrise" launch phase is 799 used to submit a registration with trademark information that can 800 be verified by the server with the value. The 801 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 802 launch phase. Optionally, the server can support multiple 803 overlapping applications that are chosen asynchronously with a 804 server generated Application Identifier (Section 2.1) for later 805 reference. 806 landrush The EPP command with the "landrush" launch phase 807 is undefined but the form supported is up to server policy. 808 claims1 The EPP command with the "claims1" launch phase is 809 used to pass the information associated with the presentation and 810 acceptance of the "claims1" Claims Notice. The Claims Create Form 811 (Section 3.3.2) is used for the "claims1" launch phase. 812 claims2 The EPP command with the "claims2" launch phase is 813 used to pass the information associated with the presentation of 814 the "claims2" Claims Notice. The Claims Create Form 815 (Section 3.3.2) is used for the "claims2" launch phase. 816 open The EPP command with the "open" launch phase is 817 undefined but the form supported is up to server policy. 818 custom The EPP command with the "custom" launch phase is 819 undefined but the form supported is up to server policy. 821 3.3.1. Sunrise Create Form 823 The Sunrise Create Form of the extension to the EPP domain name 824 mapping [RFC5731] includes the verifiable trademark information that 825 the server uses to match against the domain name to authorize the 826 domain create. A server MUST support one of four models in Claim 827 Validation Models (Section 2.5) to verify the trademark information 828 passed by the client. 830 A element is sent along with the regular 831 domain command. The element contains the following 832 child elements: 834 The identifier for the launch phase. 835 or or 836 Zero or more elements. The 837 child elements are defined in the element (Section 2.5.1) section. 839 Zero or more elements. The 840 child elements are defined in the element (Section 2.7.1) section. 842 Zero or more 843 elements. The child elements are 844 defined in the element 845 (Section 2.7.2) section. 847 The following is an example domain command using the 848 extension, following the "code" validation model, 849 with multiple sunrise codes: 851 852 853 854 855 857 example.tld 858 jd1234 859 sh8013 860 sh8013 861 862 2fooBAR 863 864 865 866 867 869 sunrise 870 871 49FD46E6C4B45C55D4AC 872 873 874 49FD46E6C4B45C55D4AD 875 876 877 49FD46E6C4B45C55D4AE 878 879 880 881 ABC-12345 882 883 884 The following is an example domain command using the 885 extension, following the "mark" validation model, 886 with the mark information: 888 889 890 891 892 894 exampleone.tld 895 jd1234 896 sh8013 897 sh8013 898 899 2fooBAR 900 901 902 903 904 906 sunrise 907 908 910 ... 911 912 913 914 915 ABC-12345 916 917 918 The following is an example domain command using the 919 extension, following the "code with mark" validation 920 model, with a code and mark information: 922 923 924 925 926 928 example.tld 929 jd1234 930 sh8013 931 sh8013 932 933 2fooBAR 934 935 936 937 938 940 sunrise 941 942 49FD46E6C4B45C55D4AC 943 945 ... 946 947 948 949 950 ABC-12345 951 952 953 The following is an example domain command using the 954 extension, following the "signed mark" validation 955 model, with the signed mark information: 957 958 959 960 961 963 exampleone.tld 964 jd1234 965 sh8013 966 sh8013 967 968 2fooBAR 969 970 971 972 973 975 sunrise 976 978 ... 979 980 981 982 ABC-12345 983 984 985 The following is an example domain command using the 986 extension, following the "signed mark" validation 987 model, with the base64 encoded signed mark information: 989 990 991 992 993 995 exampleone.tld 996 jd1234 997 sh8013 998 sh8013 999 1000 2fooBAR 1001 1002 1003 1004 1005 1007 sunrise 1008 1010 ... 1011 1012 1013 1014 ABC-12345 1015 1016 1018 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1020 server generated Application Identifier (Section 2.1), when multiple 1021 applications of a given domain name is supported; otherwise no 1022 extension is included with the regular EPP . The element contains the following child elements: 1025 The phase of the application that mirrors the 1026 element included in the . 1027 The application identifier of the 1028 application. 1030 An example response when multiple overlapping applications are 1031 supported by the server: 1033 1034 1035 1036 1037 Command completed successfully; action pending 1038 1039 1040 1042 example.tld 1043 2010-08-10T15:38:26.623854Z 1044 2012-08-10T15:38:26.623854Z 1045 1046 1047 1048 1050 sunrise 1051 2393-9323-E08C-03B1 1052 1053 1054 1055 1056 ABC-12345 1057 54321-XYZ 1058 1059 1060 1062 3.3.2. Claims Create Form 1064 The Claims Create Form of the extension to the EPP domain name 1065 mapping [RFC5731] includes the information related to the 1066 registrant's acceptance of the Claims Notice for the "claims1" launch 1067 phase and the display of the Claims Notice for the "claims2" launch 1068 phase. 1070 A element is sent along with the regular 1071 domain command. The element contains the following 1072 child elements: 1074 MUST contain the value of "claims1" or "claim2" to 1075 indicate the claims launch phase. 1076 1077 Unique notice identifier generated by the 1078 source of the Claims Notice information such as the Claims 1079 Notice Information Service (CNIS). 1080 Contains the date and time that the 1081 Claims Notice was generated. 1082 Contains the date and time that the Claims 1083 Notice was displayed or accepted. 1084 Contains the source information of the end-user 1085 client that was shown, or that accepted, the Claims Notice, 1086 such the end-user client's IP address. 1088 The following is an example domain command using the 1089 extension with the information for 1090 the "claims1" claims launch phase: 1092 1093 1094 1095 1096 1098 example.tld 1099 jd1234 1100 sh8013 1101 sh8013 1102 1103 2fooBAR 1104 1105 1106 1107 1108 1110 claims1 1111 1112 49FD46E6C4B45C55D4AC 1113 2012-06-19T09:00:10.0Z 1114 1115 2012-06-19T09:01:30.0Z 1116 1117 192.0.2.29 1118 1119 1120 1121 ABC-12345 1122 1123 1125 This extension does not define any extension to the response of a 1126 domain command for the Claims Create Form. After processing 1127 the command, the server replies with a standard EPP response as 1128 defined in the EPP domain name mapping [RFC5731]. 1130 3.4. EPP Command 1132 This extension defines additional elements to extend the EPP 1133 command to be used in conjunction with the domain name mapping. 1135 A server that does not support multiple applications of a given 1136 domain name with an Application Identifier (Section 2.1) during its 1137 launch phase operations MUST return an EPP error result code of 2102. 1139 Registry policies permitting, clients may update an application 1140 object by submitting an EPP command along with a element to indicate the application object to be updated. 1142 The element contains the following child elements: 1144 The phase during which the application was submitted 1145 or is associated with. 1146 The application identifier for which the 1147 client wishes to update. 1149 This extension does not define any extension to the response of an 1150 domain command. After processing the command, the server 1151 replies with a standard EPP response as defined in the EPP domain 1152 name mapping [RFC5731]. 1154 The following is an example domain command with the extension to add and remove a name server of a sunrise 1156 application with the application identifier "abc123": 1158 1159 1160 1161 1162 1164 example.tld 1165 1166 1167 ns2.example.tld 1168 1169 1170 1171 1172 ns1.example.tld 1173 1174 1175 1176 1177 1178 1180 sunrise 1181 abc123 1182 1183 1184 ABC-12345 1185 1186 1187 An example response that corresponds to the above command: 1189 1190 1191 1192 1193 Command completed successfully 1194 1195 1196 ABC-12345 1197 54321-XYZ 1198 1199 1200 1202 3.5. EPP Command 1204 This extension defines additional elements to extend the EPP 1205 command to be used in conjunction with the domain name mapping. 1207 A server that does not support multiple applications of a given 1208 domain name with an Application Identifier (Section 2.1) during its 1209 launch phase operations MUST return an EPP error result code of 2102. 1211 Registry policies permitting, clients MAY withdraw an application by 1212 submitting an EPP command along with a 1213 element to indicate the application object to be deleted. The 1214 element contains the following child elements: 1216 The phase during which the application was submitted 1217 or is associated with. 1218 The application identifier for which the 1219 client wishes to delete. 1221 This extension does not define any extension to the response of a 1222 domain command. After processing the command, the server 1223 replies with a standard EPP response as defined in the EPP domain 1224 name mapping [RFC5731]. 1226 The following is an example domain command with the extension: 1229 1230 1231 1232 1233 1235 example.tld 1236 1237 1238 1239 1241 sunrise 1242 abc123 1243 1244 1245 ABC-12345 1246 1247 1249 An example response that corresponds to the above command: 1251 1252 1253 1254 1255 Command completed successfully 1256 1257 1258 ABC-12345 1259 54321-XYZ 1260 1261 1262 1264 3.6. EPP Command 1266 This extension does not define any extension to the EPP 1267 command or response described in the EPP domain name mapping 1268 [RFC5731]. 1270 3.7. EPP Command 1272 This extension does not define any extension to the EPP 1273 command or response described in the EPP domain name mapping 1275 [RFC5731]. 1277 4. Formal Syntax 1279 One schema is presented here that is the EPP Launch Phase Mapping 1280 schema. 1282 The formal syntax presented here is a complete schema representation 1283 of the object mapping suitable for automated validation of EPP XML 1284 instances. The BEGIN and END tags are not part of the schema; they 1285 are used to note the beginning and ending of the schema for URI 1286 registration purposes. 1288 4.1. Launch Schema 1290 Copyright (c) 2012 IETF Trust and the persons identified as authors 1291 of the code. All rights reserved. 1293 Redistribution and use in source and binary forms, with or without 1294 modification, are permitted provided that the following conditions 1295 are met: 1297 o Redistributions of source code must retain the above copyright 1298 notice, this list of conditions and the following disclaimer. 1299 o Redistributions in binary form must reproduce the above copyright 1300 notice, this list of conditions and the following disclaimer in 1301 the documentation and/or other materials provided with the 1302 distribution. 1303 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1304 names of specific contributors, may be used to endorse or promote 1305 products derived from this software without specific prior written 1306 permission. 1308 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1309 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1310 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1311 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1312 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1313 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1314 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1315 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1316 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1317 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1318 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1320 BEGIN 1321 1322 1331 1334 1337 1340 1343 1344 1345 Extensible Provisioning Protocol v1.0 1346 domain name extension schema 1347 for the launch phase processing. 1348 1349 1351 1354 1355 1356 1357 1358 1360 1363 1364 1365 1366 1367 1368 1369 1372 1373 1374 1376 1382 1383 1384 1385 1386 1387 1388 1390 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1404 1407 1408 1409 1410 1411 1413 1416 1417 1418 1419 1420 1422 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1437 1440 1441 1442 1443 1445 1447 1448 1449 1450 1452 1456 1457 1458 1460 1462 1463 1464 1467 1468 1469 1470 1471 1473 1475 1477 1479 1480 1481 1483 1486 1487 1488 1489 1490 1491 1492 1493 1495 1498 1499 1500 1501 1502 1504 1507 1508 1509 1510 1513 1514 1516 1518 1521 1522 1523 1525 1528 1529 1530 1531 1533 1534 1536 1537 1538 1539 1541 1542 1544 1545 1546 1547 1549 1550 1551 1553 1556 1557 1558 1559 1562 1564 1566 1567 1569 1570 END 1572 5. Acknowledgements 1574 The authors wish to acknowledge the efforts of the leading 1575 participants of the Community TMCH Model that led to many of the 1576 changes to this document, which include Chris Wright, Jeff Neuman, 1577 Jeff Eckhaus, and Will Shorter. 1579 Special suggestions that have been incorporated into this document 1580 were provided by Jothan Frakes, Keith Gaughan, Jan Jansen, Rubens 1581 Kuhl, Gustavo Lozano, Klaus Malorny, Patrick Mevzek, Bernhard 1582 Reutner-Fischer, Trung Tran, Ulrich Wisser and Sharon Wodjenski. 1584 6. Change History 1586 6.1. Change from 00 to 01 1588 1. Changed to use camel case for the XML elements. 1589 2. Replaced "cancelled" status to "rejected" status. 1590 3. Added the child elements of the element. 1591 4. Removed the XML schema and replaced with "[TBD]". 1593 6.2. Change from 01 to 02 1595 1. Added support for both the ICANN and ARI/Neustar TMCH models. 1596 2. Changed the namespace URI and prefix to use "launch" instead of 1597 "launchphase". 1598 3. Added definition of multiple claim validation models. 1599 4. Added the and 1600 elements. 1601 5. Added support for Claims Info Command 1603 6.3. Change from 02 to 03 1605 1. Removed XSI namespace per Keith Gaughan's suggestion on the 1606 provreg list. 1607 2. Added extensibility to the launch:status element and added the 1608 pendingAuction status per Trung Tran's feedback on the provreg 1609 list. 1610 3. Added support for the Claims Check Command, updated the location 1611 and contents of the signedNotice, and replaced most references of 1612 Claim to Mark based on the work being done on the ARI/Neustar 1613 launch model. 1615 6.4. Change from 03 to 04 1617 1. Removed references to the ICANN model. 1618 2. Removed support for the Claims Info Command. 1619 3. Removed use of the signedClaim. 1620 4. Revised the method for referring to the signedClaim from the XML 1621 Signature using the IDREF URI. 1622 5. Split the launch-1.0.xsd into three XML schemas including launch- 1623 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 1624 6. Split the "claims" launch phase to the "claims1" and "claims2" 1625 launch phases. 1626 7. Added support for the encodedSignedMark with base64 encoded 1627 signedMark. 1628 8. Changed the elements in the createNoticeType to include the 1629 noticeID, timestamp, and the source elements. 1630 9. Added the class and effectiveDate elements to mark. 1632 6.5. Change from 04 to 05 1634 1. Removed reference to in the example. 1635 2. Incorporated feedback from Bernhard Reutner-Fischer on the 1636 provreg mail list. 1637 3. Added missing launch XML prefix to applicationIDType reference in 1638 the idContainerType of the Launch Schema. 1639 4. Added missing description of the element in the element. 1641 5. Updated note on replication of the EPP contact mapping elements 1642 in the Mark Contact section. 1644 6.6. Change from 05 to 06 1646 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 1647 replaced with reference to draft-lozano-smd, that contains the 1648 definition for the mark, signed marked, and encoded signed mark. 1650 2. Split the into and 1651 based on feedback from Trung Tran. 1652 3. Added the "includeMark" optional attribute to the 1653 element to enable the client to request whether or not to include 1654 the mark in the info response. 1655 4. Fixed state diagram to remove redundant transition from "invalid" 1656 to "rejected"; thanks Klaus Malorny. 1658 6.7. Change from 06 to 07 1660 1. Proof-read grammar and spelling. 1661 2. Changed "pendingAuction" status to "pendingAllocation", changed 1662 "pending" to "pendingValidation" status, per proposal from Trung 1663 Tran and seconded by Rubens Kuhl. 1664 3. Added text related to the use of RFC 5731 pendingCreate to the 1665 Application Identifier section. 1666 4. Added the Poll Messaging section to define the use of poll 1667 messaging for intermediate state transitions and pending action 1668 poll messaging for final state transitions. 1670 7. IANA Considerations 1672 This document uses URNs to describe XML namespaces and XML schemas 1673 conforming to a registry mechanism described in [RFC3688]. Three URI 1674 assignments have been registered by the IANA. 1676 Registration request for the Launch namespace: 1678 URI: urn:ietf:params:xml:ns:launch-1.0 1679 Registrant Contact: See the "Author's Address" section of this 1680 document. 1681 XML: None. Namespace URIs do not represent an XML specification. 1683 8. Security Considerations 1685 The mapping extensions described in this document do not provide any 1686 security services beyond those described by EPP [RFC5730], the EPP 1687 domain name mapping [RFC5731], and protocol layers used by EPP. The 1688 security considerations described in these other specifications apply 1689 to this specification as well. 1691 Updates to, and deletion of an application object must be restricted 1692 to clients authorized to perform the said operation on the object. 1694 As information contained within an application, or even the mere fact 1695 that an application exists may be confidential. Any attempt to 1696 operate on an application object by an unauthorized client MUST be 1697 rejected with an EPP 2303 (object does not exist) or an appropriate 1698 auhorization error. Server policy may allow operation with 1699 filtered output by clients other than the sponsoring client, in which 1700 case the and response SHOULD be 1701 filtered to include only fields that are publicly accessible. 1703 9. Normative References 1705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1706 Requirement Levels", BCP 14, RFC 2119, March 1997. 1708 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1709 January 2004. 1711 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1712 STD 69, RFC 5730, August 2009. 1714 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1715 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1717 [draft-lozano-smd] 1718 Lozano, G., "Mark and Signed Mark Objects Mapping". 1720 [1] 1723 Authors' Addresses 1725 Wil Tan 1726 Cloud Registry 1727 Suite 32 Seabridge House 1728 377 Kent St 1729 Sydney, NSW 2000 1730 AU 1732 Phone: +61 414 710899 1733 Email: wil@cloudregistry.net 1734 URI: http://www.cloudregistry.net 1735 Gavin Brown 1736 CentralNic Ltd 1737 35-39 Mooregate 1738 London, England EC2R 6AR 1739 GB 1741 Phone: +44 20 33 88 0600 1742 Email: gavin.brown@centralnic.com 1743 URI: https://www.centralnic.com 1745 James Gould 1746 VeriSign, Inc. 1747 12061 Bluemont Way 1748 Reston, VA 20190 1749 US 1751 Email: jgould@verisign.com 1752 URI: http://www.verisigninc.com