idnits 2.17.1 draft-tan-epp-launchphase-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 10, 2012) is 4270 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' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: February 11, 2013 CentralNic Ltd 6 J. Gould 7 VeriSign, Inc. 8 August 10, 2012 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-tan-epp-launchphase-02 13 Abstract 15 This document describes an Extensible Provisioning Protocol (EPP) 16 extension mapping for the provisioning and management of domain names 17 during the launch phase 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 February 11, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Application Identifiers . . . . . . . . . . . . . . . . . 4 57 2.2. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3.1. State Transition . . . . . . . . . . . . . . . . . . . 5 60 2.4. Claim Validation Models . . . . . . . . . . . . . . . . . 6 61 2.4.1. element . . . . . . . . . . . . . . 6 62 2.5. Claim . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.6. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.7. Digital Signature . . . . . . . . . . . . . . . . . . . . 9 65 2.7.1. element . . . . . . . . . . . . . 9 66 2.7.2. element . . . . . . . . . . . . 11 67 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12 68 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 13 69 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 13 70 3.2.1. Sunrise Info Form . . . . . . . . . . . . . . . . . . 13 71 3.2.2. Claims Info Form . . . . . . . . . . . . . . . . . . . 20 72 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 24 73 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 25 74 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 31 75 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 34 76 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 36 77 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 37 78 3.7. EPP Command . . . . . . . . . . . . . . . . . . 38 79 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 38 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 83 8. Normative References . . . . . . . . . . . . . . . . . . . . . 47 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 86 1. Introduction 88 This document describes an extension mapping for version 1.0 of the 89 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 90 specifies a flexible schema that can be used to implement several 91 common use cases related to the provisioning and management of launch 92 phase extension in a domain name registry. 94 It is typical for domain registries to operate in special modes 95 within certain periods of time to facilitate allocation of domain 96 names for a subset of the zone namespace that becomes available. 97 This document uses the term "launch phase" and the shorter form 98 "launch" to refer to such a period. 100 The EPP domain name mapping [RFC5731] is designed for the steady 101 state operation of a registry. During the launch, the interface used 102 at each phase of the launch could be different from what is defined 103 in EPP domain name mapping [RFC5731]. for example, registries 104 typically accept multiple applications for a given domain name during 105 the "sunrise" launch phase. In addition, the Trademark Clearinghouse 106 Draft Implementation Model [1] defines a registry interface for the 107 Trademark Claims or "claims" launch phase that includes support for 108 presenting a Trademark Claims Notice to the Registrant. This 109 document proposes an extension to the domain name extension in order 110 to unambiguously manage the various launch phases known. 112 1.1. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 XML is case sensitive. Unless stated otherwise, XML specifications 119 and examples provided in this document MUST be interpreted in the 120 character case presented in order to develop a conforming 121 implementation. 123 "launch-1.0" is used as an abbreviation for 124 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 125 "launch" is used, but implementations MUST NOT depend on it and 126 instead employ a proper namespace-aware XML parser and serializer to 127 interpret and output the XML documents. 129 2. Object Attributes 131 This extension adds additional elements to the EPP domain name 132 mapping [RFC5731]. Only those new elements are described here. 134 2.1. Application Identifiers 136 Servers MAY allow multiple applications of a given domain name during 137 its launch phase operations. Upon receiving a request to create a 138 domain name, the server creates an application object corresponding 139 to the request and assigns an application identifier for the 140 application and returns it to the client with the element. In order to facilitate correlation, all 142 subsequent launch operations on the application object MUST be 143 qualified by the previously assigned application identifier using the 144 element. 146 2.2. Launch Phases 148 The server MAY support multiple launch phases sequentially or 149 simultaneously. The element MUST be included by the 150 client to define the target launch phase of the command. 152 The following launch phase values are defined: 153 sunrise Phase when trademark holders can submit registration 154 applications with trademark information that can be validated by 155 the server. 156 landrush Post sunrise phase when non-trademark holders are allowed 157 to register domain names. 158 claims Trademark claims phase as defined by Trademark Clearinghouse 159 Draft Implementation Model [1]. 160 open Post launch phase that is also referred to as "steady state". 161 Servers MAY require additional trademark protection with this 162 phase. 163 custom A custom server launch phase that is defined using the "name" 164 attribute. 166 For extensibility the element includes an OPTIONAL 167 "name" attribute that can define a sub-phase or the full name of the 168 phase when the element has the "custom" value. 170 2.3. Status Values 172 A launch application object MAY have a status value. The 173 element is used to convey extended status pertaining to the 174 application object, beyond what is specified in the object mapping 175 for this application object. 177 The following status values are defined: 179 pending: the initial state of a newly-created application object. 180 validated: the application meets relevant registry rules. 181 invalid: the application does not validate according to registry 182 rules 183 allocated: one of two possible end states of an application object; 184 the object corresponding to the application has been provisioned 185 rejected: the other possible end state; the object was not 186 provisioned 188 Certain status values MAY be combined. For example, an application 189 can be invalid and rejected. Additionally certain statuses MAY be 190 skipped. For example, an application can immediately start at the 191 allocated status. If a processes a request 192 synchronously without the use of an intermediate application, than an 193 Application Identifier (Section 2.1) is not needed along with the 194 application status. 196 2.3.1. State Transition 198 | request 199 v 200 +---------+ 201 | pending | 202 +----+----+ 203 | 204 | 205 +--------------+-----+-----------+--------------+ 206 | | | | 207 v v v v 208 +-----------+ +---------+ +-------+ +-------+ 209 | | | | / \ / \ 210 | validated | | invalid +----->| rejected | | allocated | 211 | | | | \ / \ / 212 +----+------+ +----+----+ +-------+ +-------+ 213 | | ^ ^ 214 | | | | 215 | +-----------------+ | 216 | | | 217 +---------------------------------+ | 218 | | 219 +------------------------------------------------+ 221 Figure 1 223 2.4. Claim Validation Models 225 A server MUST support one of four models for validating the trademark 226 claim information: 228 code Use of a claim code by itself to validate that the claim 229 matches the domain name. The code is the "sunrise code" as 230 defined in Trademark Clearinghouse Draft Implementation Model [1] 231 that is validated by the server using its local sunrise code data. 232 This model is supported using the element with 233 just the element. 234 claim The claim information is passed without any other validation 235 element. The server will use some custom form of validation to 236 validate that the claim information is authentic. This model is 237 supported using the element with just the 238 element. 239 code with claim: A code is used along with the claim information by 240 the server to validate the claim utilizing an external party like 241 a Trademark Clearinghouse. The code represents some form of 242 secret that matches the claims information passed. This model is 243 supported using the element with both the 244 and the element. 245 signed claim: The claim information is digitally signed as described 246 in the Digital Signature (Section 2.7) section. The digital 247 signature can be directly validated by the server using the public 248 key of the external party that created the signed claim. This 249 model is supported using the (Section 2.7.1) 250 and (Section 2.7.2) elements. 252 More than one element or more than one element MAY be specified. The maximum number of claims 254 per domain name is up to server policy. 256 2.4.1. element 258 The element that is used by the "code", "claim", 259 and "code with claim" validation models has the following child 260 elements: 262 : OPTIONAL claim code used to validate the information or to directly validate the claim against the 264 domain name. The claim code can be a claim specific secret value 265 that the server can verify against a third party or can be 266 directly combined with the domain name to verify against a server 267 code file. 269 : OPTIONAL claim information with child elements 270 defined in the Claim (Section 2.5) section. 272 The following is an example element with both a 273 and a element. 275 276 49FD46E6C4B45C55D4AC 277 278 Example One 279 example-one 280 exampleone 281 IP Clearinghouse 282 GE 3933232 283 REG-TM-WORD 284 owner 285 2011-09-09 286 2013-09-09 287 AU 288 VIC 289 290 Example Inc. 291 292 293 John Doe 294 Example Inc. 295 296 123 Example Dr. 297 Suite 100 298 Reston 299 VA 300 20190 301 US 302 303 +1.7035555555 304 +1.7035555556 305 jdoe@example.tld 306 307 308 310 2.5. Claim 312 A element describes an applicant's prior right to a 313 given domain name. 315 The child elements of the element include: 317 : an identifier for the claim. This identifier MUST be 318 unique among all claims associated with an application object. 319 : The registered trademark text string. This value is 320 free-form text that MAY be mapped to one or more 321 values. 322 : Zero or more domain name labels that corresponds to 323 the . Each can match directly to the 324 domain name after adding the parent zone. 325 : name of the authority which issued the right 326 (trademark clearinghouse, trademark office, company registration 327 bureau, etc.) 328 : the registration number of the right (trademark 329 number, company registration number, etc.) 330 : indicates the type of claim being made (trademark, 331 symbol, combined mark, company name, etc.) 332 : indicates the applicant's entitlement to the 333 claim (owner, licensee, etc.) 334 : the date of registration of the claim 335 : the date of expiration of the claim 336 : indicates the country in which the claim is valid. 337 This may be a two-character code from [WIPO.ST3] 338 : indicates the name of a city, state, province or 339 other geographic region in which the claim is valid. 340 : Owner information using the Contact (Section 2.6) 341 elements. 342 : Contact for the owner using the Contact 343 (Section 2.6) element. 345 All of the child elements are OPTIONAL. Server policy may place 346 additional constraints on the format and requirements of such 347 elements. 349 2.6. Contact 351 The contact information contained within the Claim (Section 2.5) 352 cannot be defined via a contact identifier as defined in the EPP 353 contact mapping [RFC5733] since it is contact information defined 354 outside of the server. Some of the contact elements defined in EPP 355 contact mapping [RFC5733] are replicated in this extension. 357 The child elements of a contact using either the or 358 elements include: 359 : identifier of contact that MUST be unique among all 360 contacts of the external third party. 362 : name of the individual or role represented by the 363 contact. 364 : name of the organization with which the contact is 365 affiliated. 366 : address information associated with the contact. the 367 element contains the following child elements: 369 one, two, or three elements that 370 contain the contact's street address. 371 contact's city 372 contact's state or province 373 contact's country code 374 : contact's voice telephone number 375 : contact's facsimile telephone number 376 : contact's email address 378 All of the child elements are OPTIONAL. Server policy may place 379 additional constraints on the format and requirements of such 380 elements. 382 2.7. Digital Signature 384 Digital signatures can be used by the server to validate either the 385 claims information, when using the signed claim model with the 386 element, or the claims notice with the element. The digital signatures are handled using an 388 XML Signature [2] around the entire or elements. Once the digital signature is validated 390 using the appropriate public key, the server can trust all of the 391 information included in the or elements. It's up to server policy how the public key 393 is transferred. 395 To have the digital signature cover all of the elements of the 396 and elements, the XML 397 Signature [2] Reference URI is set to "#pointer(..)" and the 398 Transform "http://www.w3.org/2000/09/xmldsig#enveloped-signature" is 399 used. Both of these has the digital signature cover the parent 400 element of the Signature element and to specify that the Signature 401 element is embedded in the parent element. 403 2.7.1. element 405 The child elements of the element include: 407 : Signature serial number that that can be compared 408 with a revocation list by the server. 409 : Zero or more DNS zones the can 410 be used with. No element indicates that the 411 can be used within any DNS zone. 412 : OPTIONAL date and time that the expires. The server MUST NOT accept a that has expired. No element 415 indicates that there is no expiry. 416 : Claim information as defined in the Claim 417 (Section 2.5) section. 418 : XML Signature [2] for the 420 The following is an example using the XML 421 Signature [2] to sign all of the elements of 422 element. 424 425 123456 426 newtld 427 2012-08-16T09:00:00.0Z 428 429 Example One 430 example-one 431 exampleone 432 IP Clearinghouse 433 GE 3933232 434 REG-TM-WORD 435 owner 436 2011-09-09 437 2013-09-09 438 AU 439 VIC 440 441 Example Inc. 442 443 444 John Doe 445 Example Inc. 446 447 123 Example Dr. 448 Suite 100 449 Reston 450 VA 451 20190 452 US 453 454 +1.7035555555 455 +1.7035555556 456 jdoe@example.tld 457 458 459 461 462 465 467 468 469 472 473 476 j6lwx3rvEPO0vKtMup4NbeVu8nk= 477 478 479 480 cID8yqvR60QYQVhOpBDUmPiIxplV/fM7lj9RKF+fswSjJAklUrgf2w== 481 482 483 485 2.7.2. element 487 The child elements of the element include: 489 : Unique notice identifier generated by the third 490 party. The can be compared with a revocation 491 list by the server. 492 : OPTIONAL date and time that the expires. The server MUST NOT accept a that has expired. No element 495 indicates that there is no expiry. 496 : XML Signature [2] for the 497 The following is an example using the XML 498 Signature [2] to sign all of the elements of 499 element. 501 502 49FD46E6C4B45C55D4AC 503 2012-08-16T09:00:00.0Z 504 505 506 509 511 512 513 516 517 519 j6lwx3rvEPO0vKtMup4NbeVu8nk= 520 521 522 523 cID8yqvR60QYQVhOpBDUmPiIxplV/fM7lj9RKF+fswSjJAklUrgf2w== 524 525 526 528 3. EPP Command Mapping 530 A detailed description of the EPP syntax and semantics can be found 531 in the EPP core protocol specification [RFC5730]. The command 532 mappings described here are specifically for use in the Launch Phase 533 Extension. 535 This mapping is designed to be flexible, requiring only a minimum set 536 of required elements. 538 While it is meant to serve several use cases, it does not prescribe 539 any interpretation by the client or server. Such processing is 540 typically highly policy-dependent and therefore specific to 541 implementations. 543 Operations on application objects are done via one or more of the 544 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 545 Registries may choose to support a subset of the operations. 547 3.1. EPP Command 549 This extension does not define any extension to the EPP 550 command or response described in the EPP domain name mapping 551 [RFC5731]. 553 3.2. EPP Command 555 This extension defines additional elements to extend the EPP 556 command and response to be used in conjunction with the EPP domain 557 name mapping [RFC5731]. 559 There are two forms of the extension to the EPP command that 560 are dependent on the supported launch phases (Section 2.2) as defined 561 below: 563 sunrise The EPP command with the "sunrise" phase is used to 564 retrieve information for a specific "sunrise" application based on 565 an Application Identifier (Section 2.1). This form of the EPP 566 extension is referred to as the Sunrise Info Form and is 567 defined in the Sunrise Info Form (Section 3.2.1) section. 568 landrush The EPP command with the "landrush" phase is 569 undefined but the form supported is up to server policy. 570 claims The EPP command with the "claims" phase is used to 571 retrieve the trademark claims information associated with a non- 572 existing domain name that is referred to as the Claims Info 573 Command. The response to the Claims Info Command does not extend 574 the Domain Info Response as defined in EPP domain name mapping 575 [RFC5731]. This form of the EPP extension is referred to 576 as the Claims Info Form and defined in the Claims Info Form 577 (Section 3.2.2) section. 578 open The EPP command with the "open" phase is undefined but 579 the form supported is up to server policy. 580 custom The EPP command with the "custom" phase is undefined 581 but the form supported is up to server policy. 583 3.2.1. Sunrise Info Form 585 The Sunrise Info Form of the extension to the EPP domain name mapping 586 [RFC5731] gets information on an application created with the 587 using the Application Identifier (Section 2.1) 588 returned in the element of the Create Response 589 (Section 3.3). A element is sent along with the 590 regular domain command. The element contains 591 the following child elements: 593 The phase during which the application was submitted 594 or is associated with. Server policy defines what phases that 595 are supported for the Sunrise Info Form. 596 the application identifier of the 597 application. 599 Example domain command with the Sunrise Info Form extension. 602 603 605 606 607 609 example.tld 610 611 612 613 615 sunrise 616 abc123 617 618 619 ABC-12345 620 621 623 If the query was successful, the server replies with an element along with the regular EPP . The contains the following child elements: 627 the phase during which the application was submitted 628 or is associated with. 629 the application identifier of the returned 630 application. 631 status of the application using one of the supported 632 status values (Section 2.3). 633 or 634 zero or more elements. 635 The child elements are defined in the 636 element (Section 2.4.1) section. 638 zero or more elements. 639 The child elements are defined in the 640 element (Section 2.7.1) section. 642 Example domain response using the Sunrise Info Form extension with multiple codes. 645 646 648 649 650 Command completed successfully 651 652 653 655 example.tld 656 EXAMPLE1-REP 657 658 jd1234 659 sh8013 660 sh8013 661 ClientX 662 ClientY 663 2012-04-03T22:00:00.0Z 664 665 2fooBAR 666 667 668 669 670 672 sunrise 673 abc123 674 675 676 49FD46E6C4B45C55D4AC 677 678 679 49FD46E6C4B45C55D4AD 680 681 682 49FD46E6C4B45C55D4AE 683 684 685 686 687 ABC-12345 688 54322-XYZ 689 690 691 693 Example domain response using the Sunrise Info Form extension with code and claim information. 696 697 699 700 701 Command completed successfully 702 703 704 706 exampleone.tld 707 EXAMPLE1-REP 708 709 jd1234 710 sh8013 711 sh8013 712 ClientX 713 ClientY 714 2012-04-03T22:00:00.0Z 715 716 2fooBAR 717 718 719 720 721 723 sunrise 724 abc123 725 726 727 49FD46E6C4B45C55D4AC 728 729 Example One 730 example-one 731 exampleone 732 IP Clearinghouse 733 GE 3933232 734 REG-TM-WORD 735 owner 736 2011-09-09 737 2013-09-09 738 AU 739 VIC 740 741 Example Inc. 742 743 744 John Doe 745 Example Inc. 746 747 123 Example Dr. 748 Suite 100 749 Reston 750 VA 751 20190 752 US 753 754 +1.7035555555 755 +1.7035555556 756 jdoe@example.tld 757 758 759 760 761 762 763 ABC-12345 764 54322-XYZ 765 766 767 769 Example domain response using the Sunrise Info Form extension signed claim information. 772 773 775 776 777 Command completed successfully 778 779 780 782 exampleone.tld 783 EXAMPLE1-REP 784 785 jd1234 786 sh8013 787 sh8013 788 ClientX 789 ClientY 790 2012-04-03T22:00:00.0Z 791 792 2fooBAR 793 794 795 796 797 799 sunrise 800 abc123 801 802 803 123456 804 newtld 805 2012-08-16T09:00:00.0Z 806 807 Example One 808 example-one 809 exampleone 810 IP Clearinghouse 811 GE 3933232 812 REG-TM-WORD 813 owner 814 2011-09-09 815 2013-09-09 816 AU 817 VIC 818 819 Example Inc. 820 821 822 John Doe 823 Example Inc. 824 825 123 Example Dr. 826 Suite 100 827 Reston 828 VA 829 20190 830 US 831 832 +1.7035555555 833 +1.7035555556 834 jdoe@example.tld 835 836 837 839 840 843 845 846 847 850 851 854 j6lwx3rvEPO0vKtMup4NbeVu8nk= 855 856 857 858 cID8yqvR60QYQVhOpBDUmPiIxplV/fM7lj9RKF+fswSjJAklUrgf2w== 859 860 861 862 863 864 865 ABC-12345 866 54322-XYZ 867 868 869 871 3.2.2. Claims Info Form 873 The Claims Info Form of the extension to the EPP domain name mapping 874 [RFC5731] gets trademark claims information for a non-existing domain 875 name that is referred to as a Claims Info Command. The 876 element contains the following child elements: 878 The phase with the value of "claims" to indicate that 879 this is a Claims Info Command. 881 Example Claims Info Command using the domain command and the 882 Claims Info Form extension. 884 885 887 888 889 891 example.tld 892 893 894 895 897 claims 898 899 900 ABC-12345 901 902 904 If the query was successful, the server replies with an element containing the trademark claims information expected 906 to be used by the client to generate the claims notice. The has the following child elements: 909 the phase with a value of "claims". 910 The information used for the trademark claims 911 notice. The element has the following child 912 elements: 914 The domain name that the claim notice information 915 is associated with. 916 OPTIONAL element included if there are no 917 trademark claims associated with the 918 OPTIONAL server generated identifier for the 919 claims notice that is passed in the extension 920 of the Create Command (Section 3.3). This MUST be included 921 if there is at least one trademark claim associated with the 922 element. 923 Zero or more elements containing 924 the trademark claims information as defined in the Claim 925 (Section 2.5) section. 927 Example Claims Info Response when no matching trademark claims are 928 found for the domain name example.tld. 930 931 933 934 935 Command completed successfully 936 937 938 940 claims 941 942 example.tld 943 944 945 946 947 948 ABC-12345 949 54322-XYZ 950 951 952 954 Example Claims Info Response when two matching trademark claims are 955 found for the domain name exampleone.tld. 957 958 960 961 962 Command completed successfully 963 964 965 967 claims 968 969 exampleone.tld 970 49FD46E6C4B45C55D4AC 971 972 Example One 973 example-one 974 exampleone 975 IP Clearinghouse 976 GE 3933232 977 REG-TM-WORD 978 owner 979 2011-09-09 980 2013-09-09 981 AU 982 VIC 983 984 Example Inc. 985 986 987 John Doe 988 Example Inc. 989 990 123 Example Dr. 991 Suite 100 992 Reston 993 VA 994 20190 995 US 996 997 +1.7035555555 998 +1.7035555556 999 jdoe@example.tld 1000 1001 1002 1003 Example Two 1004 example-two 1005 exampletwo 1006 IP Clearinghouse 1007 GE 3933233 1008 REG-TM-WORD 1009 owner 1010 2011-09-09 1011 2013-09-09 1012 AU 1013 VIC 1014 1015 Example Inc. 1016 1017 1018 John Doe 1019 Example Inc. 1020 1021 123 Example Dr. 1022 Suite 100 1023 Reston 1024 VA 1025 20190 1026 US 1027 1028 +1.7035555555 1029 +1.7035555556 1030 jdoe@example.tld 1031 1032 1033 1034 1035 1036 1037 ABC-12345 1038 54322-XYZ 1039 1040 1041 1043 3.3. EPP Command 1045 There are two forms of the extension to the EPP command that 1046 are dependent on the supported launch phases (Section 2.2) as defined 1047 below: 1049 sunrise The EPP command with the "sunrise" phase is used to 1050 submit an application with trademark information that can be 1051 verified by the server with the value. The Sunrise 1052 Create Form (Section 3.3.1) is used for the "sunrise" phase. 1053 Optionally, the server can support multiple overlapping 1054 applications that are chosen asynchronously with a server 1055 generated Application Identifier (Section 2.1) for later 1056 reference. 1057 landrush The EPP command with the "landrush" phase is 1058 undefined but the form supported is up to server policy. 1059 claims The EPP command with the "claims" phase is used to 1060 pass the information that can be used to validate that the claims 1061 notice information was retrieved via the Claims Info Command and 1062 was accepted by the registrant. The Claims Create Form 1063 (Section 3.3.2) is used for the "claims" phase. 1064 open The EPP command with the "open" phase is undefined but 1065 the form supported is up to server policy. 1066 custom The EPP command with the "custom" phase is undefined 1067 but the form supported is up to server policy. 1069 3.3.1. Sunrise Create Form 1071 The Sunrise Create Form of the extension to the EPP domain name 1072 mapping [RFC5731] includes the verifiable trademark information that 1073 the server uses to match against the domain name to authorize the 1074 domain create. A server MUST support one of four models in Claim 1075 Validation Models (Section 2.4) for the verifiable trademark 1076 information passed by the client. 1078 A element is sent along with the regular 1079 domain command. The element contains the following 1080 child elements: 1082 The phase the application is associated with. 1083 or 1084 zero or more elements. 1085 The child elements are defined in the 1086 element (Section 2.4.1) section. 1087 zero or more elements. 1088 The child elements are defined in the 1089 element (Section 2.7.1) section. 1091 Following is an example domain command using the extension with multiple sunrise codes. 1094 1095 1097 1098 1099 1101 example.tld 1102 jd1234 1103 sh8013 1104 sh8013 1105 1106 2fooBAR 1107 1108 1109 1110 1111 1113 sunrise 1114 1115 49FD46E6C4B45C55D4AC 1116 1117 1118 49FD46E6C4B45C55D4AD 1119 1120 1121 49FD46E6C4B45C55D4AE 1122 1123 1124 1125 ABC-12345 1126 1127 1129 Following is an example domain command using the extension with a code and claim information. 1132 1133 1135 1136 1137 1139 exampleone.tld 1140 jd1234 1141 sh8013 1142 sh8013 1143 1144 2fooBAR 1145 1146 1147 1148 1149 1151 sunrise 1152 1153 49FD46E6C4B45C55D4AC 1154 1155 Example One 1156 example-one 1157 exampleone 1158 IP Clearinghouse 1159 GE 3933232 1160 REG-TM-WORD 1161 owner 1162 2011-09-09 1163 2013-09-09 1164 AU 1165 VIC 1166 1167 Example Inc. 1168 1169 1170 John Doe 1171 Example Inc. 1172 1173 123 Example Dr. 1174 Suite 100 1175 Reston 1176 VA 1177 20190 1178 US 1179 1180 +1.7035555555 1181 +1.7035555556 1182 jdoe@example.tld 1183 1184 1185 1186 1188 1189 ABC-12345 1190 1191 1193 Following is an example domain command using the extension with signed claim information. 1196 1197 1201 1202 1203 1207 example.tld 1208 jd1234 1209 sh8013 1210 sh8013 1211 1212 2fooBAR 1213 1214 1215 1216 1217 1221 sunrise 1222 1223 123456 1224 newtld 1225 example-and-example 1226 example 1227 1228 Hello 1229 IP Clearinghouse 1230 GE 3933232 1231 REG-TM-WORD 1232 owner 1233 2011-09-09 1234 2013-09-09 1235 AU 1236 VIC 1237 1238 Example Inc. 1239 1240 1241 John Doe 1242 Example Inc. 1243 1244 123 Example Dr. 1245 Suite 100 1246 Reston 1247 VA 1248 20190 1249 US 1250 1251 +1.7035555555 1252 +1.7035555556 1253 jdoe@example.tld 1254 1255 1256 1257 1258 1261 1263 1264 1265 1268 1269 1272 j6lwx3rvEPO0vKtMup4NbeVu8nk= 1273 1274 1275 1276 cID8yqvR60QYQVhOpBDUmPiIxplV/fM7lj9RKF+fswSjJAklUrgf2w== 1277 1278 1279 1280 1281 1282 ABC-12345 1283 1285 1287 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1289 server generated Application Identifier (Section 2.1) when multiple 1290 applications of a given domain name is supported; otherwise no 1291 extension is included with the regular EPP . The element contains the following child elements: 1294 The phase of the application that mirrors the 1295 element included in the . 1296 the application identifier of the 1297 application. 1299 An example response when multiple overlapping applications are 1300 supported by the server. 1302 1303 1304 1305 1306 Command completed successfully 1307 1308 1309 1311 example.tld 1312 2010-08-10T15:38:26.623854Z 1313 2012-08-10T15:38:26.623854Z 1314 1315 1316 1317 1318 sunrise 1319 2393-9323-E08C-03B1 1320 1321 1322 1323 example:epp:239332 1324 server-8551292e23b 1325 1326 1327 1328 3.3.2. Claims Create Form 1330 The Claims Create Form of the extension to the EPP domain name 1331 mapping [RFC5731] includes the information related to the acceptance 1332 of the claims notice that is based on the contents of the Claims Info 1333 Response defined in the Claims Info Form (Section 3.2.2) section or 1334 is based on a signed notice by a trusted third party like the 1335 Trademark Clearinghouse (TMCH). 1337 A element is sent along with the regular 1338 domain command. The element contains the following 1339 child elements: 1341 Must contain the value of "claims" to indicate it is 1342 the Claims Create Form 1343 or 1344 Reference to claims notice information using a 1345 server generated notice identifier. The 1346 element has the following child elements: 1348 Server generated identifier for the claim 1349 notice information returned in the 1350 element. The server MUST validate the noticeID either 1351 matches the exact claims information returned in the 1352 or the current claims information 1353 associated with the domain name. The method of 1354 validation is up to server policy. If the launchID does 1355 not pass the validation the server MUST return an EPP 1356 error result code of 2202. 1357 Contains the date and time that the 1358 claims notice was accepted. 1359 Contains the client IP address of the 1360 client that accepted the claims notice. 1361 Signed claims notice reference information 1362 generated by a trusted third party like the Trademark 1363 Clearinghouse (TMCH). The child elements of 1364 are defined in the element 1365 (Section 2.7.2) section. 1367 Following is an example domain command using the extension with the trademark claims notice reference 1369 information. 1371 1372 1374 1375 1376 1378 example.tld 1379 jd1234 1380 sh8013 1381 sh8013 1382 1383 2fooBAR 1384 1385 1386 1387 1388 1390 claims 1391 1392 49FD46E6C4B45C55D4AC 1393 2012-06-19T09:00:00.0Z 1394 192.0.2.29 1395 1396 1397 1398 ABC-12345 1399 1400 1402 Following is an example domain command using the extension with the signed notice reference information. 1405 1406 1410 1411 1412 1416 example.tld 1417 jd1234 1418 sh8013 1419 sh8013 1420 1421 2fooBAR 1422 1423 1424 1425 1426 1430 claims 1431 1432 49FD46E6C4B45C55D4AC 1433 1434 1435 1438 1440 1441 1442 1445 1446 1448 j6lwx3rvEPO0vKtMup4NbeVu8nk= 1449 1450 1451 1452 cID8yqvR60QYQVhOpBDUmPiIxplV/fM7lj9RKF+fswSjJAklUrgf2w== 1453 1454 1455 1456 1457 1458 ABC-12345 1459 1460 1461 3.4. EPP Command 1463 This extension defines additional elements to extend the EPP 1464 command to be used in conjunction with the domain name mapping. 1466 A server that does not support allow multiple applications of a given 1467 domain name with a Application Identifier (Section 2.1) during its 1468 launch phase operations MUST return an EPP error result code of 2102. 1470 Registry policies permitting, clients may update an application 1471 object by submitting an EPP command along with an element to indicate the application object to be updated. 1473 The element contains the following child elements: 1475 the phase during which the application was submitted 1476 or is associated with. 1477 the application identifier for which the 1478 client wishes to update. 1480 This extension does not define any extension to the response of an 1481 domain command. After processing the command, the server 1482 replies with a standard EPP response as defined in the EPP domain 1483 mapping. 1485 Following is an example domain command with the extension to add and remove a name server of a sunrise 1487 application with the application identifier "abc123". 1489 1490 1492 1493 1494 1496 example.tld 1497 1498 1499 ns2.example.tld 1500 1501 1502 1503 1504 ns1.example.tld 1505 1506 1507 1508 1509 1510 1512 sunrise 1513 abc123 1514 1515 1516 ABC-12345 1517 1518 1519 An example response that corresponds to the above command. 1521 1522 1523 1524 1525 Command completed successfully 1526 1527 1528 example:epp:239333 1529 server-8551292e23c 1530 1531 1532 1534 3.5. EPP Command 1536 This extension defines additional elements to extend the EPP 1537 command to be used in conjunction with the domain name mapping. 1539 A server that does not support allow multiple applications of a given 1540 domain name with a Application Identifier (Section 2.1) during its 1541 launch phase operations MUST return an EPP error result code of 2102. 1543 Registry policies permitting, clients MAY withdraw an application by 1544 submitting an EPP command along with an 1545 element to indicate the application object to be deleted. The 1546 element contains the following child elements: 1548 the phase during which the application was submitted 1549 or is associated with. 1550 the application identifier for which the 1551 client wishes to delete. 1553 This extension does not define any extension to the response of an 1554 domain command. After processing the command, the server 1555 replies with a standard EPP response as defined in the EPP domain 1556 mapping. 1558 Following is an example domain command with the extension. 1561 1562 1564 1565 1566 1568 example.tld 1569 1570 1571 1572 1574 sunrise 1575 abc123 1576 1577 1578 ABC-12345 1579 1580 1582 An example response that corresponds to the above command. 1584 1585 1586 1587 1588 Command completed successfully 1589 1590 1591 example:epp:239334 1592 server-8551292e23d 1593 1594 1595 1597 3.6. EPP Command 1599 This extension does not define any extension to the EPP 1600 command or response described in the EPP domain name mapping 1601 [RFC5731]. 1603 3.7. EPP Command 1605 This extension does not define any extension to the EPP 1606 command or response described in the EPP domain name mapping 1607 [RFC5731]. 1609 4. Formal Syntax 1611 An EPP object mapping is specified in XML Schema notation. The 1612 formal syntax presented here is a complete schema representation of 1613 the object mapping suitable for automated validation of EPP XML 1614 instances. The BEGIN and END tags are not part of the schema; they 1615 are used to note the beginning and ending of the schema for URI 1616 registration purposes. 1618 Copyright (c) 2012 IETF Trust and the persons identified as authors 1619 of the code. All rights reserved. 1621 Redistribution and use in source and binary forms, with or without 1622 modification, are permitted provided that the following conditions 1623 are met: 1625 o Redistributions of source code must retain the above copyright 1626 notice, this list of conditions and the following disclaimer. 1627 o Redistributions in binary form must reproduce the above copyright 1628 notice, this list of conditions and the following disclaimer in 1629 the documentation and/or other materials provided with the 1630 distribution. 1631 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1632 names of specific contributors, may be used to endorse or promote 1633 products derived from this software without specific prior written 1634 permission. 1636 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1637 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1638 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1639 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1640 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1641 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1642 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1643 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1644 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1645 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1646 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1648 BEGIN 1649 1650 1658 1661 1664 1667 1668 1669 Extensible Provisioning Protocol v1.0 1670 domain name extension schema 1671 for the launch phase processing. 1672 1673 1675 1678 1679 1680 1681 1683 1686 1687 1688 1689 1690 1691 1693 1696 1697 1698 1700 1706 1707 1708 1709 1710 1711 1712 1714 1717 1718 1719 1720 1721 1722 1723 1724 1725 1727 1730 1731 1732 1733 1734 1736 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1750 1751 1752 1753 1754 1756 1759 1760 1761 1762 1764 1765 1766 1768 1769 1770 1771 1772 1773 1775 1776 1777 1778 1779 1780 1782 1783 1784 1785 1786 1787 1788 1789 1790 1792 1794 1795 1796 1797 1799 1801 1802 1803 1805 1806 1807 1808 1810 1812 1813 1814 1815 1817 1818 1819 1821 1823 1824 1826 1829 1830 1831 1832 1833 1836 1839 1841 1843 1844 1845 1847 1850 1851 1852 1853 1854 1855 1856 1858 1859 1860 1861 1863 1864 1865 1867 1870 1871 1872 1873 1876 1877 1879 1882 1884 1886 1887 1888 1889 1890 1891 1893 1896 1897 1900 1903 1904 1905 1908 1909 1910 1912 1915 1916 1917 1918 1919 1920 1921 1923 1926 1927 1928 1929 1931 1932 1933 1934 1936 1937 1938 1940 1941 1942 1943 1944 1945 1947 1948 1949 1951 1952 1954 1956 1957 1958 1960 1961 1962 1964 1966 1968 1970 1972 1974 1975 1977 1980 1981 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2009 2011 2012 END 2014 5. Acknowledgements 2016 [to be filled in] 2018 6. IANA Considerations 2020 This document uses URNs to describe XML namespaces and XML schemas 2021 conforming to a registry mechanism described in [RFC3688]. 2023 Registration request for the extension namespace: 2025 URI: urn:ietf:params:xml:ns:launch-1.0 2027 Registrant Contact: IESG 2028 XML: None. Namespace URIs do not represent an XML specification. 2030 Registration request for the extension XML schema: 2032 URI: urn:ietf:params:xml:schema:launch-1.0 2034 7. Security Considerations 2036 The mapping extensions described in this document do not provide any 2037 security services beyond those described by EPP [RFC5730], the EPP 2038 domain name mapping [RFC5731], and protocol layers used by EPP. The 2039 security considerations described in these other specifications apply 2040 to this specification as well. 2042 Updates to, and deletion of an application object must be restricted 2043 to clients authorized to perform the said operation on the object. 2045 As information contained within an application, or even the mere fact 2046 that an application exists may be confidential. Any attempt to 2047 operate on an application object by an unauthorized client MUST be 2048 rejected with an EPP 2303 (object does not exist) or an appropriate 2049 auhorization error. Server policy may allow operation with 2050 filtered output by clients other than the sponsoring client, in which 2051 case the and response SHOULD be 2052 filtered to include only fields that are publicly accessible. 2054 8. Normative References 2056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2057 Requirement Levels", BCP 14, RFC 2119, March 1997. 2059 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2060 January 2004. 2062 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2063 STD 69, RFC 5730, August 2009. 2065 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2066 Domain Name Mapping", STD 69, RFC 5731, August 2009. 2068 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2069 Contact Mapping", STD 69, RFC 5733, August 2009. 2071 [WIPO.ST3] 2072 WIPO, "Recommended standard on two-letter codes for the 2073 representation of states, other entities and 2074 intergovernmental organizations", March 2007. 2076 [1] 2079 [2] 2081 Authors' Addresses 2083 Wil Tan 2084 Cloud Registry 2085 Suite 32 Seabridge House 2086 377 Kent St 2087 Sydney, NSW 2000 2088 AU 2090 Phone: +61 414 710899 2091 Email: wil@cloudregistry.net 2092 URI: http://www.cloudregistry.net 2094 Gavin Brown 2095 CentralNic Ltd 2096 35-39 Mooregate 2097 London, England EC2R 6AR 2098 GB 2100 Phone: +44 8700 170 900 2101 Email: gavin.brown@centralnic.com 2102 URI: http://www.centralnic.com 2104 James Gould 2105 VeriSign, Inc. 2106 12061 Bluemont Way 2107 Reston, VA 20190 2108 US 2110 Email: jgould@verisign.com 2111 URI: http://www.verisigninc.com