idnits 2.17.1 draft-tan-epp-launchphase-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2013) is 4062 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-06 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 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 Identifiers . . . . . . . . . . . . . . . . . 4 57 2.2. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3.1. State Transition . . . . . . . . . . . . . . . . . . . 6 60 2.4. Mark Validation Models . . . . . . . . . . . . . . . . . . 7 61 2.4.1. element . . . . . . . . . . . . . . 7 62 2.5. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.6. Digital Signature . . . . . . . . . . . . . . . . . . . . 8 64 2.6.1. element . . . . . . . . . . . . . . . 8 65 2.6.2. element . . . . . . . . . . . 8 66 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 9 68 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 13 69 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 17 70 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 17 71 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 23 72 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 25 73 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 27 74 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 28 75 3.7. EPP Command . . . . . . . . . . . . . . . . . . 28 76 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 77 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 29 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 79 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 35 80 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 35 81 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 35 82 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 36 83 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 36 84 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 36 85 6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . . 36 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 88 9. Normative References . . . . . . . . . . . . . . . . . . . . . 37 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 91 1. Introduction 93 This document describes an extension mapping for version 1.0 of the 94 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 95 specifies a flexible schema that can be used to implement several 96 common use cases related to the provisioning and management of launch 97 phase extension in a domain name registry. 99 It is typical for domain registries to operate in special modes 100 within certain periods of time to facilitate allocation of domain 101 names. This document uses the term "launch phase" and the shorter 102 form "launch" to refer to such a period. 104 The EPP domain name mapping [RFC5731] is designed for the steady 105 state operation of a registry. During the launch, the interface used 106 at each phase of the launch could be different from what is defined 107 in EPP domain name mapping [RFC5731]. for example, registries 108 typically accept multiple applications for a given domain name during 109 the "sunrise" launch phase, referred to as a launch application. A 110 launch registration is used to refer to a registration made during a 111 launch phase when the server uses a first-come-first-serve model. 112 Even in a first-come-first-serve model additional steps and 113 information might be required to support a launch phase, like the 114 passing of trademark information on a create. In addition, the 115 Proposed Trademark Claims Model [1] defines a registry interface for 116 the Trademark Claims or "claims" launch phase that includes support 117 for presenting a Trademark Claims Notice to the Registrant. This 118 document proposes an extension to the domain name extension in order 119 to unambiguously manage the various launch phases known. 121 1.1. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 XML is case sensitive. Unless stated otherwise, XML specifications 128 and examples provided in this document MUST be interpreted in the 129 character case presented in order to develop a conforming 130 implementation. 132 "launch-1.0" is used as an abbreviation for 133 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 134 "launch" is used, but implementations MUST NOT depend on it and 135 instead employ a proper namespace-aware XML parser and serializer to 136 interpret and output the XML documents. 138 "signedMark-1.0" is used as an abbreviation for 139 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 140 [draft-lozano-smd]. The XML namespace prefix "smd" is used, but 141 implementations MUST NOT depend on it and instead employ a proper 142 namespace-aware XML parser and serializer to interpret and output the 143 XML documents. 145 "mark-1.0" is used as an abbreviation for 146 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 147 [draft-lozano-smd]. The XML namespace prefix "mark" is used, but 148 implementations MUST NOT depend on it and instead employ a proper 149 namespace-aware XML parser and serializer to interpret and output the 150 XML documents. 152 2. Object Attributes 154 This extension adds additional elements to the EPP domain name 155 mapping [RFC5731]. Only those new elements are described here. 157 2.1. Application Identifiers 159 Servers MAY allow multiple applications, referred to as a launch 160 application, of a given domain name during its launch phase 161 operations. Upon receiving a request to create a domain name, the 162 server creates an application object corresponding to the request and 163 assigns an application identifier for the application and returns it 164 to the client with the element. In order to 165 facilitate correlation, all subsequent launch operations on the 166 application object MUST be qualified by the previously assigned 167 application identifier using the element. 169 2.2. Launch Phases 171 The server MAY support multiple launch phases sequentially or 172 simultaneously. The element MUST be included by the 173 client to define the target launch phase of the command. 175 The following launch phase values are defined: 176 sunrise Phase when trademark holders can submit registrations or 177 applications with trademark information that can be validated by 178 the server. 179 landrush Post sunrise phase when non-trademark holders are allowed 180 to register domain names with steps taken to address a large 181 volume of initial registrations. 183 claims1 Trademark claims phase 1 as defined by Trademark 184 Clearinghouse model of displaying a full, detailed claims notice 185 to clients for domain names that match trademarks. 186 claims2 Trademark claims phase 2 as defined by Trademark 187 Clearinghouse model of displaying a short, educational claims 188 notice to clients for domain names that match trademarks that opt 189 into the service. 190 open Post launch phase that is also referred to as "steady state". 191 Servers MAY require additional trademark protection with this 192 phase. 193 custom A custom server launch phase that is defined using the "name" 194 attribute. 196 For extensibility the element includes an OPTIONAL 197 "name" attribute that can define a sub-phase or the full name of the 198 phase when the element has the "custom" value. For 199 example, the "claims1" launch phase could have two sub-phases that 200 include "landrush" and "open". 202 2.3. Status Values 204 A launch application object MAY have a status value. The element is used to convey extended status pertaining to the 206 application object, beyond what is specified in the object mapping 207 for this application object. 209 The following status values are defined using the required "s" 210 attribute: 211 pending: The initial state of a newly-created application object. 212 validated: The application meets relevant registry rules. 213 invalid: The application does not validate according to registry 214 rules. 215 pendingAuction: The application is pending based on results of an 216 auction. 217 allocated: One of two possible end states of an application object; 218 the object corresponding to the application has been provisioned. 219 rejected: The other possible end state; the object was not 220 provisioned. 221 custom: A custom status that is defined using the "name" attribute. 223 Each status value MAY be accompanied by a string of human-readable 224 text that describes the rationale for the status applied to the 225 object. The OPTIONAL "lang" attribute MAY be present to identify the 226 language if the negotiated value is something other than the default 227 value of "en" (English). 229 For extensibility the element includes an OPTIONAL 230 "name" attribute that can define a sub-status or the full name of the 231 status when the status value is "custom". The server SHOULD NOT use 232 the "custom" status value. 234 Certain status values MAY be combined. For example, an application 235 can be invalid and rejected. Additionally certain statuses MAY be 236 skipped. For example, an application MAY immediately start at the 237 allocated status or an application MAY skip the pendingAuction status 238 if the server does not support an auction. If a 239 processes a request synchronously without the use of an intermediate 240 application, than an Application Identifier (Section 2.1) is not 241 needed along with the application status. 243 2.3.1. State Transition 245 | request 246 v 247 +---------+ 248 | pending | 249 +----+----+ 250 | 251 | 252 +--------------+-----+-----------+--------------+ 253 | | | | 254 v v v v 255 +-----------+ +---------+ +-------+ +-------+ 256 | | | | / \ / \ 257 | validated | | invalid +----->| rejected | | allocated | 258 | | | | \ / \ / 259 +----+------+ +----+----+ +-------+ +-------+ 260 | ^ ^ 261 | | | 262 | | | 263 | | | 264 +---------------------------------+ | 265 | | | 266 | | | 267 | +--------+-------+ | 268 | | | | 269 +----------------------->| pendingAuction +------+ 270 | | 271 +----------------+ 273 Figure 1 275 2.4. Mark Validation Models 277 A server MUST support at least one of the following models for 278 validating the trademark information: 280 code Use of a mark code by itself to validate that the mark matches 281 the domain name. This model is supported using the element with just the element. 283 mark The mark information is passed without any other validation 284 element. The server will use some custom form of validation to 285 validate that the mark information is authentic. This model is 286 supported using the element with just the (Section 2.5) element. 288 code with mark: A code is used along with the mark information by 289 the server to validate the mark utilizing an external party. The 290 code represents some form of secret that matches the mark 291 information passed. This model is supported using the element that contains both the and the 293 (Section 2.5) elements. 294 signed mark: The mark information is digitally signed as described 295 in the Digital Signature (Section 2.6) section. The digital 296 signature can be directly validated by the server using the public 297 key of the external party that created the signed mark using it's 298 private key. This model is supported using the 299 (Section 2.6.1) and (Section 2.6.2) 300 elements. 302 More than one , (Section 2.6.1), or 303 (Section 2.6.2) element MAY be specified. 304 The maximum number of marks per domain name is up to server policy. 306 2.4.1. element 308 The element that is used by the "code", "mark", and 309 "code with mark" validation models, has the following child elements: 311 : OPTIONAL mark code used to validate the 312 (Section 2.5) information. The mark code can be a mark specific 313 secret value that the server can verify against a third party. 314 : OPTIONAL mark information with child elements defined 315 in the Mark (Section 2.5) section. 317 The following is an example element with both a 318 and (Section 2.5) element. 320 321 49FD46E6C4B45C55D4AC 322 323 ... 324 325 327 2.5. Mark 329 A element describes an applicant's prior right to a given 330 domain name that is used with the "mark", "mark with code", and the 331 "signed mark" validation models. The element is defined 332 in [draft-lozano-smd]. A new mark format can be supported by 333 creating a new XML schema for the mark that has an element that 334 substitutes for the element from 335 [draft-lozano-smd]. 337 2.6. Digital Signature 339 Digital signatures MAY be used by the server to validate either the 340 mark information, when using the "signed mark" validation model with 341 the (Section 2.6.1) element or the (Section 2.6.2) element. 344 2.6.1. element 346 The element contains the digitally signed mark 347 information. The element is defined in 348 [draft-lozano-smd]. A new signed mark format can be supported by 349 creating a new XML schema for the signed mark that has an element 350 that substitutes for the element from 351 [draft-lozano-smd]. 353 2.6.2. element 355 The element contains an encoded form of the 356 digitally signed (Section 2.6.1) element. The element is defined in [draft-lozano-smd]. A new 358 encoded signed mark format can be supported by creating a new XML 359 schema for the encoded signed mark that has an element that 360 substitutes for the element from 361 [draft-lozano-smd]. 363 3. EPP Command Mapping 365 A detailed description of the EPP syntax and semantics can be found 366 in the EPP core protocol specification [RFC5730]. The command 367 mappings described here are specifically for use in the Launch Phase 368 Extension. 370 This mapping is designed to be flexible, requiring only a minimum set 371 of required elements. 373 While it is meant to serve several use cases, it does not prescribe 374 any interpretation by the client or server. Such processing is 375 typically highly policy-dependent and therefore specific to 376 implementations. 378 Operations on application objects are done via one or more of the 379 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 380 Registries may choose to support a subset of the operations. 382 3.1. EPP Command 384 This extension defines additional elements to extend the EPP 385 command and response to be used in conjunction with the EPP domain 386 name mapping [RFC5731]. 388 This extension defines a new command called the Claims Check Command 389 that is used to determine whether or not there are any matching 390 trademarks, in the specified launch phase, for each domain name 391 passed in the command. The availability check information defined in 392 the EPP domain name mapping [RFC5731] MUST NOT be returned for the 393 Claims Check Command. Instead of returning whether the domain name 394 is available the Claims Check Command will return whether or not at 395 least one matching trademark exists for the domain name. If there is 396 at least one matching trademark that exists for the domain name a 397 element is returned. The value of the element can be used with an info service of a third party 399 trademark provider like the Trademark Clearinghouse (TMCH) for 400 getting the information needed to generate the trademark claims 401 notice. The third party trademark provider should also return a 402 unique notice identifier that can be passed in the 403 element of the extension to the Create Command (Section 3.3). The 404 elements in the EPP command of EPP domain name 405 mapping [RFC5731] define the domain names to check for matching 406 trademarks. The element contains the following child 407 elements: 409 The phase with the value of "claims1" or "claims2" to 410 indicate it as a Claims Check Command. The "claims1" Claims 411 Check Command will match the against the full list 412 of trademark labels and the "claims2" Claims Check Command will 413 match the against the list of trademark labels that 414 opted into the "claims2" launch phase. 416 Example Claims Check Command using the domain command and the 417 extension to determine if "example1.tld" and 418 "example2.tld" have any matching trademarks during the "claims1" 419 launch phase. 421 422 423 424 425 427 example1.tld 428 example2.tld 429 430 431 432 434 claims1 435 436 437 ABC-12345 438 439 440 Example Claims Check Command using the domain command and the 441 extension to determine if "example3.tld" and 442 "example4.tld" have any matching trademarks that opted into the 443 "claims2" launch phase. 445 446 447 448 449 451 example3.tld 452 example4.tld 453 454 455 456 458 claims2 459 460 461 ABC-12345 462 463 465 If the command has been processed successfully, the EPP 466 element MUST contains a child element that 467 identifies the launch namespace. The element 468 contains the following child elements: 470 The phase with a value of "claims1" or "claims2" that 471 matches the associated Claims Check Command . 472 One or more elements that contain the 473 following child elements: 475 Contains the fully qualified name of the queried 476 domain name. This element MUST contain an "exists" attribute 477 whose value indicates if a matching trademark exists for the 478 domain name. A value of "1" or "true" means that a matching 479 trademark does exist for the claims launch phase. A value of 480 "0" or "false" means that a matching trademark does not 481 exist. 482 An OPTIONAL claim key that MAY be passed to an 483 info service of a third party trademark provider like the 484 Trademark Clearinghouse (TMCH) for getting the information 485 needed to generate the trademark claims notice. The is used as the key for the query in place of the 487 domain name to securely query the service without using a 488 well-known value like a domain name. 490 Example Claims Check Response when no matching trademarks are found 491 for the domain name example1.tld and matching trademarks are found 492 for the domain name example2.tld for the "claims1" launch phase. 494 495 496 497 498 Command completed successfully 499 500 501 503 claims1 504 505 example1.tld 506 507 508 example2.tld 509 abc123 510 511 512 513 514 ABC-12345 515 54321-XYZ 516 517 518 519 Example Claims Check Response when no matching trademarks are found 520 for the domain name example3.tld and matching trademarks are found 521 for the domain name example4.tld for the "claims2" launch phase. 523 524 525 526 527 Command completed successfully 528 529 530 532 claims2 533 534 example3.tld 535 536 537 example4.tld 538 abc123 539 540 541 542 543 ABC-12345 544 54321-XYZ 545 546 547 549 3.2. EPP Command 551 This extension defines additional elements to extend the EPP 552 command and response to be used in conjunction with the EPP domain 553 name mapping [RFC5731]. 555 The EPP command is used to retrieve information for a launch 556 phase registration or application. The Application Identifier 557 (Section 2.1) returned in the element of the Create 558 Response (Section 3.3) is used for retrieving information for a 559 launch application. A element is sent along with the 560 regular domain command. The element includes an 561 OPTIONAL "includeMark" boolean attribute, with a default value of 562 "false", to indicate whether or not to include the mark in the 563 response. The element contains the following child 564 elements: 566 The phase during which the application or 567 registration was submitted or is associated with. Server policy 568 defines the phases that are supported. 569 OPTIONAL application identifier of the launch 570 application. 572 Example domain command with the extension to 573 retrieve information for the sunrise application for example.tld and 574 application identifier "abc123". 576 577 578 579 580 582 example.tld 583 584 585 586 589 sunrise 590 abc123 591 592 593 ABC-12345 594 595 596 Example domain command with the extension to 597 retrieve information for the sunrise registration for example.tld. 599 600 601 602 603 605 example.tld 606 607 608 609 611 sunrise 612 613 614 ABC-12345 615 616 618 If the query was successful, the server replies with a element along with the regular EPP . The contains the following child elements: 622 The phase during which the application was submitted 623 or is associated with that matches the associated command 624 . 625 OPTIONAL application identifier of the launch 626 application. 627 OPTIONAL status of the launch application using one 628 of the supported status values (Section 2.3). 629 Zero or more (Section 2.5) elements. 631 Example domain response using the extension 632 with the mark information. 634 635 636 637 638 Command completed successfully 639 640 641 643 example.tld 644 EXAMPLE1-REP 645 646 jd1234 647 sh8013 648 sh8013 649 ClientX 650 ClientY 651 2012-04-03T22:00:00.0Z 652 653 2fooBAR 654 655 656 657 658 660 sunrise 661 abc123 662 663 665 ... 666 667 668 669 670 ABC-12345 671 54321-XYZ 672 673 674 676 3.3. EPP Command 678 There are two forms of the extension to the EPP command that 679 are dependent on the supported launch phases (Section 2.2) as defined 680 below: 682 sunrise The EPP command with the "sunrise" launch phase is 683 used to submit a registration with trademark information that can 684 be verified by the server with the value. The 685 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 686 launch phase. Optionally, the server can support multiple 687 overlapping applications that are chosen asynchronously with a 688 server generated Application Identifier (Section 2.1) for later 689 reference. 690 landrush The EPP command with the "landrush" launch phase 691 is undefined but the form supported is up to server policy. 692 claims1 The EPP command with the "claims1" launch phase is 693 used to pass the information associated with the presentation and 694 acceptance of the "claims1" claims notice. The Claims Create Form 695 (Section 3.3.2) is used for the "claims1" launch phase. 696 claims2 The EPP command with the "claims2" launch phase is 697 used to pass the information associated with the presentation of 698 the "claims1" claims notice. The Claims Create Form 699 (Section 3.3.2) is used for the "claims2" launch phase. 700 open The EPP command with the "open" launch phase is 701 undefined but the form supported is up to server policy. 702 custom The EPP command with the "custom" launch phase is 703 undefined but the form supported is up to server policy. 705 3.3.1. Sunrise Create Form 707 The Sunrise Create Form of the extension to the EPP domain name 708 mapping [RFC5731] includes the verifiable trademark information that 709 the server uses to match against the domain name to authorize the 710 domain create. A server MUST support one of four models in Claim 711 Validation Models (Section 2.4) to verify the trademark information 712 passed by the client. 714 A element is sent along with the regular 715 domain command. The element contains the following 716 child elements: 718 The launch phase for the create like the "sunrise" 719 launch phase. 721 or or 722 Zero or more elements. The 723 child elements are defined in the element (Section 2.4.1) section. 725 Zero or more elements. The 726 child elements are defined in the element (Section 2.6.1) section. 728 Zero or more 729 elements. The child elements are 730 defined in the element 731 (Section 2.6.2) section. 733 Following is an example domain command using the extension, following the "code" validation model, with 735 multiple sunrise codes. 737 738 739 740 741 743 example.tld 744 jd1234 745 sh8013 746 sh8013 747 748 2fooBAR 749 750 751 752 753 755 sunrise 756 757 49FD46E6C4B45C55D4AC 758 759 760 49FD46E6C4B45C55D4AD 761 762 763 49FD46E6C4B45C55D4AE 764 765 766 767 ABC-12345 768 770 772 Following is an example domain command using the extension, following the "mark" validation model, with the 774 mark information. 776 777 778 779 780 782 exampleone.tld 783 jd1234 784 sh8013 785 sh8013 786 787 2fooBAR 788 789 790 791 792 794 sunrise 795 796 798 ... 799 800 801 802 803 ABC-12345 804 805 806 Following is an example domain command using the extension, following the "code with mark" validation model, 808 with a code and mark information. 810 811 812 813 814 816 example.tld 817 jd1234 818 sh8013 819 sh8013 820 821 2fooBAR 822 823 824 825 826 828 sunrise 829 830 49FD46E6C4B45C55D4AC 831 833 ... 834 835 836 837 838 ABC-12345 839 840 841 Following is an example domain command using the extension, following the "signed mark" validation model, with 843 the signed mark information. 845 846 847 848 849 851 exampleone.tld 852 jd1234 853 sh8013 854 sh8013 855 856 2fooBAR 857 858 859 860 861 863 sunrise 864 866 ... 867 868 869 870 ABC-12345 871 872 873 Following is an example domain command using the extension, following the "signed mark" validation model, with 875 the base64 encoded signed mark information. 877 878 879 880 881 883 exampleone.tld 884 jd1234 885 sh8013 886 sh8013 887 888 2fooBAR 889 890 891 892 893 895 sunrise 896 898 ... 899 900 901 902 ABC-12345 903 904 906 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 908 server generated Application Identifier (Section 2.1) when multiple 909 applications of a given domain name is supported; otherwise no 910 extension is included with the regular EPP . The element contains the following child elements: 913 The phase of the application that mirrors the 914 element included in the . 915 The application identifier of the 916 application. 918 An example response when multiple overlapping applications are 919 supported by the server. 921 922 923 924 925 Command completed successfully; action pending 926 927 928 930 example.tld 931 2010-08-10T15:38:26.623854Z 932 2012-08-10T15:38:26.623854Z 933 934 935 936 938 sunrise 939 2393-9323-E08C-03B1 940 941 942 943 944 ABC-12345 945 54321-XYZ 946 947 948 950 3.3.2. Claims Create Form 952 The Claims Create Form of the extension to the EPP domain name 953 mapping [RFC5731] includes the information related to the acceptance 954 of the claims notice for the "claims1" launch phase and the display 955 of the claims notice for the "claims2" launch phase. 957 A element is sent along with the regular 958 domain command. The element contains the following 959 child elements: 961 MUST contain the value of "claims1" or "claim2" to 962 indicate the claims launch phase. 964 965 Unique notice identifier generated by the 966 source of the claims notice information like the Claims 967 Notice Information Service (CNIS). 968 Contains the date and time that the 969 claims notice was generated. 970 Contains the date and time that the claims 971 notice was displayed or accepted. 972 Contains the source information of the client 973 that was displayed or that accepted the claims notice like 974 the client IP address. 976 Following is an example domain command using the extension with the information for the 978 "claims1" claims launch phase. 980 981 982 983 984 986 example.tld 987 jd1234 988 sh8013 989 sh8013 990 991 2fooBAR 992 993 994 995 996 998 claims1 999 1000 49FD46E6C4B45C55D4AC 1001 2012-06-19T09:00:10.0Z 1002 1003 2012-06-19T09:01:30.0Z 1004 1005 192.0.2.29 1006 1007 1008 1009 ABC-12345 1010 1011 1012 This extension does not define any extension to the response of a 1013 domain command for the Claims Create Form. After processing 1014 the command, the server replies with a standard EPP response as 1015 defined in the EPP domain name mapping [RFC5731]. 1017 3.4. EPP Command 1019 This extension defines additional elements to extend the EPP 1020 command to be used in conjunction with the domain name mapping. 1022 A server that does not support multiple applications of a given 1023 domain name with an Application Identifier (Section 2.1) during its 1024 launch phase operations MUST return an EPP error result code of 2102. 1026 Registry policies permitting, clients may update an application 1027 object by submitting an EPP command along with a element to indicate the application object to be updated. 1029 The element contains the following child elements: 1031 The phase during which the application was submitted 1032 or is associated with. 1033 The application identifier for which the 1034 client wishes to update. 1036 This extension does not define any extension to the response of an 1037 domain command. After processing the command, the server 1038 replies with a standard EPP response as defined in the EPP domain 1039 name mapping [RFC5731]. 1041 Following is an example domain command with the extension to add and remove a name server of a sunrise 1043 application with the application identifier "abc123". 1045 1046 1047 1048 1049 1051 example.tld 1052 1053 1054 ns2.example.tld 1055 1056 1057 1058 1059 ns1.example.tld 1060 1061 1062 1063 1064 1065 1067 sunrise 1068 abc123 1069 1070 1071 ABC-12345 1072 1073 1074 An example response that corresponds to the above command. 1076 1077 1078 1079 1080 Command completed successfully 1081 1082 1083 ABC-12345 1084 54321-XYZ 1085 1086 1087 1089 3.5. EPP Command 1091 This extension defines additional elements to extend the EPP 1092 command to be used in conjunction with the domain name mapping. 1094 A server that does not support multiple applications of a given 1095 domain name with an Application Identifier (Section 2.1) during its 1096 launch phase operations MUST return an EPP error result code of 2102. 1098 Registry policies permitting, clients MAY withdraw an application by 1099 submitting an EPP command along with a 1100 element to indicate the application object to be deleted. The 1101 element contains the following child elements: 1103 The phase during which the application was submitted 1104 or is associated with. 1105 The application identifier for which the 1106 client wishes to delete. 1108 This extension does not define any extension to the response of a 1109 domain command. After processing the command, the server 1110 replies with a standard EPP response as defined in the EPP domain 1111 name mapping [RFC5731]. 1113 Following is an example domain command with the extension. 1116 1117 1118 1119 1120 1122 example.tld 1123 1124 1125 1126 1128 sunrise 1129 abc123 1130 1131 1132 ABC-12345 1133 1134 1136 An example response that corresponds to the above command. 1138 1139 1140 1141 1142 Command completed successfully 1143 1144 1145 ABC-12345 1146 54321-XYZ 1147 1148 1149 1151 3.6. EPP Command 1153 This extension does not define any extension to the EPP 1154 command or response described in the EPP domain name mapping 1155 [RFC5731]. 1157 3.7. EPP Command 1159 This extension does not define any extension to the EPP 1160 command or response described in the EPP domain name mapping 1162 [RFC5731]. 1164 4. Formal Syntax 1166 One schema is presented here that is the EPP Launch Phase Mapping 1167 schema. 1169 The formal syntax presented here is a complete schema representation 1170 of the object mapping suitable for automated validation of EPP XML 1171 instances. The BEGIN and END tags are not part of the schema; they 1172 are used to note the beginning and ending of the schema for URI 1173 registration purposes. 1175 4.1. Launch Schema 1177 Copyright (c) 2012 IETF Trust and the persons identified as authors 1178 of the code. All rights reserved. 1180 Redistribution and use in source and binary forms, with or without 1181 modification, are permitted provided that the following conditions 1182 are met: 1184 o Redistributions of source code must retain the above copyright 1185 notice, this list of conditions and the following disclaimer. 1186 o Redistributions in binary form must reproduce the above copyright 1187 notice, this list of conditions and the following disclaimer in 1188 the documentation and/or other materials provided with the 1189 distribution. 1190 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1191 names of specific contributors, may be used to endorse or promote 1192 products derived from this software without specific prior written 1193 permission. 1195 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1196 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1197 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1198 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1199 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1200 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1201 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1202 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1203 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1204 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1205 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1207 BEGIN 1208 1209 1218 1221 1224 1227 1230 1231 1232 Extensible Provisioning Protocol v1.0 1233 domain name extension schema 1234 for the launch phase processing. 1235 1236 1238 1241 1242 1243 1244 1245 1247 1250 1251 1252 1253 1254 1255 1256 1259 1260 1261 1263 1269 1270 1271 1272 1273 1274 1275 1277 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1291 1294 1295 1296 1297 1298 1300 1303 1304 1305 1306 1307 1309 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1324 1327 1328 1329 1330 1332 1334 1335 1336 1337 1339 1343 1344 1345 1347 1349 1350 1351 1354 1355 1356 1357 1358 1360 1362 1364 1366 1367 1368 1370 1373 1374 1375 1376 1377 1378 1379 1380 1382 1385 1386 1387 1388 1389 1391 1394 1395 1396 1397 1400 1401 1403 1405 1408 1409 1410 1412 1415 1416 1417 1418 1420 1421 1423 1424 1425 1426 1428 1429 1431 1432 1433 1434 1436 1437 1438 1440 1443 1444 1445 1446 1449 1451 1453 1454 1456 1457 END 1459 5. Acknowledgements 1461 The authors wish to acknowledge the efforts of the leading 1462 participants of the Community TMCH Model that led to many of the 1463 changes to this document, which include Chris Wright, Jeff Neuman, 1464 Jeff Eckhaus, and Will Shorter. 1466 Special suggestions that have been incorporated into this document 1467 were provided by Jothan Frakes, Keith Gaughan, Jan Jansen, Gustavo 1468 Lozano, Klaus Malorny, Patrick Mevzek, Bernhard Reutner-Fischer, 1469 Trung Tran, Ulrich Wisser and Sharon Wodjenski. 1471 6. Change History 1473 6.1. Change from 00 to 01 1475 1. Changed to use camel case for the XML elements. 1476 2. Replaced "cancelled" status to "rejected" status. 1477 3. Added the child elements of the element. 1478 4. Removed the XML schema and replaced with "[TBD]". 1480 6.2. Change from 01 to 02 1482 1. Added support for both the ICANN and ARI/Neustar TMCH models. 1483 2. Changed the namespace URI and prefix to use "launch" instead of 1484 "launchphase". 1485 3. Added definition of multiple claim validation models. 1486 4. Added the and 1487 elements. 1488 5. Added support for Claims Info Command 1490 6.3. Change from 02 to 03 1492 1. Removed XSI namespace per Keith Gaughan's suggestion on the 1493 provreg list. 1494 2. Added extensibility to the launch:status element and added the 1495 pendingAuction status per Trung Tran's feedback on the provreg 1496 list. 1497 3. Added support for the Claims Check Command, updated the location 1498 and contents of the signedNotice, and replaced most references of 1499 Claim to Mark based on the work being done on the ARI/Neustar 1500 launch model. 1502 6.4. Change from 03 to 04 1504 1. Removed references to the ICANN model. 1505 2. Removed support for the Claims Info Command. 1506 3. Removed use of the signedClaim. 1507 4. Revised the method for referring to the signedClaim from the XML 1508 Signature using the IDREF URI. 1509 5. Split the launch-1.0.xsd into three XML schemas including launch- 1510 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 1511 6. Split the "claims" launch phase to the "claims1" and "claims2" 1512 launch phases. 1513 7. Added support for the encodedSignedMark with base64 encoded 1514 signedMark. 1515 8. Changed the elements in the createNoticeType to include the 1516 noticeID, timestamp, and the source elements. 1517 9. Added the class and effectiveDate elements to mark. 1519 6.5. Change from 04 to 05 1521 1. Removed reference to in the example. 1522 2. Incorporated feedback from Bernhard Reutner-Fischer on the 1523 provreg mail list. 1524 3. Added missing launch XML prefix to applicationIDType reference in 1525 the idContainerType of the Launch Schema. 1526 4. Added missing description of the element in the element. 1528 5. Updated note on replication of the EPP contact mapping elements 1529 in the Mark Contact section. 1531 6.6. Change from 05 to 06 1533 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 1534 replaced with reference to draft-lozano-smd, that contains the 1535 definition for the mark, signed marked, and encoded signed mark. 1537 2. Split the into and 1538 based on feedback from Trung Tran. 1539 3. Added the "includeMark" optional attribute to the 1540 element to enable the client to request whether or not to include 1541 the mark in the info response. 1542 4. Fixed state diagram to remove redundant transition from "invalid" 1543 to "rejected"; thanks Klaus Malorny. 1545 7. IANA Considerations 1547 This document uses URNs to describe XML namespaces and XML schemas 1548 conforming to a registry mechanism described in [RFC3688]. Three URI 1549 assignments have been registered by the IANA. 1551 Registration request for the Launch namespace: 1553 URI: urn:ietf:params:xml:ns:launch-1.0 1554 Registrant Contact: See the "Author's Address" section of this 1555 document. 1556 XML: None. Namespace URIs do not represent an XML specification. 1558 8. Security Considerations 1560 The mapping extensions described in this document do not provide any 1561 security services beyond those described by EPP [RFC5730], the EPP 1562 domain name mapping [RFC5731], and protocol layers used by EPP. The 1563 security considerations described in these other specifications apply 1564 to this specification as well. 1566 Updates to, and deletion of an application object must be restricted 1567 to clients authorized to perform the said operation on the object. 1569 As information contained within an application, or even the mere fact 1570 that an application exists may be confidential. Any attempt to 1571 operate on an application object by an unauthorized client MUST be 1572 rejected with an EPP 2303 (object does not exist) or an appropriate 1573 auhorization error. Server policy may allow operation with 1574 filtered output by clients other than the sponsoring client, in which 1575 case the and response SHOULD be 1576 filtered to include only fields that are publicly accessible. 1578 9. Normative References 1580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1581 Requirement Levels", BCP 14, RFC 2119, March 1997. 1583 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1584 January 2004. 1586 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1587 STD 69, RFC 5730, August 2009. 1589 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1590 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1592 [draft-lozano-smd] 1593 Lozano, G., "Mark and Signed Mark Objects Mapping". 1595 [1] 1598 Authors' Addresses 1600 Wil Tan 1601 Cloud Registry 1602 Suite 32 Seabridge House 1603 377 Kent St 1604 Sydney, NSW 2000 1605 AU 1607 Phone: +61 414 710899 1608 Email: wil@cloudregistry.net 1609 URI: http://www.cloudregistry.net 1611 Gavin Brown 1612 CentralNic Ltd 1613 35-39 Mooregate 1614 London, England EC2R 6AR 1615 GB 1617 Phone: +44 8700 170 900 1618 Email: gavin.brown@centralnic.com 1619 URI: http://www.centralnic.com 1620 James Gould 1621 VeriSign, Inc. 1622 12061 Bluemont Way 1623 Reston, VA 20190 1624 US 1626 Email: jgould@verisign.com 1627 URI: http://www.verisigninc.com