idnits 2.17.1 draft-tan-epp-launchphase-10.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 (May 1, 2013) is 4013 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 J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track W. Tan 5 Expires: November 2, 2013 Cloud Registry 6 G. Brown 7 CentralNic Ltd 8 May 1, 2013 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-tan-epp-launchphase-10 13 Abstract 15 This document describes an Extensible Provisioning Protocol (EPP) 16 extension mapping for the provisioning and management of domain name 17 registrations and applications during the launch of a domain name 18 registry. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 2, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 56 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Application Identifier . . . . . . . . . . . . . . . . . . 5 58 2.2. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3.1. State Transition . . . . . . . . . . . . . . . . . . . 8 61 2.4. Poll Messaging . . . . . . . . . . . . . . . . . . . . . . 9 62 2.5. Mark Validation Models . . . . . . . . . . . . . . . . . . 12 63 2.5.1. element . . . . . . . . . . . . . . 13 64 2.5.2. element . . . . . . . . . . . . . . . . . 14 65 2.5.3. Digital Signature . . . . . . . . . . . . . . . . . . 14 66 2.5.3.1. element . . . . . . . . . . . . . 14 67 2.5.3.2. element . . . . . . . . . 14 68 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 14 69 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 15 70 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 15 71 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 17 72 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 18 73 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 22 74 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 22 75 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 28 76 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 30 77 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 31 78 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 32 79 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 33 80 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 35 81 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 36 82 3.7. EPP Command . . . . . . . . . . . . . . . . . . 36 83 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 36 84 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 36 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 86 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 43 87 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 43 88 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 43 89 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 43 90 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 44 91 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 44 92 6.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . . 44 93 6.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . . 44 94 6.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . . 45 95 6.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . . 45 96 6.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . . 46 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 99 9. Normative References . . . . . . . . . . . . . . . . . . . . . 47 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 102 1. Introduction 104 This document describes an extension mapping for version 1.0 of the 105 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 106 specifies a flexible schema that can be used to implement several 107 common use cases related to the provisioning and management of domain 108 name registrations and applications during the launch of a domain 109 name registry. 111 It is typical for domain registries to operate in special modes 112 during their initial launch to facilitate allocation of domain names, 113 often according to special rules. This document uses the term 114 "launch phase" and the shorter form "launch" to refer to such a 115 period. 117 The EPP domain name mapping [RFC5731] is designed for the steady- 118 state operation of a registry. During a launch period, the model in 119 place may be different from what is defined in the EPP domain name 120 mapping [RFC5731]. For example, registries often accept multiple 121 applications for the same domain name during the "Sunrise" launch 122 phase, referred to as a Launch Application. A Launch Registration 123 refers to a registration made during a launch phase when the server 124 uses a "first-come, first-served" model. Even in a "first-come, 125 first-served" model, additional steps and information might be 126 required, such as trademark information. In addition, the TMCH 127 Functional Specification [1] defines a registry interface for the 128 Trademark Claims or "claims" launch phase that includes support for 129 presenting a Trademark Claims Notice to the Registrant. This 130 document proposes an extension to the domain name mapping in order to 131 provide a uniform interface for the management of Launch Applications 132 and Launch Registrations in launch phases. 134 1.1. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 XML is case sensitive. Unless stated otherwise, XML specifications 141 and examples provided in this document MUST be interpreted in the 142 character case presented in order to develop a conforming 143 implementation. 145 In examples, "C:" represents lines sent by a protocol client and "S:" 146 represents lines returned by a protocol server. Indentation and 147 white space in examples are provided only to illustrate element 148 relationships and are not a REQUIRED feature of this protocol. 150 "launch-1.0" is used as an abbreviation for 151 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 152 "launch" is used, but implementations MUST NOT depend on it and 153 instead employ a proper namespace-aware XML parser and serializer to 154 interpret and output the XML documents. 156 "signedMark-1.0" is used as an abbreviation for 157 "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in 158 [draft-lozano-smd]. The XML namespace prefix "smd" is used, but 159 implementations MUST NOT depend on it and instead employ a proper 160 namespace-aware XML parser and serializer to interpret and output the 161 XML documents. 163 "mark-1.0" is used as an abbreviation for 164 "urn:ietf:params:xml:ns:mark-1.0" that is defined in 165 [draft-lozano-smd]. The XML namespace prefix "mark" is used, but 166 implementations MUST NOT depend on it and instead employ a proper 167 namespace-aware XML parser and serializer to interpret and output the 168 XML documents. 170 2. Object Attributes 172 This extension adds additional elements to the EPP domain name 173 mapping [RFC5731]. Only those new elements are described here. 175 2.1. Application Identifier 177 Servers MAY allow multiple applications, referred to as a Launch 178 Application, of the same domain name during its launch phase 179 operations. Upon receiving a valid request to create a Launch 180 Application, the server MUST create an application object 181 corresponding to the request, assign an application identifier for 182 the Launch Application, set the [RFC5731] pendingCreate status, and 183 return the application identifier to the client with the element. In order to facilitate correlation, all 185 subsequent launch operations on the Launch Application MUST be 186 qualified by the previously assigned application identifier using the 187 element. 189 If the command processes a request synchronously 190 without the use of an intermediate Launch Application, then an 191 application identifier MAY not be needed. 193 2.2. Launch Phases 195 The server MAY support multiple launch phases sequentially or 196 simultaneously. The element MUST be included by the 197 client to define the target launch phase of the command. The server 198 SHOULD validate the phase and MAY validate the sub-phase of the 199 element against the active phase and OPTIONAL sub- 200 phase of the server on a create command, and return an EPP error 201 result code of 2306 if there is a mismatch. 203 The following launch phase values are defined: 204 sunrise The phase during which trademark holders can submit 205 registrations or applications with trademark information that can 206 be validated by the server. 207 landrush A post-Sunrise phase when non-trademark holders are allowed 208 to register domain names with steps taken to address a large 209 volume of initial registrations. 210 claims The Trademark Claims phase, as defined in the TMCH Functional 211 Specification [1], in which a Claims Notice must be displayed to a 212 prospective registrant of a domain name that matches trademarks. 213 open A post-launch phase that is also referred to as "steady state". 214 Servers MAY require additional trademark protection during this 215 phase. 216 custom A custom server launch phase that is defined using the "name" 217 attribute. 219 For extensibility, the element includes an OPTIONAL 220 "name" attribute that can define a sub-phase or the full name of the 221 phase when the element has the "custom" value. For 222 example, the "claims" launch phase could have two sub-phases that 223 include "landrush" and "open". 225 Launch phases MAY overlap to support the "claims" launch phase, 226 defined in the TMCH Functional Specification [1], and to support a 227 traditional "landrush" launch phase. The overlap of the "claims" and 228 "landrush" launch phases SHOULD be handled by setting "claims" as the 229 value and setting "landrush" as the sub-phase with the 230 "name" attribute. For example, the element SHOULD be 231 claims. 233 2.3. Status Values 235 A Launch Application or Launch Registration object MAY have a launch 236 status value. The element is used to convey the 237 launch status pertaining to the object, beyond what is specified in 238 the object mapping. A Launch Application or Launch Registration MUST 239 set the [RFC5731] "pendingCreate" status if a launch status is 240 supported and the launch status is not one of the final statuses, 241 including the "allocated" and "rejected" statuses. 243 The following status values are defined using the required "s" 244 attribute: 246 pendingValidation: The initial state of a newly-created application 247 or registration object. The application or registration requires 248 validation, but the validation process has not yet completed. 249 validated: The application or registration meets relevant registry 250 rules. 251 invalid: The application or registration does not validate according 252 to registry rules. Server policies permitting, it may transition 253 back into "pendingValidation" for revalidation, after 254 modifications are made to ostensibly correct attributes that 255 caused the validation failure. 256 pendingAllocation: The allocation of the application or registration 257 is pending based on the results of some out-of-band process (for 258 example, an auction). 259 allocated: The object corresponding to the application or 260 registration has been provisioned. Is a possible end state of an 261 application or registration object. 262 rejected: The application or registration object was not 263 provisioned. Is a possible end state of an application or 264 registration object. 265 custom: A custom status that is defined using the "name" attribute. 267 Each status value MAY be accompanied by a string of human-readable 268 text that describes the rationale for the status applied to the 269 object. The OPTIONAL "lang" attribute MAY be present to identify the 270 language if the negotiated value is something other than the default 271 value of "en" (English). 273 For extensibility the element includes an OPTIONAL 274 "name" attribute that can define a sub-status or the full name of the 275 status when the status value is "custom". The server SHOULD NOT use 276 the "custom" status value. 278 Certain status values MAY be combined. For example, an application 279 or registration may be both "invalid" and "rejected". Additionally, 280 certain statuses MAY be skipped. For example, an application or 281 registration MAY immediately start at the "allocated" status or an 282 application or registration MAY skip the "pendingAllocation" status. 283 If the launch phase does not require validation of a request, an 284 application or registration MAY immediately skip to 285 "pendingAllocation". 287 2.3.1. State Transition 289 | request 290 | 291 | +--------------------------+ 292 | | | 293 v v | 294 +-------------------+ | 295 | | | 296 | pendingValidation +--------------+ | 297 | | | | 298 +---------+---------+ | | 299 | | | 300 | | | 301 v v | 302 +-----------+ +---------+ | 303 | | | | | 304 | validated | | invalid +--+ 305 | | | | 306 +-----+-----+ +----+----+ 307 | | 308 | | 309 v | 310 +-------------------+ | 311 | | | 312 | pendingAllocation +-----------+ | 313 | | | | 314 +---------+---------+ | | 315 | | | 316 | | | 317 | | | 318 | | | 319 | | | 320 v v v 321 +---------+ +--------+ 322 / \ / \ 323 | allocated | | rejected | 324 \ / \ / 325 +---------+ +--------+ 327 Figure 1 329 2.4. Poll Messaging 331 A Launch Application MUST and a Launch Registration MAY be handled as 332 a domain name of [RFC5731] in "pendingCreate" status, with the launch 333 status values defined in Section 2.3. As a Launch Application or 334 Launch Registration transitions between the status values defined in 335 Section 2.3, the server SHOULD insert poll messages, per [RFC5730], 336 for the applicable intermediate statuses, including the 337 "pendingValidation", "validated", "pendingAllocation, and "invalid" 338 statuses, using the element with the extension. The element MAY contain non- 340 mandatory information, like contact and name server information. 341 Also, further extensions that would normally be included in the 342 response of a command, per [RFC5731], MAY be included. 343 For the final statuses, including the "allocated" and "rejected" 344 statuses, the server MUST insert a poll message, per 345 [RFC5731], with the extension. 347 The following is an example poll message for a Launch Application 348 that has transitioned to the "pendingAllocation" state. 350 S: 351 S: 352 S: 353 S: 354 S: Command completed successfully; ack to dequeue 355 S: 356 S: 357 S: 2013-04-04T22:01:00.0Z 358 S: Application pendingAllocation. 359 S: 360 S: 361 S: 363 S: example.tld 364 S: ... 365 S: 366 S: 367 S: 368 S: 370 S: sunrise 371 S: abc123 372 S: 373 S: 374 S: 375 S: 376 S: ABC-12345 377 S: 54322-XYZ 378 S: 379 S: 380 S: 381 The following is an example poll message for an 382 "allocated" Launch Application. 384 S: 385 S: 386 S: 387 S: 388 S: Command completed successfully; ack to dequeue 389 S: 390 S: 391 S: 2013-04-04T22:01:00.0Z 392 S: Application successfully allocated. 393 S: 394 S: 395 S: 397 S: example.tld 398 S: 399 S: ABC-12345 400 S: 54321-XYZ 401 S: 402 S: 2013-04-04T22:00:00.0Z 403 S: 404 S: 405 S: 406 S: 408 S: sunrise 409 S: abc123 410 S: 411 S: 412 S: 413 S: 414 S: BCD-23456 415 S: 65432-WXY 416 S: 417 S: 418 S: 419 The following is an example poll message for an 420 "allocated" Launch Registration. 422 S: 423 S: 424 S: 425 S: 426 S: Command completed successfully; ack to dequeue 427 S: 428 S: 429 S: 2013-04-04T22:01:00.0Z 430 S: Registration successfully allocated. 431 S: 432 S: 433 S: 435 S: example.tld 436 S: 437 S: ABC-12345 438 S: 54321-XYZ 439 S: 440 S: 2013-04-04T22:00:00.0Z 441 S: 442 S: 443 S: 444 S: 446 S: sunrise 447 S: 448 S: 449 S: 450 S: 451 S: BCD-23456 452 S: 65432-WXY 453 S: 454 S: 455 S: 457 2.5. Mark Validation Models 459 A server MUST support at least one of the following models for 460 validating trademark information: 462 code Use of a mark code by itself to validate that the mark matches 463 the domain name. This model is supported using the element with just the element. 466 mark The mark information is passed without any other validation 467 element. The server will use some custom form of validation to 468 validate that the mark information is authentic. This model is 469 supported using the element with just the (Section 2.5.2) element. 471 code with mark: A code is used along with the mark information by 472 the server to validate the mark utilizing an external party. The 473 code represents some form of secret that matches the mark 474 information passed. This model is supported using the element that contains both the and the 476 (Section 2.5.2) elements. 477 signed mark: The mark information is digitally signed as described 478 in the Digital Signature (Section 2.5.3) section. The digital 479 signature can be directly validated by the server using the public 480 key of the external party that created the signed mark using its 481 private key. This model is supported using the 482 (Section 2.5.3.1) and (Section 2.5.3.2) 483 elements. 485 More than one , (Section 2.5.3.1), 486 or (Section 2.5.3.2) element MAY be 487 specified. The maximum number of marks per domain name is up to 488 server policy. 490 2.5.1. element 492 The element that is used by the "code", "mark", and 493 "code with mark" validation models, has the following child elements: 495 : OPTIONAL mark code used to validate the 496 (Section 2.5.2) information. The mark code is be a mark-specific 497 secret that the server can verify against a third party. 498 : OPTIONAL mark information with child elements defined 499 in the Mark (Section 2.5.2) section. 501 The following is an example element with both a 502 and (Section 2.5.2) element. 504 505 49FD46E6C4B45C55D4AC 506 507 ... 508 509 511 2.5.2. element 513 A element describes an applicant's prior right to a given 514 domain name that is used with the "mark", "mark with code", and the 515 "signed mark" validation models. The element is defined 516 in [draft-lozano-smd]. A new mark format can be supported by 517 creating a new XML schema for the mark that has an element that 518 substitutes for the element from 519 [draft-lozano-smd]. 521 2.5.3. Digital Signature 523 Digital signatures MAY be used by the server to validate either the 524 mark information, when using the "signed mark" validation model with 525 the (Section 2.5.3.1) element or the (Section 2.5.3.2) element. 528 2.5.3.1. element 530 The element contains the digitally signed mark 531 information. The element is defined in 532 [draft-lozano-smd]. A new signed mark format can be supported by 533 creating a new XML schema for the signed mark that has an element 534 that substitutes for the element from 535 [draft-lozano-smd]. 537 2.5.3.2. element 539 The element contains an encoded form of the 540 digitally signed (Section 2.5.3.1) element. The 541 element is defined in [draft-lozano-smd]. A 542 new encoded signed mark format can be supported by creating a new XML 543 schema for the encoded signed mark that has an element that 544 substitutes for the element from 545 [draft-lozano-smd]. 547 3. EPP Command Mapping 549 A detailed description of the EPP syntax and semantics can be found 550 in the EPP core protocol specification [RFC5730]. The command 551 mappings described here are specifically for use in the Launch Phase 552 Extension. 554 This mapping is designed to be flexible, requiring only a minimum set 555 of required elements. 557 While it is meant to serve several use cases, it does not prescribe 558 any interpretation by the client or server. Such processing is 559 typically highly policy-dependent and therefore specific to 560 implementations. 562 Operations on application objects are done via one or more of the 563 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 564 Registries MAY choose to support a subset of the operations. 566 3.1. EPP Command 568 There are two forms of the extension to the EPP command: the 569 Claims Check Form (Section 3.1.1) and the Availability Check Form 570 (Section 3.1.2). The element "type" attribute defines 571 the form, with the value of "claims" for the Claims Check Form 572 (Section 3.1.1) and with the value of "avail" for the Availability 573 Check Form (Section 3.1.2). The default value of the "type" 574 attribute is "claims". The forms supported by the server is 575 determined by server policy. The server MUST return an EPP error 576 result code of 2307 if it receives a check form that is not 577 supported. 579 3.1.1. Claims Check Form 581 The Claims Check Form defines a new command called the Claims Check 582 Command that is used to determine whether or not there are any 583 matching trademarks, in the specified launch phase, for each domain 584 name passed in the command. The availability check information 585 defined in the EPP domain name mapping [RFC5731] MUST NOT be returned 586 for the Claims Check Command. This form is the default form and MAY 587 be explicitly identified by setting the "type" 588 attribute to "claims". 590 Instead of returning whether the domain name is available, the Claims 591 Check Command will return whether or not at least one matching 592 trademark exists for the domain name. If there is at least one 593 matching trademark that exists for the domain name, a element is returned. The client may then use the value of 595 the element to obtain information needed to 596 generate the trademark Claims Notice from a third-party trademark 597 validator such as the Trademark Clearinghouse (TMCH). The third 598 party trademark validator should also return a unique notice 599 identifier that can be passed in the element of the 600 extension to the Create Command (Section 3.3). 602 The elements in the EPP command of EPP domain 603 name mapping [RFC5731] define the domain names to check for matching 604 trademarks. The element contains the following child 605 elements: 607 The launch phase that SHOULD be "claims". 609 Example Claims Check command using the domain command and the 610 extension with the "type" explicitly set to "claims", 611 to determine if "example1.tld" and "example2.tld" have any matching 612 trademarks during the "claims" launch phase: 614 C: 615 C: 616 C: 617 C: 618 C: 620 C: example1.tld 621 C: example2.tld 622 C: 623 C: 624 C: 625 C: 628 C: claims 629 C: 630 C: 631 C: ABC-12345 632 C: 633 C: 635 If the command has been processed successfully, the EPP 636 element MUST contain a child element that 637 identifies the launch namespace. The element 638 contains the following child elements: 640 The launch phase that SHOULD be "claims". 641 One or more elements that contain the 642 following child elements: 644 Contains the fully qualified name of the queried 645 domain name. This element MUST contain an "exists" attribute 646 whose value indicates if a matching trademark exists for the 647 domain name. A value of "1" (or "true") means that a 648 matching trademark does exist for the claims launch phase. A 649 value of "0" (or "false") means that a matching trademark 650 does not exist. 652 An OPTIONAL claim key that MAY be passed to a 653 third-party trademark validator such as the Trademark 654 Clearinghouse (TMCH) for querying the information needed to 655 generate a Trademark Claims Notice. The is 656 used as the key for the query in place of the domain name to 657 securely query the service without using a well-known value 658 like a domain name. 660 Example Claims Check response when no matching trademarks are found 661 for the domain name example1.tld and matching trademarks are found 662 for the domain name example2.tld for the "claims" launch phase: 664 S: 665 S: 666 S: 667 S: 668 S: Command completed successfully 669 S: 670 S: 671 S: 673 S: claims 674 S: 675 S: example1.tld 676 S: 677 S: 678 S: example2.tld 679 S: abc123 680 S: 681 S: 682 S: 683 S: 684 S: ABC-12345 685 S: 54321-XYZ 686 S: 687 S: 688 S: 690 3.1.2. Availability Check Form 692 The Availability Check Form defines additional elements to extend the 693 EPP command described in the EPP domain name mapping 694 [RFC5731]. No additional elements are defined for the EPP 695 response. This form MUST be identified by setting the 696 "type" attribute to "avail". 698 The EPP command is used to determine if an object can be 699 provisioned within a repository. Domain names may be made available 700 only in unique launch phases, whilst remaining unavailable for 701 concurrent launch phases. In addition to the elements expressed in 702 the , the command is extended with the 703 element that contains the following child elements: 705 The launch phase to which domain name availability 706 should be determined. 708 Example Availability Check Form command using the domain 709 command and the extension with the "type" set to 710 "avail", to determine the availability of two domain names in the 711 "idn-release" custom launch phase: 713 C: 714 C: 715 C: 716 C: 717 C: 719 C: example1.tld 720 C: example2.tld 721 C: 722 C: 723 C: 724 C: 727 C: custom 728 C: 729 C: 730 C: ABC-12345 731 C: 732 C: 734 The Availability Check Form does not define any extension to the 735 response of an domain command. After processing the command, 736 the server replies with a standard EPP response as defined in the EPP 737 domain name mapping [RFC5731]. 739 3.2. EPP Command 741 This extension defines additional elements to extend the EPP 742 command and response to be used in conjunction with the EPP domain 743 name mapping [RFC5731]. 745 The EPP command is used to retrieve information for a launch 746 phase registration or application. The Application Identifier 747 (Section 2.1) returned in the element of the create 748 response (Section 3.3) is used for retrieving information for a 749 Launch Application. A element is sent along with the 750 regular domain command. The element includes an 751 OPTIONAL "includeMark" boolean attribute, with a default value of 752 "false", to indicate whether or not to include the mark in the 753 response. The element contains the following child 754 elements: 756 The phase during which the application or 757 registration was submitted or is associated with. Server policy 758 defines the phases that are supported. 759 OPTIONAL application identifier of the Launch 760 Application. 762 Example domain command with the extension to 763 retrieve information for the sunrise application for example.tld and 764 application identifier "abc123": 766 C: 767 C: 768 C: 769 C: 770 C: 772 C: example.tld 773 C: 774 C: 775 C: 776 C: 779 C: sunrise 780 C: abc123 781 C: 782 C: 783 C: ABC-12345 784 C: 785 C: 786 Example domain command with the extension to 787 retrieve information for the sunrise registration for example.tld: 789 C: 790 C: 791 C: 792 C: 793 C: 795 C: example.tld 796 C: 797 C: 798 C: 799 C: 801 C: sunrise 802 C: 803 C: 804 C: ABC-12345 805 C: 806 C: 808 If the query was successful, the server replies with a element along with the regular EPP . The contains the following child elements: 812 The phase during which the application was submitted, 813 or is associated with, that matches the associated command 814 . 815 OPTIONAL Application Identifier of the Launch 816 Application. 817 OPTIONAL status of the Launch Application using one 818 of the supported status values (Section 2.3). 819 Zero or more (Section 2.5.2) elements. 821 Example domain response using the extension 822 with the mark information: 824 S: 825 S: 826 S: 827 S: 828 S: Command completed successfully 829 S: 830 S: 831 S: 833 S: example.tld 834 S: EXAMPLE1-REP 835 S: 836 S: jd1234 837 S: sh8013 838 S: sh8013 839 S: ClientX 840 S: ClientY 841 S: 2012-04-03T22:00:00.0Z 842 S: 843 S: 2fooBAR 844 S: 845 S: 846 S: 847 S: 848 S: 850 S: sunrise 851 S: abc123 852 S: 853 S: 855 S: ... 856 S: 857 S: 858 S: 859 S: 860 S: ABC-12345 861 S: 54321-XYZ 862 S: 863 S: 864 S: 866 3.3. EPP Command 868 There are four forms of the extension to the EPP command 869 that include the Sunrise Create Form (Section 3.3.1), the Claims 870 Create Form (Section 3.3.2), the General Create Form (Section 3.3.3), 871 and the Mixed Create Form (Section 3.3.4). The form is dependent on 872 the supported launch phases (Section 2.2) as defined below. 874 sunrise The EPP command with the "sunrise" launch phase is 875 used to submit a registration with trademark information that can 876 be verified by the server with the value. The 877 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 878 launch phase. 879 landrush The EPP command with the "landrush" launch phase 880 MAY use the General Create Form (Section 3.3.3) to explictly 881 specify the phase and optionally define the expected type of 882 object to create. 883 claims The EPP command with the "claims" launch phase is 884 used to pass the information associated with the presentation and 885 acceptance of the Claims Notice. The Claims Create Form 886 (Section 3.3.2) is used and the General Create Form 887 (Section 3.3.3) MAY be used for the "claims" launch phase. 888 open The EPP command with the "open" launch phase is 889 undefined but the form supported is up to server policy. 890 custom The EPP command with the "custom" launch phase is 891 undefined but the form supported is up to server policy. 893 3.3.1. Sunrise Create Form 895 The Sunrise Create Form of the extension to the EPP domain name 896 mapping [RFC5731] includes the verifiable trademark information that 897 the server uses to match against the domain name to authorize the 898 domain create. A server MUST support one of four models in Claim 899 Validation Models (Section 2.5) to verify the trademark information 900 passed by the client. 902 A element is sent along with the regular 903 domain command. The element has an OPTIONAL "type" 904 attribute that defines the expected type of object ("application" or 905 "registration") to create. The server SHOULD validate the "type" 906 attribute, when passed, against the type of object that will be 907 created. The element contains the following child 908 elements: 910 The identifier for the launch phase. 911 or or 912 Zero or more elements. The 913 child elements are defined in the element (Section 2.5.1) section. 915 Zero or more elements. The 916 child elements are defined in the element (Section 2.5.3.1) section. 918 Zero or more 919 elements. The child elements are 920 defined in the element 921 (Section 2.5.3.2) section. 923 The following is an example domain command using the 924 extension, following the "code" validation model, 925 with multiple sunrise codes: 927 C: 928 C: 929 C: 930 C: 931 C: 933 C: example.tld 934 C: jd1234 935 C: sh8013 936 C: sh8013 937 C: 938 C: 2fooBAR 939 C: 940 C: 941 C: 942 C: 943 C: 945 C: sunrise 946 C: 947 C: 49FD46E6C4B45C55D4AC 948 C: 949 C: 950 C: 49FD46E6C4B45C55D4AD 951 C: 952 C: 953 C: 49FD46E6C4B45C55D4AE 954 C: 955 C: 956 C: 957 C: ABC-12345 958 C: 959 C: 960 The following is an example domain command using the 961 extension, following the "mark" validation model, 962 with the mark information: 964 C: 965 C: 966 C: 967 C: 968 C: 970 C: exampleone.tld 971 C: jd1234 972 C: sh8013 973 C: sh8013 974 C: 975 C: 2fooBAR 976 C: 977 C: 978 C: 979 C: 980 C: 982 C: sunrise 983 C: 984 C: 986 C: ... 987 C: 988 C: 989 C: 990 C: 991 C: ABC-12345 992 C: 993 C: 994 The following is an example domain command using the 995 extension, following the "code with mark" validation 996 model, with a code and mark information: 998 C: 999 C: 1000 C: 1001 C: 1002 C: 1004 C: example.tld 1005 C: jd1234 1006 C: sh8013 1007 C: sh8013 1008 C: 1009 C: 2fooBAR 1010 C: 1011 C: 1012 C: 1013 C: 1014 C: 1016 C: sunrise 1017 C: 1018 C: 49FD46E6C4B45C55D4AC 1019 C: 1021 C: ... 1022 C: 1023 C: 1024 C: 1025 C: 1026 C: ABC-12345 1027 C: 1028 C: 1029 The following is an example domain command using the 1030 extension, following the "signed mark" validation 1031 model, with the signed mark information for a sunrise application: 1033 C: 1034 C: 1035 C: 1036 C: 1037 C: 1039 C: exampleone.tld 1040 C: jd1234 1041 C: sh8013 1042 C: sh8013 1043 C: 1044 C: 2fooBAR 1045 C: 1046 C: 1047 C: 1048 C: 1049 C: 1052 C: sunrise 1053 C: 1055 C: ... 1056 C: 1057 C: 1058 C: 1059 C: ABC-12345 1060 C: 1061 C: 1062 The following is an example domain command using the 1063 extension, following the "signed mark" validation 1064 model, with the base64 encoded signed mark information: 1066 C: 1067 C: 1068 C: 1069 C: 1070 C: 1072 C: exampleone.tld 1073 C: jd1234 1074 C: sh8013 1075 C: sh8013 1076 C: 1077 C: 2fooBAR 1078 C: 1079 C: 1080 C: 1081 C: 1082 C: 1084 C: sunrise 1085 C: 1087 C: ... 1088 C: 1089 C: 1090 C: 1091 C: ABC-12345 1092 C: 1093 C: 1095 3.3.2. Claims Create Form 1097 The Claims Create Form of the extension to the EPP domain name 1098 mapping [RFC5731] includes the information related to the 1099 registrant's acceptance of the Claims Notice for the "claims" launch 1100 phase. 1102 A element is sent along with the regular 1103 domain command. The element has an OPTIONAL "type" 1104 attribute that defines the expected type of object ("application" or 1105 "registration") to create. The server SHOULD validate the "type" 1106 attribute, when passed, against the type of object that will be 1107 created. The element contains the following child 1108 elements: 1110 MUST contain the value of "claims" to indicate the 1111 claims launch phase. 1112 1113 Unique notice identifier generated by the 1114 source of the Claims Notice information. 1115 Expiry of the claims notice. 1116 Contains the date and time that the Claims 1117 Notice was accepted. 1119 The following is an example domain command using the 1120 extension with the information for 1121 the "claims" launch phase: 1123 C: 1124 C: 1125 C: 1126 C: 1127 C: 1129 C: example.tld 1130 C: jd1234 1131 C: sh8013 1132 C: sh8013 1133 C: 1134 C: 2fooBAR 1135 C: 1136 C: 1137 C: 1138 C: 1139 C: 1141 C: claims 1142 C: 1143 C: 49FD46E6C4B45C55D4AC 1144 C: 2012-06-19T10:00:10.0Z 1145 C: 1146 C: 2012-06-19T09:01:30.0Z 1147 C: 1148 C: 1149 C: 1150 C: 1151 C: ABC-12345 1152 C: 1153 C: 1155 3.3.3. General Create Form 1157 The General Create Form of the extension to the EPP domain name 1158 mapping [RFC5731] includes the launch phase and optionally the object 1159 type to create. The OPTIONAL "type" attribute defines the expected 1160 type of object ("application" or "registration") to create. The 1161 server SHOULD validate the "type" attribute, when passed, against the 1162 type of object that will be created. 1164 A element is sent along with the regular 1165 domain command. The element contains the following 1166 child elements: 1168 Contains the value of the active launch phase of the 1169 server. The server SHOULD validate the value against the active 1170 server launch phase. 1172 The following is an example domain command using the 1173 extension for a "landrush" launch phase application: 1175 C: 1176 C: 1177 C: 1178 C: 1179 C: 1181 C: example.tld 1182 C: jd1234 1183 C: sh8013 1184 C: sh8013 1185 C: 1186 C: 2fooBAR 1187 C: 1188 C: 1189 C: 1190 C: 1191 C: 1194 C: landrush 1195 C: 1196 C: 1197 C: ABC-12345 1198 C: 1199 C: 1201 3.3.4. Mixed Create Form 1203 The Mixed Create Form supports a mix of the create forms, where for 1204 example the Sunrise Create Form (Section 3.3.1) and the Claims Create 1205 Form (Section 3.3.2) MAY be supported in a single command by 1206 including both the verified trademark information and the information 1207 related to the registrant's acceptance of the Claims Notice. The 1208 server MAY support the Mixed Create Form. The "custom" launch phase 1209 SHOULD be used when using the Mixed Create Form. 1211 The following is an example domain command using the 1212 extension, with using a mix of the Sunrise Create 1213 Form (Section 3.3.1) and the Claims Create Form (Section 3.3.2) by 1214 including both a mark and a notice: 1216 C: 1217 C: 1218 C: 1219 C: 1220 C: 1222 C: exampleone.tld 1223 C: jd1234 1224 C: sh8013 1225 C: sh8013 1226 C: 1227 C: 2fooBAR 1228 C: 1229 C: 1230 C: 1231 C: 1232 C: 1235 C: custom 1236 C: 1237 C: 1239 C: ... 1240 C: 1241 C: 1242 C: 1243 C: 49FD46E6C4B45C55D4AC 1244 C: 2012-06-19T10:00:10.0Z 1245 C: 1246 C: 2012-06-19T09:01:30.0Z 1247 C: 1248 C: 1249 C: 1250 C: 1251 C: ABC-12345 1252 C: 1253 C: 1255 3.3.5. Create Response 1257 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1259 server generated Application Identifier (Section 2.1), when multiple 1260 applications of a given domain name are supported; otherwise no 1261 extension is included with the regular EPP . The element contains the following child elements: 1264 The phase of the application that mirrors the 1265 element included in the . 1266 The application identifier of the 1267 application. 1269 An example response when multiple overlapping applications are 1270 supported by the server: 1272 S: 1273 S: 1274 S: 1275 S: 1276 S: Command completed successfully; action pending 1277 S: 1278 S: 1279 S: 1281 S: example.tld 1282 S: 2010-08-10T15:38:26.623854Z 1283 S: 2012-08-10T15:38:26.623854Z 1284 S: 1285 S: 1286 S: 1287 S: 1289 S: sunrise 1290 S: 2393-9323-E08C-03B1 1291 S: 1292 S: 1293 S: 1294 S: 1295 S: ABC-12345 1296 S: 54321-XYZ 1297 S: 1298 S: 1299 S: 1301 3.4. EPP Command 1303 This extension defines additional elements to extend the EPP 1304 command to be used in conjunction with the domain name mapping. 1306 A server that does not support multiple applications of a given 1307 domain name with an Application Identifier (Section 2.1) during its 1308 launch phase operations MUST return an EPP error result code of 2102. 1310 Registry policies permitting, clients may update an application 1311 object by submitting an EPP command along with a element to indicate the application object to be updated. 1313 The element contains the following child elements: 1315 The phase during which the application was submitted 1316 or is associated with. 1317 The application identifier for which the 1318 client wishes to update. 1320 The following is an example domain command with the extension to add and remove a name server of a sunrise 1322 application with the application identifier "abc123": 1324 C: 1325 C: 1326 C: 1327 C: 1328 C: 1330 C: example.tld 1331 C: 1332 C: 1333 C: ns2.example.tld 1334 C: 1335 C: 1336 C: 1337 C: 1338 C: ns1.example.tld 1339 C: 1340 C: 1341 C: 1342 C: 1343 C: 1344 C: 1346 C: sunrise 1347 C: abc123 1348 C: 1349 C: 1350 C: ABC-12345 1351 C: 1352 C: 1354 This extension does not define any extension to the response of an 1355 domain command. After processing the command, the server 1356 replies with a standard EPP response as defined in the EPP domain 1357 name mapping [RFC5731]. 1359 3.5. EPP Command 1361 This extension defines additional elements to extend the EPP 1362 command to be used in conjunction with the domain name mapping. 1364 A server that does not support multiple applications of a given 1365 domain name with an Application Identifier (Section 2.1) during its 1366 launch phase operations MUST return an EPP error result code of 2102. 1368 Registry policies permitting, clients MAY withdraw an application by 1369 submitting an EPP command along with a 1370 element to indicate the application object to be deleted. The 1371 element contains the following child elements: 1373 The phase during which the application was submitted 1374 or is associated with. 1375 The application identifier for which the 1376 client wishes to delete. 1378 The following is an example domain command with the extension: 1381 C: 1382 C: 1383 C: 1384 C: 1385 C: 1387 C: example.tld 1388 C: 1389 C: 1390 C: 1391 C: 1393 C: sunrise 1394 C: abc123 1395 C: 1396 C: 1397 C: ABC-12345 1398 C: 1399 C: 1401 This extension does not define any extension to the response of a 1402 domain command. After processing the command, the server 1403 replies with a standard EPP response as defined in the EPP domain 1404 name mapping [RFC5731]. 1406 3.6. EPP Command 1408 This extension does not define any extension to the EPP 1409 command or response described in the EPP domain name mapping 1410 [RFC5731]. 1412 3.7. EPP Command 1414 This extension does not define any extension to the EPP 1415 command or response described in the EPP domain name mapping 1416 [RFC5731]. 1418 4. Formal Syntax 1420 One schema is presented here that is the EPP Launch Phase Mapping 1421 schema. 1423 The formal syntax presented here is a complete schema representation 1424 of the object mapping suitable for automated validation of EPP XML 1425 instances. The BEGIN and END tags are not part of the schema; they 1426 are used to note the beginning and ending of the schema for URI 1427 registration purposes. 1429 4.1. Launch Schema 1431 Copyright (c) 2012 IETF Trust and the persons identified as authors 1432 of the code. All rights reserved. 1434 Redistribution and use in source and binary forms, with or without 1435 modification, are permitted provided that the following conditions 1436 are met: 1438 o Redistributions of source code must retain the above copyright 1439 notice, this list of conditions and the following disclaimer. 1440 o Redistributions in binary form must reproduce the above copyright 1441 notice, this list of conditions and the following disclaimer in 1442 the documentation and/or other materials provided with the 1443 distribution. 1444 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1445 names of specific contributors, may be used to endorse or promote 1446 products derived from this software without specific prior written 1447 permission. 1449 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1450 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1451 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1452 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1453 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1454 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1455 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1456 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1457 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1458 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1459 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1461 BEGIN 1462 1463 1472 1475 1478 1481 1484 1485 1486 Extensible Provisioning Protocol v1.0 1487 domain name extension schema 1488 for the launch phase processing. 1489 1490 1492 1495 1496 1497 1498 1499 1501 1504 1505 1506 1507 1508 1509 1511 1514 1515 1516 1518 1524 1525 1526 1527 1528 1529 1530 1532 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1547 1548 1549 1550 1551 1553 1556 1557 1558 1559 1560 1562 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1577 1580 1581 1582 1583 1585 1587 1588 1589 1590 1591 1595 1596 1597 1599 1601 1602 1604 1607 1608 1609 1610 1611 1613 1615 1617 1618 1620 1621 1622 1624 1627 1628 1629 1630 1631 1632 1634 1637 1638 1639 1640 1641 1642 1643 1645 1648 1649 1650 1651 1652 1654 1656 1660 1661 1662 1663 1664 1665 1667 1670 1671 1672 1673 1676 1677 1679 1681 1685 1686 1687 1689 1692 1693 1694 1695 1697 1698 1700 1701 1702 1703 1705 1706 1708 1709 1710 1711 1713 1714 1715 1717 1720 1721 1722 1723 1726 1728 1730 1731 1733 1734 END 1736 5. Acknowledgements 1738 The authors wish to acknowledge the efforts of the leading 1739 participants of the Community TMCH Model that led to many of the 1740 changes to this document, which include Chris Wright, Jeff Neuman, 1741 Jeff Eckhaus, and Will Shorter. 1743 Special suggestions that have been incorporated into this document 1744 were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Jan 1745 Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus Malorny, 1746 Alexander Mayrhofer, Patrick Mevzek, James Mitchell, Bernhard 1747 Reutner-Fischer, Trung Tran, Ulrich Wisser and Sharon Wodjenski. 1749 6. Change History 1751 6.1. Change from 00 to 01 1753 1. Changed to use camel case for the XML elements. 1754 2. Replaced "cancelled" status to "rejected" status. 1755 3. Added the child elements of the element. 1756 4. Removed the XML schema and replaced with "[TBD]". 1758 6.2. Change from 01 to 02 1760 1. Added support for both the ICANN and ARI/Neustar TMCH models. 1761 2. Changed the namespace URI and prefix to use "launch" instead of 1762 "launchphase". 1763 3. Added definition of multiple claim validation models. 1764 4. Added the and 1765 elements. 1766 5. Added support for Claims Info Command 1768 6.3. Change from 02 to 03 1770 1. Removed XSI namespace per Keith Gaughan's suggestion on the 1771 provreg list. 1772 2. Added extensibility to the launch:status element and added the 1773 pendingAuction status per Trung Tran's feedback on the provreg 1774 list. 1775 3. Added support for the Claims Check Command, updated the location 1776 and contents of the signedNotice, and replaced most references of 1777 Claim to Mark based on the work being done on the ARI/Neustar 1778 launch model. 1780 6.4. Change from 03 to 04 1782 1. Removed references to the ICANN model. 1783 2. Removed support for the Claims Info Command. 1784 3. Removed use of the signedClaim. 1785 4. Revised the method for referring to the signedClaim from the XML 1786 Signature using the IDREF URI. 1787 5. Split the launch-1.0.xsd into three XML schemas including launch- 1788 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 1789 6. Split the "claims" launch phase to the "claims1" and "claims2" 1790 launch phases. 1791 7. Added support for the encodedSignedMark with base64 encoded 1792 signedMark. 1793 8. Changed the elements in the createNoticeType to include the 1794 noticeID, timestamp, and the source elements. 1795 9. Added the class and effectiveDate elements to mark. 1797 6.5. Change from 04 to 05 1799 1. Removed reference to in the example. 1800 2. Incorporated feedback from Bernhard Reutner-Fischer on the 1801 provreg mail list. 1802 3. Added missing launch XML prefix to applicationIDType reference in 1803 the idContainerType of the Launch Schema. 1804 4. Added missing description of the element in the element. 1806 5. Updated note on replication of the EPP contact mapping elements 1807 in the Mark Contact section. 1809 6.6. Change from 05 to 06 1811 1. Removed the definition of the mark-1.0 and signedMark-1.0 and 1812 replaced with reference to draft-lozano-smd, that contains the 1813 definition for the mark, signed marked, and encoded signed mark. 1814 2. Split the into and 1815 based on feedback from Trung Tran. 1816 3. Added the "includeMark" optional attribute to the 1817 element to enable the client to request whether or not to include 1818 the mark in the info response. 1819 4. Fixed state diagram to remove redundant transition from "invalid" 1820 to "rejected"; thanks Klaus Malorny. 1822 6.7. Change from 06 to 07 1824 1. Proof-read grammar and spelling. 1825 2. Changed "pendingAuction" status to "pendingAllocation", changed 1826 "pending" to "pendingValidation" status, per proposal from Trung 1827 Tran and seconded by Rubens Kuhl. 1829 3. Added text related to the use of RFC 5731 pendingCreate to the 1830 Application Identifier section. 1831 4. Added the Poll Messaging section to define the use of poll 1832 messaging for intermediate state transitions and pending action 1833 poll messaging for final state transitions. 1835 6.8. Change from 07 to 08 1837 1. Added support for use of the launch statuses and poll messaging 1838 for Launch Registrations based on feedback from Sharon Wodjenski 1839 and Trung Tran. 1840 2. Incorporated changes based on updates or clarifications in 1841 draft-lozano-tmch-func-spec-01, which include: 1842 1. Removed the unused element. 1843 2. Removed the element. 1844 3. Added the element based on the required 1845 element. 1847 6.9. Change from 08 to 09 1849 1. Made element optional in to allow 1850 passing just the in per request 1851 from Ben Levac. 1852 2. Added optional "type" attribute in to enable the 1853 client to explicitly define the desired type of object 1854 (application or registration) to create to all forms of the 1855 create extension. 1856 3. Added text that the server SHOULD validate the 1857 element in the Launch Phases section. 1858 4. Add the "General Create Form" to the create command extension to 1859 support the request from Ben Levac. 1860 5. Updated the text for the Poll Messaging section based on feedback 1861 from Klaus Malorny. 1862 6. Replaced the "claims1" and "claims2" phases with the "claims" 1863 phase based on discussion on the provreg list. 1864 7. Added support for a mixed create model (Sunrise Create Model and 1865 Claims Create Model), where a trademark (encoded signed mark, 1866 etc.) and notice can be passed, based on a request from James 1867 Mitchell. 1868 8. Added text for the handling of the overlapping "claims" and 1869 "landrush" launch phases. 1870 9. Added support for two check forms (claims check form and 1871 availability check form) based on a request from James Mitchell. 1872 The availability check form was based on the text in 1873 draft-rbp-application-epp-mapping. 1875 6.10. Change from 09 to 10 1877 1. Changed noticeIDType from base64Binary to be compatible with 1878 draft-lozano-tmch-func-spec-05. 1879 2. Changed codeType from base64Binary to token to be more generic. 1880 3. Updated based on feedback from Alexander Mayrhofer, which 1881 include: 1882 1. Changed "extension to the domain name extension" to 1883 "extension to the domain name mapping". 1884 2. Changed use of 2004 return code to 2306 return code when 1885 phase passed mismatches active phase and sub-phase. 1886 3. Changed description of "allocated" and "rejected" statuses. 1887 4. Moved sentence on a synchronous command 1888 without the use of an intermediate application, then an 1889 Application Identifier MAY not be needed to the Application 1890 Identifier section. 1891 5. Restructured the Mark Validation Models section to include 1892 the " element" sub-section, the " element" sub-section, and the Digital Signature sub- 1894 section. 1895 6. Changed "Registries may" to "Registries MAY". 1896 7. Changed "extensed" to "extended" in "Availability Check 1897 Form" section. 1898 8. Broke the mix of create forms in the "EPP Command" 1899 section to a fourth "Mixed Create Form" with its own sub- 1900 section. 1901 9. Removed "displayed or" from "displayed or accepted" in the 1902 description. 1903 10. Replaced "given domain name is supported" with "given domain 1904 name are supported" in the "Create Response" section. 1905 11. Changed the reference of 2303 (object does not exist) in the 1906 "Security Considerations" section to 2201 (authorization 1907 error). 1908 12. Added arrow from "invalid" status to "pendingValidation" 1909 status and "pendingAllocation" status to "rejected" status 1910 in the State Transition Diagram. 1911 4. Added the "C:" and "S:" example prefixes and related text in the 1912 "Conventions Used in This Document" section. 1914 7. IANA Considerations 1916 This document uses URNs to describe XML namespaces and XML schemas 1917 conforming to a registry mechanism described in [RFC3688]. Three URI 1918 assignments have been registered by the IANA. 1920 Registration request for the Launch namespace: 1922 URI: urn:ietf:params:xml:ns:launch-1.0 1923 Registrant Contact: See the "Author's Address" section of this 1924 document. 1925 XML: None. Namespace URIs do not represent an XML specification. 1927 8. Security Considerations 1929 The mapping extensions described in this document do not provide any 1930 security services beyond those described by EPP [RFC5730], the EPP 1931 domain name mapping [RFC5731], and protocol layers used by EPP. The 1932 security considerations described in these other specifications apply 1933 to this specification as well. 1935 Updates to, and deletion of an application object must be restricted 1936 to clients authorized to perform the said operation on the object. 1938 As information contained within an application, or even the mere fact 1939 that an application exists may be confidential. Any attempt to 1940 operate on an application object by an unauthorized client MUST be 1941 rejected with an EPP 2201 (authorization error) return code. Server 1942 policy may allow operation with filtered output by clients 1943 other than the sponsoring client, in which case the 1944 and response SHOULD be filtered to include only 1945 fields that are publicly accessible. 1947 9. Normative References 1949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1950 Requirement Levels", BCP 14, RFC 2119, March 1997. 1952 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1953 January 2004. 1955 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1956 STD 69, RFC 5730, August 2009. 1958 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1959 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1961 [draft-lozano-smd] 1962 Lozano, G., "Mark and Signed Mark Objects Mapping". 1964 [1] 1966 Authors' Addresses 1968 James Gould 1969 VeriSign, Inc. 1970 12061 Bluemont Way 1971 Reston, VA 20190 1972 US 1974 Email: jgould@verisign.com 1975 URI: http://www.verisigninc.com 1977 Wil Tan 1978 Cloud Registry 1979 Suite 32 Seabridge House 1980 377 Kent St 1981 Sydney, NSW 2000 1982 AU 1984 Phone: +61 414 710899 1985 Email: wil@cloudregistry.net 1986 URI: http://www.cloudregistry.net 1988 Gavin Brown 1989 CentralNic Ltd 1990 35-39 Mooregate 1991 London, England EC2R 6AR 1992 GB 1994 Phone: +44 20 33 88 0600 1995 Email: gavin.brown@centralnic.com 1996 URI: https://www.centralnic.com