idnits 2.17.1 draft-tan-epp-launchphase-05.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 (January 22, 2013) is 4109 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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: July 26, 2013 CentralNic Ltd 6 J. Gould 7 VeriSign, Inc. 8 January 22, 2013 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-tan-epp-launchphase-05 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 July 26, 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 . . . . . . . . . . . . . . . . . . 6 61 2.4.1. element . . . . . . . . . . . . . . 7 62 2.5. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.6. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.7. Digital Signature . . . . . . . . . . . . . . . . . . . . 10 65 2.7.1. element . . . . . . . . . . . . . . . 10 66 2.7.2. element . . . . . . . . . . . 12 67 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 14 68 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 14 69 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 18 70 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 22 71 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 22 72 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . . 31 73 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 33 74 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 35 75 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 36 76 3.7. EPP Command . . . . . . . . . . . . . . . . . . 36 77 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 37 78 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 37 79 4.2. Signed Mark Schema . . . . . . . . . . . . . . . . . . . . 43 80 4.3. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 45 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 82 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 49 83 6.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . . 49 84 6.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . . 49 85 6.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . . 49 86 6.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . . 50 87 6.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . . 50 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 90 9. Normative References . . . . . . . . . . . . . . . . . . . . . 51 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 93 1. Introduction 95 This document describes an extension mapping for version 1.0 of the 96 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 97 specifies a flexible schema that can be used to implement several 98 common use cases related to the provisioning and management of launch 99 phase extension in a domain name registry. 101 It is typical for domain registries to operate in special modes 102 within certain periods of time to facilitate allocation of domain 103 names. This document uses the term "launch phase" and the shorter 104 form "launch" to refer to such a period. 106 The EPP domain name mapping [RFC5731] is designed for the steady 107 state operation of a registry. During the launch, the interface used 108 at each phase of the launch could be different from what is defined 109 in EPP domain name mapping [RFC5731]. for example, registries 110 typically accept multiple applications for a given domain name during 111 the "sunrise" launch phase, referred to as a launch application. A 112 launch registration is used to refer to a registration made during a 113 launch phase when the server uses a first-come-first-serve model. 114 Even in a first-come-first-serve model additional steps and 115 information might be required to support a launch phase, like the 116 passing of trademark information on a create. In addition, the 117 Proposed Trademark Claims Model [1] defines a registry interface for 118 the Trademark Claims or "claims" launch phase that includes support 119 for presenting a Trademark Claims Notice to the Registrant. This 120 document proposes an extension to the domain name extension in order 121 to unambiguously manage the various launch phases known. 123 1.1. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 XML is case sensitive. Unless stated otherwise, XML specifications 130 and examples provided in this document MUST be interpreted in the 131 character case presented in order to develop a conforming 132 implementation. 134 "launch-1.0" is used as an abbreviation for 135 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 136 "launch" is used, but implementations MUST NOT depend on it and 137 instead employ a proper namespace-aware XML parser and serializer to 138 interpret and output the XML documents. 140 "signedMark-1.0" is used as an abbreviation for 141 "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix 142 "smd" is used, but implementations MUST NOT depend on it and instead 143 employ a proper namespace-aware XML parser and serializer to 144 interpret and output the XML documents. 146 "mark-1.0" is used as an abbreviation for 147 "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" 148 is used, but implementations MUST NOT depend on it and instead employ 149 a proper namespace-aware XML parser and serializer to interpret and 150 output the 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. 182 claims1 Trademark claims phase 1 as defined by Trademark 183 Clearinghouse model of displaying a full, detailed claims notice 184 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 one of four models for validating the trademark 278 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 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 elements. 294 signed mark: The mark information is digitally signed as described 295 in the Digital Signature (Section 2.7) 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.7.1) and (Section 2.7.2) 300 elements. 302 More than one , , or element MAY be specified. The maximum number of 304 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 information. The mark code can be a mark specific secret value 313 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 element. 320 321 49FD46E6C4B45C55D4AC 322 323 Example One 324 example-one 325 exampleone 326 IP Clearinghouse 327 GE 3933232 328 REG-TM-WORD 329 1 330 owner 331 2011-09-09 332 2011-10-09 333 2013-09-09 334 AU 335 VIC 336 337 Example Inc. 338 339 340 John Doe 341 Example Inc. 342 343 123 Example Dr. 344 Suite 100 345 Reston 346 VA 347 20190 348 US 349 350 +1.7035555555 351 +1.7035555556 352 jdoe@example.tld 353 354 355 357 2.5. Mark 359 A element describes an applicant's prior right to a given 360 domain name that is used with the "mark", "mark with code", and the 361 "signed mark" validation models. 363 The child elements of the element include: 365 : An identifier for the mark. This identifier MUST be 366 unique among all marks associated with an application object. 367 : The registered trademark text string. This value is 368 free-form text that MAY be mapped to one or more 369 values. 370 : Zero or more domain name labels that correspond to the 371 . Each can match directly to the domain 372 name after adding the parent zone. 373 : The name of the authority which issued the right 374 (trademark clearinghouse, trademark office, company registration 375 bureau, etc.). 376 : The registration number of the right (trademark 377 number, company registration number, etc.). 378 : Indicates the type of claim being made (trademark, 379 symbol, combined mark, company name, etc.). 380 : Zero or more Nice Classification class numbers as 381 defined in the Nice List of Classes [2]. 382 : Indicates the applicant's entitlement to the 383 mark (owner, licensee, etc.). 384 : The date of registration / application of the mark. 385 : The date the mark becomes effective. 386 : The date of expiration of the mark. 387 : The country in which the mark is valid. This may be 388 a two-character code from [WIPO.ST3]. 389 : The name of a city, state, province or other 390 geographic region in which the mark is valid. 391 : The owner information using the Contact (Section 2.6) 392 elements. 393 : The contact for the owner using the Contact 394 (Section 2.6) element. 396 All of the child elements are OPTIONAL. Server policy may place 397 additional constraints on the format and requirements of such 398 elements. 400 2.6. Contact 402 The contact information contained within the Mark (Section 2.5) 403 cannot be defined via a contact identifier as defined in the EPP 404 contact mapping [RFC5733] since it is contact information defined 405 outside of the server. Some of the contact elements defined in EPP 406 contact mapping [RFC5733] are replicated for the mark contact so 407 there is no dependency to the EPP contact mapping [RFC5733] XML 408 schema from the Mark XML schema. 410 The child elements of a contact using either the or 411 elements include: 413 : The name of the individual or role represented by the 414 contact. 415 : The name of the organization with which the contact is 416 affiliated. 417 : The address information associated with the contact. 418 the element contains the following child elements: 420 Zero to three elements that contain 421 the contact's street address. 422 The contact's city. 423 The contact's state or province. 424 The contact's postal code. 425 The contact's country code. 426 : The contact's voice telephone number. 427 : The contact's facsimile telephone number. 428 : The contact's email address. 430 All of the child elements are OPTIONAL. Server policy may place 431 additional constraints on the format and requirements of such 432 elements. 434 2.7. Digital Signature 436 Digital signatures MAY be used by the server to validate either the 437 mark information, when using the "signed mark" validation model with 438 the element or the element. 439 The digital signatures are handled using an XML Signature [3] around 440 the entire element. The 441 element includes an encoded form of the element like 442 the use of "base64" encoding. Once the digital signature is 443 validated using the appropriate public key, the server can trust all 444 of the information included in the element. It's up 445 to server policy how the public key is transferred. 447 To have the digital signature cover all of the elements of the element, the XML Signature [3] IDREF URI is set to the 449 "id" attribute value of the element and the 450 Transform "http://www.w3.org/2000/09/xmldsig#enveloped-signature" is 451 used. The digital signature covers the element and 452 the Signature element is embedded in the element. 454 2.7.1. element 456 The is the fragment of XML that is digitally signed 457 using XML Signature [3]. The includes a required 458 "id" attribute of type XSD ID for use with an IDREF URI from the 459 Signature element. The child elements of the 460 element include: 462 : The signature serial number that can be compared with 463 a revocation list by the server. 464 : OPTIONAL date and time that the 465 expiry. The server MUST NOT accept a that has 466 expired. No element indicates that there is no 467 expiry. 468 : The trademark information as defined in the Mark 469 (Section 2.5) section. 470 : XML Signature [3] for the . Use of a 471 namespace prefix, like "dsig", is recommended for the 472 "http://www.w3.org/TR/xmldsig-core/" elements. 474 The following is an example using the XML 475 Signature [3] to sign all of the elements of 476 element. 478 480 123456 481 2012-08-16T09:00:00.0Z 482 484 Example One 485 example-one 486 exampleone 487 IP Clearinghouse 488 GE 3933232 489 REG-TM-WORD 490 1 491 owner 492 2011-09-09 493 2011-10-09 494 2013-09-09 495 AU 496 VIC 497 498 Example Inc. 499 500 501 John Doe 502 Example Inc. 503 504 123 Example Dr. 505 Suite 100 506 Reston 507 VA 508 20190 509 US 511 512 +1.7035555555 513 +1.7035555556 514 jdoe@example.tld 515 516 517 519 520 522 524 525 526 529 530 532 533 6651T5s9GZgQOxifdCFmDfSIoUc= 534 535 536 537 538 Gm7RnEb6jcijKcgmwEmxJ6j1L0vt2wFyXv3oKc9 539 a4b8nMOKdec8S3tG2hSx/NZa0RFHvx5zMsH/M 540 jmxzrTBbl5d7W8Qql5VsW4XanSjJ+UgILs9k6XgVtZE2EvffMLBiL4xbCJM48ew 541 RYRY7lVEzoNms91pmm3U5IlNRNjU/YFqZ1pXhhrhyhPjSi9Uon8FnAJaiBEfHcj 542 G6815IJV/9RT+MTXri7i0s82CqIS4wDGbGpyZAs7/kDY3A3upqSOwTtrFSCFX1F 543 +Craec72lBB/dKJHxmoVkbIO5KQhqIOd+E+h2kguE++RHKa4xoBIeyTgWqpWcLu 544 MoFpM+GxwFcpSA== 545 546 547 549 2.7.2. element 551 The element contains an encoded form of the 552 digitally signed element, described in 553 Section 2.7.1, with the encoding defined by the "encoding" attribute 554 with the default "encoding" value of "base64". The "base64" encoded 555 text of the element MUST conform to 556 [RFC2045]. 558 The following is an example of a element that 559 uses the default "base64" for encoding a element. 561 563 D94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c21kOnN 564 pZ25lZE1hcmsgeG1sbnM6c21kPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zO 565 nNpZ25lZE1hcmstMS4wIiBpZD0ic2lnbmVkTWFyayI-PHNtZDpzZXJpYWw 566 -MTIzNDU2PC9zbWQ6c2VyaWFsPjxzbWQ6ZXhEYXRlPjIwMTItMTEtMjlUM 567 Tg6MTY6NTQuMDg4MFo8L3NtZDpleERhdGU-PG1hcms6bWFyayB4bWxuczp 568 tYXJrPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm1hcmstMS4wIj48bWFya 569 zpuYW1lPkV4YW1wbGUgT25lPC9tYXJrOm5hbWU-PG1hcms6bGFiZWw-ZXh 570 hbXBsZS1vbmU8L21hcms6bGFiZWw-PG1hcms6bGFiZWw-ZXhhbXBsZW9uZ 571 TwvbWFyazpsYWJlbD48bWFyazppc3N1ZXI-SVAgQ2xlYXJpbmdob3VzZTw 572 vbWFyazppc3N1ZXI-PG1hcms6bnVtYmVyPkdFIDM5MzMyMzI8L21hcms6b 573 nVtYmVyPjxtYXJrOm51bWJlcj5vd25lcjwvbWFyazpudW1iZXI-PG1hcms 574 6cmVnRGF0ZT4yMDEyLTExLTI5VDE4OjE2OjU0LjA3NDZaPC9tYXJrOnJlZ 575 0RhdGU-PG1hcms6ZXhEYXRlPjIwMTItMTEtMjlUMTg6MTY6NTQuMDc0Nlo 576 8L21hcms6ZXhEYXRlPjxtYXJrOmNvdW50cnk-QVU8L21hcms6Y291bnRye 577 T48bWFyazpyZWdpb24-VklDPC9tYXJrOnJlZ2lvbj48L21hcms6bWFyaz4 578 8ZHNpZzpTaWduYXR1cmUgeG1sbnM6ZHNpZz0iaHR0cDovL3d3dy53My5vc 579 mcvMjAwMC8wOS94bWxkc2lnIyI-PGRzaWc6U2lnbmVkSW5mbz48ZHNpZzp 580 DYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3d 581 y53My5vcmcvVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUjV2l0aEN 582 vbW1lbnRzIi8-PGRzaWc6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0ia 583 HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8 584 -PGRzaWc6UmVmZXJlbmNlIFVSST0iI3NpZ25lZE1hcmsiPjxkc2lnOlRyY 585 W5zZm9ybXM-PGRzaWc6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d 586 3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1c 587 mUiLz48L2RzaWc6VHJhbnNmb3Jtcz48ZHNpZzpEaWdlc3RNZXRob2QgQWx 588 nb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc 589 2hhMSIvPjxkc2lnOkRpZ2VzdFZhbHVlPktIdVFrdFdUMnRYbXg4Y2ZWd2N 590 vZ0JSUm5oRT08L2RzaWc6RGlnZXN0VmFsdWU-PC9kc2lnOlJlZmVyZW5jZ 591 T48L2RzaWc6U2lnbmVkSW5mbz48ZHNpZzpTaWduYXR1cmVWYWx1ZT5RdWk 592 2d2xLVUlRcHMxS2N6ajhUaTVuNTBjaTVDc2pML2k2YjBwS0Z2NG16ZENhc 593 WpWcXVvVDFiSzJCZnhKNG0rbXJiOWxLeFlrVnNFCnB4QnloSG5KSHpSMXV 594 1MG1NMmt4VURyWkVCc0dpV3FuaHMzQVBxOTJBcVdGZHZnUmV6ZHcycmNVb 595 Vg3dGJyeWNGM3ZDMEJmRUg4RHoKb2FIUFRQb24xTUxObzF5bGtYTDA5bWJ 596 qTHVhRlJSS3Z2UCs4djQ1VFJXRmkrbVJ0akJvMGg4blFiNTNtR2lKaU1Oe 597 kFDaDBtK3pFeAp2bmxEUmRpdWJFZVVWbG9LV2dMY1BiSkd4QmFWL1gvQjQ 598 vRnVRbXEzclcxaXNZOUlEYzA3U3ZheEZ0a1l4emVra25GQkNCSWNibXFTC 599 nlOckMvOEp4Y2RRSHN0TUZWc1Z2SjdWUFJqS2VZM0RLcUwrTGhRPT08L2R 600 zaWc6U2lnbmF0dXJlVmFsdWU-PC9kc2lnOlNpZ25hdHVyZT48L3NtZDpza 601 WduZWRNYXJrPg 602 604 3. EPP Command Mapping 606 A detailed description of the EPP syntax and semantics can be found 607 in the EPP core protocol specification [RFC5730]. The command 608 mappings described here are specifically for use in the Launch Phase 609 Extension. 611 This mapping is designed to be flexible, requiring only a minimum set 612 of required elements. 614 While it is meant to serve several use cases, it does not prescribe 615 any interpretation by the client or server. Such processing is 616 typically highly policy-dependent and therefore specific to 617 implementations. 619 Operations on application objects are done via one or more of the 620 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 621 Registries may choose to support a subset of the operations. 623 3.1. EPP Command 625 This extension defines additional elements to extend the EPP 626 command and response to be used in conjunction with the EPP domain 627 name mapping [RFC5731]. 629 This extension defines a new command called the Claims Check Command 630 that is used to determine whether or not there are any matching 631 trademarks, in the specified launch phase, for each domain name 632 passed in the command. The availability check information defined in 633 the EPP domain name mapping [RFC5731] MUST NOT be returned for the 634 Claims Check Command. Instead of returning whether the domain name 635 is available the Claims Check Command will return whether or not at 636 least one matching trademark exists for the domain name. If there is 637 at least one matching trademark that exists for the domain name a 638 element is returned. The value of the element can be used with an info service of a third party 640 trademark provider like the Trademark Clearinghouse (TMCH) for 641 getting the information needed to generate the trademark claims 642 notice. The third party trademark provider should also return a 643 unique notice identifier that can be passed in the 644 element of the extension to the Create Command (Section 3.3). The 645 elements in the EPP command of EPP domain name 646 mapping [RFC5731] define the domain names to check for matching 647 trademarks. The element contains the following child 648 elements: 650 The phase with the value of "claims1" or "claims2" to 651 indicate it as a Claims Check Command. The "claims1" Claims 652 Check Command will match the against the full list 653 of trademark labels and the "claims2" Claims Check Command will 654 match the against the list of trademark labels that 655 opted into the "claims2" launch phase. 657 Example Claims Check Command using the domain command and the 658 extension to determine if "example1.tld" and 659 "example2.tld" have any matching trademarks during the "claims1" 660 launch phase. 662 663 664 665 666 668 example1.tld 669 example2.tld 670 671 672 673 675 claims1 676 677 678 ABC-12345 679 680 681 Example Claims Check Command using the domain command and the 682 extension to determine if "example3.tld" and 683 "example4.tld" have any matching trademarks that opted into the 684 "claims2" launch phase. 686 687 688 689 690 692 example3.tld 693 example4.tld 694 695 696 697 699 claims2 700 701 702 ABC-12345 703 704 706 If the command has been processed successfully, the EPP 707 element MUST contains a child element that 708 identifies the launch namespace. The element 709 contains the following child elements: 711 The phase with a value of "claims1" or "claims2" that 712 matches the associated Claims Check Command . 713 One or more elements that contain the 714 following child elements: 716 Contains the fully qualified name of the queried 717 domain name. This element MUST contain an "exists" attribute 718 whose value indicates if a matching trademark exists for the 719 domain name. A value of "1" or "true" means that a matching 720 trademark does exist for the claims launch phase. A value of 721 "0" or "false" means that a matching trademark does not 722 exist. 723 An OPTIONAL claim key that MAY be passed to an 724 info service of a third party trademark provider like the 725 Trademark Clearinghouse (TMCH) for getting the information 726 needed to generate the trademark claims notice. The is used as the key for the query in place of the 728 domain name to securely query the service without using a 729 well-known value like a domain name. 731 Example Claims Check Response when no matching trademarks are found 732 for the domain name example1.tld and matching trademarks are found 733 for the domain name example2.tld for the "claims1" launch phase. 735 736 737 738 739 Command completed successfully 740 741 742 744 claims1 745 746 example1.tld 747 748 749 example2.tld 750 abc123 751 752 753 754 755 ABC-12345 756 54321-XYZ 757 758 759 760 Example Claims Check Response when no matching trademarks are found 761 for the domain name example3.tld and matching trademarks are found 762 for the domain name example4.tld for the "claims2" launch phase. 764 765 766 767 768 Command completed successfully 769 770 771 773 claims2 774 775 example3.tld 776 777 778 example4.tld 779 abc123 780 781 782 783 784 ABC-12345 785 54321-XYZ 786 787 788 790 3.2. EPP Command 792 This extension defines additional elements to extend the EPP 793 command and response to be used in conjunction with the EPP domain 794 name mapping [RFC5731]. 796 The EPP command is used to retrieve information for a launch 797 phase registration or application. The Application Identifier 798 (Section 2.1) returned in the element of the Create 799 Response (Section 3.3) is used for retrieving information for a 800 launch application. A element is sent along with the 801 regular domain command. The element contains 802 the following child elements: 804 The phase during which the application or 805 registration was submitted or is associated with. Server policy 806 defines the phases that are supported. 807 OPTIONAL application identifier of the launch 808 application. 810 Example domain command with the extension to 811 retrieve information for the sunrise application for example.tld and 812 application identifier "abc123". 814 815 816 817 818 820 example.tld 821 822 823 824 826 sunrise 827 abc123 828 829 830 ABC-12345 831 832 833 Example domain command with the extension to 834 retrieve information for the sunrise registration for example.tld. 836 837 838 839 840 842 example.tld 843 844 845 846 848 sunrise 849 850 851 ABC-12345 852 853 855 If the query was successful, the server replies with a element along with the regular EPP . The contains the following child elements: 859 The phase during which the application was submitted 860 or is associated with that matches the associated command 861 . 862 OPTIONAL application identifier of the launch 863 application. 864 OPTIONAL status of the launch application using one 865 of the supported status values (Section 2.3). 866 Zero or more elements. The 867 child elements are defined in the element 868 (Section 2.5) section. 870 Example domain response using the extension 871 with the mark information. 873 874 875 876 877 Command completed successfully 878 879 880 882 example.tld 883 EXAMPLE1-REP 884 885 jd1234 886 sh8013 887 sh8013 888 ClientX 889 ClientY 890 2012-04-03T22:00:00.0Z 891 892 2fooBAR 893 894 895 896 897 899 sunrise 900 abc123 901 902 904 Hello 905 IP Clearinghouse 906 GE 3933232 907 REG-TM-WORD 908 1 909 owner 910 2011-09-09 911 2011-10-09 912 2013-09-09 913 AU 914 VIC 915 916 Example Inc. 917 918 919 John Doe 920 Example Inc. 921 922 123 Example Dr. 923 Suite 100 924 Reston 925 VA 926 20190 927 US 928 929 +1.7035555555 930 +1.7035555556 931 jdoe@example.tld 932 933 934 935 936 937 ABC-12345 938 54321-XYZ 939 940 941 943 3.3. EPP Command 945 There are two forms of the extension to the EPP command that 946 are dependent on the supported launch phases (Section 2.2) as defined 947 below: 949 sunrise The EPP command with the "sunrise" launch phase is 950 used to submit a registration with trademark information that can 951 be verified by the server with the value. The 952 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 953 launch phase. Optionally, the server can support multiple 954 overlapping applications that are chosen asynchronously with a 955 server generated Application Identifier (Section 2.1) for later 956 reference. 957 landrush The EPP command with the "landrush" launch phase 958 is undefined but the form supported is up to server policy. 959 claims1 The EPP command with the "claims1" launch phase is 960 used to pass the information associated with the presentation and 961 acceptance of the "claims1" claims notice. The Claims Create Form 962 (Section 3.3.2) is used for the "claims1" launch phase. 963 claims2 The EPP command with the "claims2" launch phase is 964 used to pass the information associated with the presentation of 965 the "claims1" claims notice. The Claims Create Form 966 (Section 3.3.2) is used for the "claims2" launch phase. 967 open The EPP command with the "open" launch phase is 968 undefined but the form supported is up to server policy. 969 custom The EPP command with the "custom" launch phase is 970 undefined but the form supported is up to server policy. 972 3.3.1. Sunrise Create Form 974 The Sunrise Create Form of the extension to the EPP domain name 975 mapping [RFC5731] includes the verifiable trademark information that 976 the server uses to match against the domain name to authorize the 977 domain create. A server MUST support one of four models in Claim 978 Validation Models (Section 2.4) to verify the trademark information 979 passed by the client. 981 A element is sent along with the regular 982 domain command. The element contains the following 983 child elements: 985 The launch phase for the create like the "sunrise" 986 launch phase. 987 or or 988 Zero or more elements. The 989 child elements are defined in the element (Section 2.4.1) section. 991 Zero or more elements. The 992 child elements are defined in the element (Section 2.7.1) section. 994 Zero or more 995 elements. The child elements are 996 defined in the element 997 (Section 2.7.2) section. 999 Following is an example domain command using the extension, following the "code" validation model, with 1001 multiple sunrise codes. 1003 1004 1005 1006 1007 1009 example.tld 1010 jd1234 1011 sh8013 1012 sh8013 1013 1014 2fooBAR 1015 1016 1017 1018 1019 1021 sunrise 1022 1023 49FD46E6C4B45C55D4AC 1024 1025 1026 49FD46E6C4B45C55D4AD 1027 1028 1029 49FD46E6C4B45C55D4AE 1030 1031 1032 1033 ABC-12345 1034 1035 1037 Following is an example domain command using the extension, following the "mark" validation model, with the 1039 mark information. 1041 1042 1043 1044 1045 1047 exampleone.tld 1048 jd1234 1049 sh8013 1050 sh8013 1051 1052 2fooBAR 1053 1054 1055 1056 1057 1059 sunrise 1060 1061 1063 Example One 1064 example-one 1065 exampleone 1066 IP Clearinghouse 1067 GE 3933232 1068 REG-TM-WORD 1069 1 1070 owner 1071 2011-09-09 1072 2011-10-09 1073 2013-09-09 1074 AU 1075 VIC 1076 1077 Example Inc. 1078 1079 1080 John Doe 1081 Example Inc. 1082 1083 123 Example Dr. 1084 Suite 100 1085 Reston 1086 VA 1087 20190 1088 US 1089 1090 +1.7035555555 1091 +1.7035555556 1092 jdoe@example.tld 1093 1094 1096 1097 1098 1099 ABC-12345 1100 1101 1103 Following is an example domain command using the extension, following the "code with mark" validation model, 1105 with a code and mark information. 1107 1108 1109 1110 1111 1113 example.tld 1114 jd1234 1115 sh8013 1116 sh8013 1117 1118 2fooBAR 1119 1120 1121 1122 1123 1125 sunrise 1126 1127 49FD46E6C4B45C55D4AC 1128 1130 Hello 1131 IP Clearinghouse 1132 GE 3933232 1133 REG-TM-WORD 1134 1 1135 owner 1136 2011-09-09 1137 2011-10-09 1138 2013-09-09 1139 AU 1140 VIC 1141 1142 Example Inc. 1143 1144 1145 John Doe 1146 Example Inc. 1147 1148 123 Example Dr. 1149 Suite 100 1150 Reston 1151 VA 1152 20190 1153 US 1154 1155 +1.7035555555 1156 +1.7035555556 1157 jdoe@example.tld 1158 1159 1160 1161 1162 1163 ABC-12345 1164 1165 1167 Following is an example domain command using the extension, following the "signed mark" validation model, with 1169 the signed mark information. 1171 1172 1173 1174 1175 1177 exampleone.tld 1178 jd1234 1179 sh8013 1180 sh8013 1181 1182 2fooBAR 1183 1184 1185 1186 1187 1189 sunrise 1190 1192 123456 1193 2012-08-16T09:00:00.0Z 1194 1196 Example One 1197 example-one 1198 exampleone 1199 IP Clearinghouse 1200 GE 3933232 1201 REG-TM-WORD 1202 1 1203 owner 1204 2011-09-09 1205 2011-10-09 1206 2013-09-09 1207 AU 1208 VIC 1209 1210 Example Inc. 1211 1212 1213 John Doe 1214 Example Inc. 1215 1216 123 Example Dr. 1217 Suite 100 1218 Reston 1219 VA 1220 20190 1221 US 1222 1223 +1.7035555555 1224 +1.7035555556 1225 jdoe@example.tld 1226 1227 1228 1230 1231 1233 1235 1236 1237 1239 1240 1242 6651T5s9GZgQOxifdCFmDfSIoUc= 1243 1244 1245 1246 1247 Gm7RnEb6jcijKcgmwEmxJ6j1L0vt2wFyXv3oKc9a4b8nMOKdec8S3tG2hSx 1248 /NZa0RFHvx5zMsH/MjmxzrTBbl5d7W8Qql5VsW4XanSjJ+UgILs9k6XgVtZ 1249 E2EvffMLBiL4xbCJM48ewRYRY7lVEzoNms91pmm3U5IlNRNjU/YFqZ1pXhh 1250 rhyhPjSi9Uon8FnAJaiBEfHcjG6815IJV/9RT+MTXri7i0s82CqIS4wDGbG 1251 pyZAs7/kDY3A3upqSOwTtrFSCFX1F+Craec72lBB/dKJHxmoVkbIO5KQhqI 1252 Od+E+h2kguE++RHKa4xoBIeyTgWqpWcLuMoFpM+GxwFcpSA== 1253 1254 1255 1256 1257 1258 ABC-12345 1259 1260 1262 Following is an example domain command using the extension, following the "signed mark" validation model, with 1264 the base64 encoded signed mark information. 1266 1267 1268 1269 1270 1272 exampleone.tld 1273 jd1234 1274 sh8013 1275 sh8013 1276 1277 2fooBAR 1278 1279 1280 1281 1282 1284 sunrise 1285 1287 D94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c21kOnNpZ25 1288 lZE1hcmsgeG1sbnM6c21kPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNpZ25lZ 1289 E1hcmstMS4wIiBpZD0ic2lnbmVkTWFyayI-PHNtZDpzZXJpYWw-MTIzNDU2PC9 1290 zbWQ6c2VyaWFsPjxzbWQ6ZXhEYXRlPjIwMTItMTEtMjlUMTg6MTY6NTQuMDg4M 1291 Fo8L3NtZDpleERhdGU-PG1hcms6bWFyayB4bWxuczptYXJrPSJ1cm46aWV0Zjp 1292 wYXJhbXM6eG1sOm5zOm1hcmstMS4wIj48bWFyazpuYW1lPkV4YW1wbGUgT25lP 1293 C9tYXJrOm5hbWU-PG1hcms6bGFiZWw-ZXhhbXBsZS1vbmU8L21hcms6bGFiZWw 1294 -PG1hcms6bGFiZWw-ZXhhbXBsZW9uZTwvbWFyazpsYWJlbD48bWFyazppc3N1Z 1295 XI-SVAgQ2xlYXJpbmdob3VzZTwvbWFyazppc3N1ZXI-PG1hcms6bnVtYmVyPkd 1296 FIDM5MzMyMzI8L21hcms6bnVtYmVyPjxtYXJrOm51bWJlcj5vd25lcjwvbWFya 1297 zpudW1iZXI-PG1hcms6cmVnRGF0ZT4yMDEyLTExLTI5VDE4OjE2OjU0LjA3NDZ 1298 aPC9tYXJrOnJlZ0RhdGU-PG1hcms6ZXhEYXRlPjIwMTItMTEtMjlUMTg6MTY6N 1299 TQuMDc0Nlo8L21hcms6ZXhEYXRlPjxtYXJrOmNvdW50cnk-QVU8L21hcms6Y29 1300 1bnRyeT48bWFyazpyZWdpb24-VklDPC9tYXJrOnJlZ2lvbj48L21hcms6bWFya 1301 z48ZHNpZzpTaWduYXR1cmUgeG1sbnM6ZHNpZz0iaHR0cDovL3d3dy53My5vcmc 1302 vMjAwMC8wOS94bWxkc2lnIyI-PGRzaWc6U2lnbmVkSW5mbz48ZHNpZzpDYW5vb 1303 mljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmc 1304 vVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUjV2l0aENvbW1lbnRzIi8-P 1305 GRzaWc6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5 1306 vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8-PGRzaWc6UmVmZXJlbmNlI 1307 FVSST0iI3NpZ25lZE1hcmsiPjxkc2lnOlRyYW5zZm9ybXM-PGRzaWc6VHJhbnN 1308 mb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc 1309 2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48L2RzaWc6VHJhbnNmb3Jtcz48ZHN 1310 pZzpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yM 1311 DAwLzA5L3htbGRzaWcjc2hhMSIvPjxkc2lnOkRpZ2VzdFZhbHVlPktIdVFrdFd 1312 UMnRYbXg4Y2ZWd2NvZ0JSUm5oRT08L2RzaWc6RGlnZXN0VmFsdWU-PC9kc2lnO 1313 lJlZmVyZW5jZT48L2RzaWc6U2lnbmVkSW5mbz48ZHNpZzpTaWduYXR1cmVWYWx 1314 1ZT5RdWk2d2xLVUlRcHMxS2N6ajhUaTVuNTBjaTVDc2pML2k2YjBwS0Z2NG16Z 1315 ENhcWpWcXVvVDFiSzJCZnhKNG0rbXJiOWxLeFlrVnNFCnB4QnloSG5KSHpSMXV 1316 1MG1NMmt4VURyWkVCc0dpV3FuaHMzQVBxOTJBcVdGZHZnUmV6ZHcycmNVbVg3d 1317 GJyeWNGM3ZDMEJmRUg4RHoKb2FIUFRQb24xTUxObzF5bGtYTDA5bWJqTHVhRlJ 1318 SS3Z2UCs4djQ1VFJXRmkrbVJ0akJvMGg4blFiNTNtR2lKaU1OekFDaDBtK3pFe 1319 Ap2bmxEUmRpdWJFZVVWbG9LV2dMY1BiSkd4QmFWL1gvQjQvRnVRbXEzclcxaXN 1320 ZOUlEYzA3U3ZheEZ0a1l4emVra25GQkNCSWNibXFTCnlOckMvOEp4Y2RRSHN0T 1321 UZWc1Z2SjdWUFJqS2VZM0RLcUwrTGhRPT08L2RzaWc6U2lnbmF0dXJlVmFsdWU 1322 -PC9kc2lnOlNpZ25hdHVyZT48L3NtZDpzaWduZWRNYXJrPg 1323 1324 1325 1326 ABC-12345 1327 1328 1330 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1332 server generated Application Identifier (Section 2.1) when multiple 1333 applications of a given domain name is supported; otherwise no 1334 extension is included with the regular EPP . The element contains the following child elements: 1337 The phase of the application that mirrors the 1338 element included in the . 1339 The application identifier of the 1340 application. 1342 An example response when multiple overlapping applications are 1343 supported by the server. 1345 1346 1347 1348 1349 Command completed successfully; action pending 1350 1351 1352 1354 example.tld 1355 2010-08-10T15:38:26.623854Z 1356 2012-08-10T15:38:26.623854Z 1357 1358 1359 1360 1362 sunrise 1363 2393-9323-E08C-03B1 1364 1365 1366 1367 1368 ABC-12345 1369 54321-XYZ 1370 1371 1372 1374 3.3.2. Claims Create Form 1376 The Claims Create Form of the extension to the EPP domain name 1377 mapping [RFC5731] includes the information related to the acceptance 1378 of the claims notice for the "claims1" launch phase and the display 1379 of the claims notice for the "claims2" launch phase. 1381 A element is sent along with the regular 1382 domain command. The element contains the following 1383 child elements: 1385 MUST contain the value of "claims1" or "claim2" to 1386 indicate the claims launch phase. 1387 1388 Unique notice identifier generated by the 1389 source of the claims notice information like the Claims 1390 Notice Information Service (CNIS). 1391 Contains the date and time that the claims 1392 notice was displayed or accepted. 1393 Contains the source information of the client 1394 that was displayed or that accepted the claims notice like 1395 the client IP address. 1397 Following is an example domain command using the extension with the information for the 1399 "claims1" claims launch phase. 1401 1402 1403 1404 1405 1407 example.tld 1408 jd1234 1409 sh8013 1410 sh8013 1411 1412 2fooBAR 1413 1414 1415 1416 1417 1419 claims1 1420 1421 49FD46E6C4B45C55D4AC 1422 2012-06-19T09:00:00.0Z 1423 192.0.2.29 1424 1425 1426 1427 ABC-12345 1428 1429 1431 This extension does not define any extension to the response of a 1432 domain command for the Claims Create Form. After processing 1433 the command, the server replies with a standard EPP response as 1434 defined in the EPP domain name mapping [RFC5731]. 1436 3.4. EPP Command 1438 This extension defines additional elements to extend the EPP 1439 command to be used in conjunction with the domain name mapping. 1441 A server that does not support multiple applications of a given 1442 domain name with an Application Identifier (Section 2.1) during its 1443 launch phase operations MUST return an EPP error result code of 2102. 1445 Registry policies permitting, clients may update an application 1446 object by submitting an EPP command along with a element to indicate the application object to be updated. 1448 The element contains the following child elements: 1450 The phase during which the application was submitted 1451 or is associated with. 1452 The application identifier for which the 1453 client wishes to update. 1455 This extension does not define any extension to the response of an 1456 domain command. After processing the command, the server 1457 replies with a standard EPP response as defined in the EPP domain 1458 name mapping [RFC5731]. 1460 Following is an example domain command with the extension to add and remove a name server of a sunrise 1462 application with the application identifier "abc123". 1464 1465 1466 1467 1468 1470 example.tld 1471 1472 1473 ns2.example.tld 1474 1475 1476 1477 1478 ns1.example.tld 1479 1480 1481 1482 1483 1484 1486 sunrise 1487 abc123 1488 1489 1490 ABC-12345 1491 1492 1493 An example response that corresponds to the above command. 1495 1496 1497 1498 1499 Command completed successfully 1500 1501 1502 ABC-12345 1503 54321-XYZ 1504 1505 1506 1508 3.5. EPP Command 1510 This extension defines additional elements to extend the EPP 1511 command to be used in conjunction with the domain name mapping. 1513 A server that does not support multiple applications of a given 1514 domain name with an Application Identifier (Section 2.1) during its 1515 launch phase operations MUST return an EPP error result code of 2102. 1517 Registry policies permitting, clients MAY withdraw an application by 1518 submitting an EPP command along with a 1519 element to indicate the application object to be deleted. The 1520 element contains the following child elements: 1522 The phase during which the application was submitted 1523 or is associated with. 1524 The application identifier for which the 1525 client wishes to delete. 1527 This extension does not define any extension to the response of a 1528 domain command. After processing the command, the server 1529 replies with a standard EPP response as defined in the EPP domain 1530 name mapping [RFC5731]. 1532 Following is an example domain command with the extension. 1535 1536 1537 1538 1539 1541 example.tld 1542 1543 1544 1545 1547 sunrise 1548 abc123 1549 1550 1551 ABC-12345 1552 1553 1555 An example response that corresponds to the above command. 1557 1558 1559 1560 1561 Command completed successfully 1562 1563 1564 ABC-12345 1565 54321-XYZ 1566 1567 1568 1570 3.6. EPP Command 1572 This extension does not define any extension to the EPP 1573 command or response described in the EPP domain name mapping 1574 [RFC5731]. 1576 3.7. EPP Command 1578 This extension does not define any extension to the EPP 1579 command or response described in the EPP domain name mapping 1581 [RFC5731]. 1583 4. Formal Syntax 1585 Three schemas are presented here. The first schema is the EPP Launch 1586 Phase Mapping schema. The second schema is a dependent schema for 1587 the Signed Mark. The third schema is a dependent schema for the 1588 Mark. 1590 The formal syntax presented here is a complete schema representation 1591 of the object mapping suitable for automated validation of EPP XML 1592 instances. The BEGIN and END tags are not part of the schema; they 1593 are used to note the beginning and ending of the schema for URI 1594 registration purposes. 1596 4.1. Launch Schema 1598 Copyright (c) 2012 IETF Trust and the persons identified as authors 1599 of the code. All rights reserved. 1601 Redistribution and use in source and binary forms, with or without 1602 modification, are permitted provided that the following conditions 1603 are met: 1605 o Redistributions of source code must retain the above copyright 1606 notice, this list of conditions and the following disclaimer. 1607 o Redistributions in binary form must reproduce the above copyright 1608 notice, this list of conditions and the following disclaimer in 1609 the documentation and/or other materials provided with the 1610 distribution. 1611 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1612 names of specific contributors, may be used to endorse or promote 1613 products derived from this software without specific prior written 1614 permission. 1616 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1617 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1618 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1619 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1620 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1621 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1622 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1623 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1624 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1625 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1626 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1628 BEGIN 1629 1630 1639 1642 1645 1648 1651 1652 1653 Extensible Provisioning Protocol v1.0 1654 domain name extension schema 1655 for the launch phase processing. 1656 1657 1659 1662 1663 1664 1665 1666 1668 1671 1672 1673 1674 1675 1677 1679 1682 1683 1684 1686 1692 1693 1694 1695 1696 1697 1698 1700 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1714 1717 1718 1719 1720 1721 1723 1726 1727 1728 1729 1730 1732 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1747 1750 1751 1752 1753 1755 1757 1758 1759 1760 1762 1766 1767 1768 1770 1773 1774 1776 1779 1780 1781 1782 1783 1785 1787 1789 1791 1792 1793 1795 1798 1799 1800 1801 1802 1803 1804 1806 1809 1810 1811 1812 1813 1815 1818 1819 1820 1821 1824 1825 1827 1830 1831 1832 1834 1837 1838 1839 1840 1842 1843 1845 1846 1847 1848 1850 1851 1853 1854 1855 1856 1858 1859 1860 1862 1865 1866 1867 1868 1871 1873 1875 1876 1878 1879 END 1881 4.2. Signed Mark Schema 1883 Copyright (c) 2012 IETF Trust and the persons identified as authors 1884 of the code. All rights reserved. 1886 Redistribution and use in source and binary forms, with or without 1887 modification, are permitted provided that the following conditions 1888 are met: 1890 o Redistributions of source code must retain the above copyright 1891 notice, this list of conditions and the following disclaimer. 1892 o Redistributions in binary form must reproduce the above copyright 1893 notice, this list of conditions and the following disclaimer in 1894 the documentation and/or other materials provided with the 1895 distribution. 1896 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1897 names of specific contributors, may be used to endorse or promote 1898 products derived from this software without specific prior written 1899 permission. 1901 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1902 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1903 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1904 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1905 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1906 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1907 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1908 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1909 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1910 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1911 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1913 BEGIN 1914 1915 1923 1926 1929 1932 1933 1934 Schema for representing a Signed Mark, also referred to 1935 as Signed Mark Data (SMD), that includes digitally 1936 signed trademark information. 1937 1938 1940 1943 1945 1948 1951 1954 1955 1956 1957 1959 1960 1961 1962 1963 1965 1968 1969 1970 1971 1973 1974 1975 1977 1978 END 1980 4.3. Mark Schema 1982 Copyright (c) 2012 IETF Trust and the persons identified as authors 1983 of the code. All rights reserved. 1985 Redistribution and use in source and binary forms, with or without 1986 modification, are permitted provided that the following conditions 1987 are met: 1989 o Redistributions of source code must retain the above copyright 1990 notice, this list of conditions and the following disclaimer. 1991 o Redistributions in binary form must reproduce the above copyright 1992 notice, this list of conditions and the following disclaimer in 1993 the documentation and/or other materials provided with the 1994 distribution. 1995 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1996 names of specific contributors, may be used to endorse or promote 1997 products derived from this software without specific prior written 1998 permission. 2000 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2001 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2002 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2003 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2004 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2005 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2006 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2007 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2008 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2009 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2010 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2012 BEGIN 2013 2014 2020 2021 2022 Schema for representing a Trademark, also referred to 2023 as Mark. 2024 2025 2027 2030 2032 2035 2036 2037 2039 2041 2043 2045 2047 2049 2051 2053 2055 2058 2060 2062 2064 2066 2068 2069 2071 2074 2075 2076 2077 2078 2079 2081 2084 2085 2086 2087 2088 2090 2093 2094 2095 2096 2097 2099 2102 2103 2104 2105 2106 2107 2108 2110 2113 2114 2115 2116 2117 2118 2120 2123 2124 2125 2127 2129 2131 2133 2135 2136 2138 2141 2142 2143 2144 2145 2147 2150 2151 2152 2154 2156 2158 2160 2162 2164 2165 2167 2168 END 2170 5. Acknowledgements 2172 [to be filled in] 2174 6. Change History 2176 6.1. Change from 00 to 01 2178 1. Changed to use camel case for the XML elements. 2179 2. Replaced "cancelled" status to "rejected" status. 2180 3. Added the child elements of the element. 2181 4. Removed the XML schema and replaced with "[TBD]". 2183 6.2. Change from 01 to 02 2185 1. Added support for both the ICANN and ARI/Neustar TMCH models. 2186 2. Changed the namespace URI and prefix to use "launch" instead of 2187 "launchphase". 2188 3. Added definition of multiple claim validation models. 2189 4. Added the and 2190 elements. 2191 5. Added support for Claims Info Command 2193 6.3. Change from 02 to 03 2195 1. Removed XSI namespace per Keith Gaughan's suggestion on the 2196 provreg list. 2198 2. Added extensibility to the launch:status element and added the 2199 pendingAuction status per Trung Tran's feedback on the provreg 2200 list. 2201 3. Added support for the Claims Check Command, updated the location 2202 and contents of the signedNotice, and replaced most references of 2203 Claim to Mark based on the work being done on the ARI/Neustar 2204 launch model. 2206 6.4. Change from 03 to 04 2208 1. Removed references to the ICANN model. 2209 2. Removed support for the Claims Info Command. 2210 3. Removed use of the signedClaim. 2211 4. Revised the method for referring to the signedClaim from the XML 2212 Signature using the IDREF URI. 2213 5. Split the launch-1.0.xsd into three XML schemas including launch- 2214 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 2215 6. Split the "claims" launch phase to the "claims1" and "claims2" 2216 launch phases. 2217 7. Added support for the encodedSignedMark with base64 encoded 2218 signedMark. 2219 8. Changed the elements in the createNoticeType to include the 2220 noticeID, timestamp, and the source elements. 2221 9. Added the class and effectiveDate elements to mark. 2223 6.5. Change from 04 to 05 2225 1. Removed reference to in the example. 2226 2. Incorporated feedback from Bernhard Reutner-Fischer on the 2227 provreg mail list. 2228 3. Added missing launch XML prefix to applicationIDType reference in 2229 the idContainerType of the Launch Schema. 2230 4. Added missing description of the element in the element. 2232 5. Updated note on replication of the EPP contact mapping elements 2233 in the Mark Contact section. 2235 7. IANA Considerations 2237 This document uses URNs to describe XML namespaces and XML schemas 2238 conforming to a registry mechanism described in [RFC3688]. Three URI 2239 assignments have been registered by the IANA. 2241 Registration request for the Launch namespace: 2243 URI: urn:ietf:params:xml:ns:launch-1.0 2244 Registrant Contact: See the "Author's Address" section of this 2245 document. 2246 XML: None. Namespace URIs do not represent an XML specification. 2248 Registration request for the Signed mark namespace: 2250 URI: urn:ietf:params:xml:ns:signedMark-1.0 2251 Registrant Contact: See the "Author's Address" section of this 2252 document. 2253 XML: None. Namespace URIs do not represent an XML specification. 2255 Registration request for the Mark namespace: 2257 URI: urn:ietf:params:xml:ns:mark-1.0 2258 Registrant Contact: See the "Author's Address" section of this 2259 document. 2260 XML: None. Namespace URIs do not represent an XML specification. 2262 8. Security Considerations 2264 The mapping extensions described in this document do not provide any 2265 security services beyond those described by EPP [RFC5730], the EPP 2266 domain name mapping [RFC5731], and protocol layers used by EPP. The 2267 security considerations described in these other specifications apply 2268 to this specification as well. 2270 Updates to, and deletion of an application object must be restricted 2271 to clients authorized to perform the said operation on the object. 2273 As information contained within an application, or even the mere fact 2274 that an application exists may be confidential. Any attempt to 2275 operate on an application object by an unauthorized client MUST be 2276 rejected with an EPP 2303 (object does not exist) or an appropriate 2277 auhorization error. Server policy may allow operation with 2278 filtered output by clients other than the sponsoring client, in which 2279 case the and response SHOULD be 2280 filtered to include only fields that are publicly accessible. 2282 9. Normative References 2284 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2285 Extensions (MIME) Part One: Format of Internet Message 2286 Bodies", RFC 2045, November 1996. 2288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2289 Requirement Levels", BCP 14, RFC 2119, March 1997. 2291 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2292 January 2004. 2294 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2295 STD 69, RFC 5730, August 2009. 2297 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2298 Domain Name Mapping", STD 69, RFC 5731, August 2009. 2300 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2301 Contact Mapping", STD 69, RFC 5733, August 2009. 2303 [WIPO.ST3] 2304 WIPO, "Recommended standard on two-letter codes for the 2305 representation of states, other entities and 2306 intergovernmental organizations", March 2007. 2308 [1] 2311 [2] 2313 [3] 2315 Authors' Addresses 2317 Wil Tan 2318 Cloud Registry 2319 Suite 32 Seabridge House 2320 377 Kent St 2321 Sydney, NSW 2000 2322 AU 2324 Phone: +61 414 710899 2325 Email: wil@cloudregistry.net 2326 URI: http://www.cloudregistry.net 2327 Gavin Brown 2328 CentralNic Ltd 2329 35-39 Mooregate 2330 London, England EC2R 6AR 2331 GB 2333 Phone: +44 8700 170 900 2334 Email: gavin.brown@centralnic.com 2335 URI: http://www.centralnic.com 2337 James Gould 2338 VeriSign, Inc. 2339 12061 Bluemont Way 2340 Reston, VA 20190 2341 US 2343 Email: jgould@verisign.com 2344 URI: http://www.verisigninc.com