idnits 2.17.1 draft-tan-epp-launchphase-04.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 (December 4, 2012) is 4160 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: June 7, 2013 CentralNic Ltd 6 J. Gould 7 VeriSign, Inc. 8 December 4, 2012 10 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 11 draft-tan-epp-launchphase-04 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 June 7, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 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 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 89 9. Normative References . . . . . . . . . . . . . . . . . . . . . 51 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 92 1. Introduction 94 This document describes an extension mapping for version 1.0 of the 95 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 96 specifies a flexible schema that can be used to implement several 97 common use cases related to the provisioning and management of launch 98 phase extension in a domain name registry. 100 It is typical for domain registries to operate in special modes 101 within certain periods of time to facilitate allocation of domain 102 names. This document uses the term "launch phase" and the shorter 103 form "launch" to refer to such a period. 105 The EPP domain name mapping [RFC5731] is designed for the steady 106 state operation of a registry. During the launch, the interface used 107 at each phase of the launch could be different from what is defined 108 in EPP domain name mapping [RFC5731]. for example, registries 109 typically accept multiple applications for a given domain name during 110 the "sunrise" launch phase, referred to as a launch application. A 111 launch registration is used to refer to a registration made during a 112 launch phase when the server uses a first-come-first-serve model. 113 Even in a first-come-first-serve model additional steps and 114 information might be required to support a launch phase, like the 115 passing of trademark information on a create. In addition, the 116 Proposed Trademark Claims Model [1] defines a registry interface for 117 the Trademark Claims or "claims" launch phase that includes support 118 for presenting a Trademark Claims Notice to the Registrant. This 119 document proposes an extension to the domain name extension in order 120 to unambiguously manage the various launch phases known. 122 1.1. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 XML is case sensitive. Unless stated otherwise, XML specifications 129 and examples provided in this document MUST be interpreted in the 130 character case presented in order to develop a conforming 131 implementation. 133 "launch-1.0" is used as an abbreviation for 134 "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix 135 "launch" is used, but implementations MUST NOT depend on it and 136 instead employ a proper namespace-aware XML parser and serializer to 137 interpret and output the XML documents. 139 "signedMark-1.0" is used as an abbreviation for 140 "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix 141 "smd" is used, but implementations MUST NOT depend on it and instead 142 employ a proper namespace-aware XML parser and serializer to 143 interpret and output the XML documents. 145 "mark-1.0" is used as an abbreviation for 146 "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" 147 is used, but implementations MUST NOT depend on it and instead employ 148 a proper namespace-aware XML parser and serializer to interpret and 149 output the XML documents. 151 2. Object Attributes 153 This extension adds additional elements to the EPP domain name 154 mapping [RFC5731]. Only those new elements are described here. 156 2.1. Application Identifiers 158 Servers MAY allow multiple applications, referred to as a launch 159 application, of a given domain name during its launch phase 160 operations. Upon receiving a request to create a domain name, the 161 server creates an application object corresponding to the request and 162 assigns an application identifier for the application and returns it 163 to the client with the element. In order to 164 facilitate correlation, all subsequent launch operations on the 165 application object MUST be qualified by the previously assigned 166 application identifier using the element. 168 2.2. Launch Phases 170 The server MAY support multiple launch phases sequentially or 171 simultaneously. The element MUST be included by the 172 client to define the target launch phase of the command. 174 The following launch phase values are defined: 175 sunrise Phase when trademark holders can submit registration 176 applications with trademark information that can be validated by 177 the server. 178 landrush Post sunrise phase when non-trademark holders are allowed 179 to register domain names with steps taken to address a large 180 volume of initial registrations. 181 claims1 Trademark claims phase 1 as defined by Trademark 182 Clearinghouse model of displaying a full, detailed claims notice 183 to clients for domain names that match trademarks. 185 claims2 Trademark claims phase 2 as defined by Trademark 186 Clearinghouse model of displaying a short, educational claims 187 notice to clients for domain names that match trademarks that opt 188 into the service. 189 open Post launch phase that is also referred to as "steady state". 190 Servers MAY require additional trademark protection with this 191 phase. 192 custom A custom server launch phase that is defined using the "name" 193 attribute. 195 For extensibility the element includes an OPTIONAL 196 "name" attribute that can define a sub-phase or the full name of the 197 phase when the element has the "custom" value. For 198 example, the "claims1" launch phase could have two sub-phases that 199 include "landrush" and "open". 201 2.3. Status Values 203 A launch application object MAY have a status value. The element is used to convey extended status pertaining to the 205 application object, beyond what is specified in the object mapping 206 for this application object. 208 The following status values are defined using the required "s" 209 attribute: 210 pending: the initial state of a newly-created application object. 211 validated: the application meets relevant registry rules. 212 invalid: the application does not validate according to registry 213 rules. 214 pendingAuction: the application is pending based on results of an 215 auction. 216 allocated: one of two possible end states of an application object; 217 the object corresponding to the application has been provisioned. 218 rejected: the other possible end state; the object was not 219 provisioned. 220 custom: A custom status that is defined using the "name" attribute. 222 Each status value MAY be accompanied by a string of human-readable 223 text that describes the rationale for the status applied to the 224 object. The OPTIONAL "lang" attribute MAY be present to identify the 225 language if the negotiated value is something other than the default 226 value of "en" (English). 228 For extensibility the element includes an OPTIONAL 229 "name" attribute that can define a sub-status or the full name of the 230 status when the status value is "custom". The server SHOULD NOT use 231 of the "custom" status value. 233 Certain status values MAY be combined. For example, an application 234 can be invalid and rejected. Additionally certain statuses MAY be 235 skipped. For example, an application MAY immediately start at the 236 allocated status or an application MAY skip the pendingAuction status 237 if server does not support an auction. If a 238 processes a request synchronously without the use of an intermediate 239 application, than an Application Identifier (Section 2.1) is not 240 needed along with the application status. 242 2.3.1. State Transition 244 | request 245 v 246 +---------+ 247 | pending | 248 +----+----+ 249 | 250 | 251 +--------------+-----+-----------+--------------+ 252 | | | | 253 v v v v 254 +-----------+ +---------+ +-------+ +-------+ 255 | | | | / \ / \ 256 | validated | | invalid +----->| rejected | | allocated | 257 | | | | \ / \ / 258 +----+------+ +----+----+ +-------+ +-------+ 259 | | ^ ^ 260 | | | | 261 | +-----------------+ | 262 | | | 263 +---------------------------------+ | 264 | ^ | 265 | | | 266 | +--------+-------+ | 267 | | | | 268 +----------------------->| pendingAuction +------+ 269 | | 270 +----------------+ 272 Figure 1 274 2.4. Mark Validation Models 276 A server MUST support one of four models for validating the trademark 277 information: 279 code Use of a mark code by itself to validate that the mark matches 280 the domain name. This model is supported using the element with just the element. 282 mark The mark information is passed without any other validation 283 element. The server will use some custom form of validation to 284 validate that the mark information is authentic. This model is 285 supported using the element with just the element. 287 code with mark: A code is used along with the mark information by 288 the server to validate the mark utilizing an external party. The 289 code represents some form of secret that matches the mark 290 information passed. This model is supported using the element that contains both the and the 292 elements. 293 signed mark: The mark information is digitally signed as described 294 in the Digital Signature (Section 2.7) section. The digital 295 signature can be directly validated by the server using the public 296 key of the external party that created the signed mark using it's 297 private key. This model is supported using the 298 (Section 2.7.1) and (Section 2.7.2) 299 elements. 301 More than one , , or element MAY be specified. The maximum number of 303 marks per domain name is up to server policy. 305 2.4.1. element 307 The element that is used by the "code", "mark", and 308 "code with mark" validation models, has the following child elements: 310 : OPTIONAL mark code used to validate the 311 information. The mark code can be a mark specific secret value 312 that the server can verify against a third party. 313 : OPTIONAL mark information with child elements defined 314 in the Mark (Section 2.5) section. 316 The following is an example element with both a 317 and element. 319 320 49FD46E6C4B45C55D4AC 321 322 Example One 323 example-one 324 exampleone 325 IP Clearinghouse 326 GE 3933232 327 REG-TM-WORD 328 1 329 owner 330 2011-09-09 331 2011-10-09 332 2013-09-09 333 AU 334 VIC 335 336 Example Inc. 337 338 339 John Doe 340 Example Inc. 341 342 123 Example Dr. 343 Suite 100 344 Reston 345 VA 346 20190 347 US 348 349 +1.7035555555 350 +1.7035555556 351 jdoe@example.tld 352 353 354 356 2.5. Mark 358 A element describes an applicant's prior right to a given 359 domain name that is used with the "mark", "mark with code", and the 360 "signed mark" validation models. 362 The child elements of the element include: 364 : an identifier for the mark. This identifier MUST be 365 unique among all marks associated with an application object. 366 : The registered trademark text string. This value is 367 free-form text that MAY be mapped to one or more 368 values. 369 : Zero or more domain name labels that corresponds to 370 the . Each can match directly to the 371 domain name after adding the parent zone. 372 : name of the authority which issued the right 373 (trademark clearinghouse, trademark office, company registration 374 bureau, etc.) 375 : the registration number of the right (trademark 376 number, company registration number, etc.) 377 : indicates the applicant's entitlement to the mark 378 (owner, licensee, etc.) 379 : zero or more Nice Classification class numbers as 380 defined in the Nice List of Classes [2] 381 : indicates the applicant's entitlement to the 382 mark (owner, licensee, etc.) 383 : the date of registration / application of the mark 384 : the date the mark becomes effective 385 : the date of expiration of the mark 386 : indicates the country in which the mark is valid. 387 This may be a two-character code from [WIPO.ST3] 388 : indicates the name of a city, state, province or 389 other geographic region in which the mark is valid. 390 : Owner information using the Contact (Section 2.6) 391 elements. 392 : Contact for the owner using the Contact 393 (Section 2.6) element. 395 All of the child elements are OPTIONAL. Server policy may place 396 additional constraints on the format and requirements of such 397 elements. 399 2.6. Contact 401 The contact information contained within the Mark (Section 2.5) 402 cannot be defined via a contact identifier as defined in the EPP 403 contact mapping [RFC5733] since it is contact information defined 404 outside of the server. Some of the contact elements defined in EPP 405 contact mapping [RFC5733] are replicated in this extension. 407 The child elements of a contact using either the or 408 elements include: 410 : name of the individual or role represented by the 411 contact. 412 : name of the organization with which the contact is 413 affiliated. 414 : address information associated with the contact. the 415 element contains the following child elements: 417 zero to three elements that contain 418 the contact's street address. 419 contact's city 420 contact's state or province 421 contact's country code 422 : contact's voice telephone number 423 : contact's facsimile telephone number 424 : contact's email address 426 All of the child elements are OPTIONAL. Server policy may place 427 additional constraints on the format and requirements of such 428 elements. 430 2.7. Digital Signature 432 Digital signatures MAY be used by the server to validate either the 433 mark information, when using the "signed mark" validation model with 434 the element or the element. 435 The digital signatures are handled using an XML Signature [3] around 436 the entire element. The 437 element includes an encoded form of the element like 438 the use of "base64" encoding. Once the digital signature is 439 validated using the appropriate public key, the server can trust all 440 of the information included in the element. It's up 441 to server policy how the public key is transferred. 443 To have the digital signature cover all of the elements of the element, the XML Signature [3] IDREF URI is set to the 445 "id" attribute value of the element and the 446 Transform "http://www.w3.org/2000/09/xmldsig#enveloped-signature" is 447 used. The digital signature covers the element and 448 the Signature element is embedded in the element. 450 2.7.1. element 452 The is the fragment of XML that is digitally signed 453 using XML Signature [3]. The includes a required 454 "id" attribute of type XSD ID for use with an IDREF URI from the 455 Signature element. The child elements of the 456 element include: 458 : Signature serial number that that can be compared with 459 a revocation list by the server. 460 : OPTIONAL date and time that the 461 expires. The server MUST NOT accept a that has 462 expired. No element indicates that there is no 463 expiry. 464 : Trademark information as defined in the Mark 465 (Section 2.5) section. 466 : XML Signature [3] for the . Use of a 467 namespace prefix, like "dsig", is recommended for the 468 "http://www.w3.org/TR/xmldsig-core/" elements. 470 The following is an example using the XML 471 Signature [3] to sign all of the elements of 472 element. 474 476 123456 477 newtld 478 2012-08-16T09:00:00.0Z 479 481 Example One 482 example-one 483 exampleone 484 IP Clearinghouse 485 GE 3933232 486 REG-TM-WORD 487 1 488 owner 489 2011-09-09 490 2011-10-09 491 2013-09-09 492 AU 493 VIC 494 495 Example Inc. 496 497 498 John Doe 499 Example Inc. 500 501 123 Example Dr. 502 Suite 100 503 Reston 504 VA 505 20190 506 US 507 508 +1.7035555555 509 +1.7035555556 510 jdoe@example.tld 511 512 513 515 516 518 520 521 522 524 525 527 6651T5s9GZgQOxifdCFmDfSIoUc= 528 529 530 531 Gm7RnEb6jcijKcgmwEmxJ6j1L0vt2wFyXv3oKc9 532 a4b8nMOKdec8S3tG2hSx/NZa0RFHvx5zMsH/M 533 jmxzrTBbl5d7W8Qql5VsW4XanSjJ+UgILs9k6XgVtZE2EvffMLBiL4xbCJM48ew 534 RYRY7lVEzoNms91pmm3U5IlNRNjU/YFqZ1pXhhrhyhPjSi9Uon8FnAJaiBEfHcj 535 G6815IJV/9RT+MTXri7i0s82CqIS4wDGbGpyZAs7/kDY3A3upqSOwTtrFSCFX1F 536 +Craec72lBB/dKJHxmoVkbIO5KQhqIOd+E+h2kguE++RHKa4xoBIeyTgWqpWcLu 537 MoFpM+GxwFcpSA== 538 539 540 542 2.7.2. element 544 The element contains an encoded form of the 545 digitally signed element, described in 546 Section 2.7.1, with the encoding defined by the "encoding" attribute 547 with the default "encoding" value of "base64". The "base64" encoded 548 text of the element MUST conform to 549 [RFC2045]. 551 The following is an example an element that 552 uses the default "base64" for encoding a element. 554 556 D94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c21kOnN 557 pZ25lZE1hcmsgeG1sbnM6c21kPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zO 558 nNpZ25lZE1hcmstMS4wIiBpZD0ic2lnbmVkTWFyayI-PHNtZDpzZXJpYWw 559 -MTIzNDU2PC9zbWQ6c2VyaWFsPjxzbWQ6ZXhEYXRlPjIwMTItMTEtMjlUM 560 Tg6MTY6NTQuMDg4MFo8L3NtZDpleERhdGU-PG1hcms6bWFyayB4bWxuczp 561 tYXJrPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm1hcmstMS4wIj48bWFya 562 zpuYW1lPkV4YW1wbGUgT25lPC9tYXJrOm5hbWU-PG1hcms6bGFiZWw-ZXh 563 hbXBsZS1vbmU8L21hcms6bGFiZWw-PG1hcms6bGFiZWw-ZXhhbXBsZW9uZ 564 TwvbWFyazpsYWJlbD48bWFyazppc3N1ZXI-SVAgQ2xlYXJpbmdob3VzZTw 565 vbWFyazppc3N1ZXI-PG1hcms6bnVtYmVyPkdFIDM5MzMyMzI8L21hcms6b 566 nVtYmVyPjxtYXJrOm51bWJlcj5vd25lcjwvbWFyazpudW1iZXI-PG1hcms 567 6cmVnRGF0ZT4yMDEyLTExLTI5VDE4OjE2OjU0LjA3NDZaPC9tYXJrOnJlZ 568 0RhdGU-PG1hcms6ZXhEYXRlPjIwMTItMTEtMjlUMTg6MTY6NTQuMDc0Nlo 569 8L21hcms6ZXhEYXRlPjxtYXJrOmNvdW50cnk-QVU8L21hcms6Y291bnRye 570 T48bWFyazpyZWdpb24-VklDPC9tYXJrOnJlZ2lvbj48L21hcms6bWFyaz4 571 8ZHNpZzpTaWduYXR1cmUgeG1sbnM6ZHNpZz0iaHR0cDovL3d3dy53My5vc 572 mcvMjAwMC8wOS94bWxkc2lnIyI-PGRzaWc6U2lnbmVkSW5mbz48ZHNpZzp 573 DYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3d 574 y53My5vcmcvVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUjV2l0aEN 575 vbW1lbnRzIi8-PGRzaWc6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0ia 576 HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8 577 -PGRzaWc6UmVmZXJlbmNlIFVSST0iI3NpZ25lZE1hcmsiPjxkc2lnOlRyY 578 W5zZm9ybXM-PGRzaWc6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d 579 3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1c 580 mUiLz48L2RzaWc6VHJhbnNmb3Jtcz48ZHNpZzpEaWdlc3RNZXRob2QgQWx 581 nb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc 582 2hhMSIvPjxkc2lnOkRpZ2VzdFZhbHVlPktIdVFrdFdUMnRYbXg4Y2ZWd2N 583 vZ0JSUm5oRT08L2RzaWc6RGlnZXN0VmFsdWU-PC9kc2lnOlJlZmVyZW5jZ 584 T48L2RzaWc6U2lnbmVkSW5mbz48ZHNpZzpTaWduYXR1cmVWYWx1ZT5RdWk 585 2d2xLVUlRcHMxS2N6ajhUaTVuNTBjaTVDc2pML2k2YjBwS0Z2NG16ZENhc 586 WpWcXVvVDFiSzJCZnhKNG0rbXJiOWxLeFlrVnNFCnB4QnloSG5KSHpSMXV 587 1MG1NMmt4VURyWkVCc0dpV3FuaHMzQVBxOTJBcVdGZHZnUmV6ZHcycmNVb 588 Vg3dGJyeWNGM3ZDMEJmRUg4RHoKb2FIUFRQb24xTUxObzF5bGtYTDA5bWJ 589 qTHVhRlJSS3Z2UCs4djQ1VFJXRmkrbVJ0akJvMGg4blFiNTNtR2lKaU1Oe 590 kFDaDBtK3pFeAp2bmxEUmRpdWJFZVVWbG9LV2dMY1BiSkd4QmFWL1gvQjQ 591 vRnVRbXEzclcxaXNZOUlEYzA3U3ZheEZ0a1l4emVra25GQkNCSWNibXFTC 592 nlOckMvOEp4Y2RRSHN0TUZWc1Z2SjdWUFJqS2VZM0RLcUwrTGhRPT08L2R 593 zaWc6U2lnbmF0dXJlVmFsdWU-PC9kc2lnOlNpZ25hdHVyZT48L3NtZDpza 594 WduZWRNYXJrPg 595 597 3. EPP Command Mapping 599 A detailed description of the EPP syntax and semantics can be found 600 in the EPP core protocol specification [RFC5730]. The command 601 mappings described here are specifically for use in the Launch Phase 602 Extension. 604 This mapping is designed to be flexible, requiring only a minimum set 605 of required elements. 607 While it is meant to serve several use cases, it does not prescribe 608 any interpretation by the client or server. Such processing is 609 typically highly policy-dependent and therefore specific to 610 implementations. 612 Operations on application objects are done via one or more of the 613 existing EPP verbs defined in the EPP domain name mapping [RFC5731]. 614 Registries may choose to support a subset of the operations. 616 3.1. EPP Command 618 This extension defines additional elements to extend the EPP 619 command and response to be used in conjunction with the EPP domain 620 name mapping [RFC5731]. 622 This extension defines a new command called the Claims Check Command 623 that is used to determine whether or not there are any matching 624 trademarks, in the specified launch phase, for each domain name 625 passed in the command. The availability check information defined in 626 the EPP domain name mapping [RFC5731] MUST NOT be returned for the 627 Claims Check Command. Instead of returning whether the domain name 628 is available the Claims Check Command will return whether or not at 629 least one matching trademark exists for the domain name. If there is 630 at least one matching trademark that exists for the domain name a 631 element is returned. The value of that the 632 element can be used with an info service of a third 633 party trademark provider like the Trademark Clearinghouse (TMCH) for 634 getting the information needed to generate the trademark claims 635 notice. The third party trademark provider should also return a 636 unique notice identifier that can be passed in the 637 element of the extension to the Create Command (Section 3.3). The 638 elements in the EPP command of EPP domain name 639 mapping [RFC5731] define the domain names to check for matching 640 trademarks. The element contains the following child 641 elements: 643 The phase with the value of "claims1" or "claims2" to 644 indicate it as a Claims Check Command. The "claims1" Claims 645 Check Command will match the against the full list 646 of trademark labels and the "claims2" Claims Check Command will 647 match the against the list of trademark labels that 648 opted into the "claims2" launch phase. 650 Example Claims Check Command using the domain command and the 651 extension to determine if "example1.tld" and 652 "example2.tld" have any matching trademarks during the "claims1" 653 launch phase. 655 656 657 658 659 661 example1.tld 662 example2.tld 663 664 665 666 668 claims1 669 670 671 ABC-12345 672 673 674 Example Claims Check Command using the domain command and the 675 extension to determine if "example3.tld" and 676 "example4.tld" have any matching trademarks that opted into the 677 "claims2" launch phase. 679 680 681 682 683 685 example3.tld 686 example4.tld 687 688 689 690 692 claims2 693 694 695 ABC-12345 696 697 699 If the command has been processed successfully, the EPP 700 element MUST contains a child element that 701 identifies the launch namespace. The element 702 contains the following child elements: 704 the phase with a value of "claims1" or "claims2" that 705 matches the associated Claims Check Command . 706 One or more elements that contain the 707 following child elements: 709 Contains the fully qualified name of the queried 710 domain name. This element MUST contain an "exists" attribute 711 whose value indicates if a matching trademark exists for the 712 domain name. A value of "1" or "true" means that a matching 713 trademark does exist for the claims launch phase. A value of 714 "0" or "false" means that a matching trademark does not 715 exist. 716 An OPTIONAL claim key that MAY be passed to an 717 info service of a third party trademark provider like the 718 Trademark Clearinghouse (TMCH) for getting the information 719 needed to generate the trademark claims notice. The is used as the key for the query in place of the 721 domain name to securely query the service without using a 722 well-known value like a domain name. 724 Example Claims Check Response when no matching trademarks are found 725 for the domain name example1.tld and matching trademarks are found 726 for the domain name example2.tld for the "claims1" launch phase. 728 729 730 731 732 Command completed successfully 733 734 735 737 claims1 738 739 example1.tld 740 741 742 example2.tld 743 abc123 744 745 746 747 748 ABC-12345 749 54322-XYZ 750 751 752 753 Example Claims Check Response when no matching trademarks are found 754 for the domain name example3.tld and matching trademarks are found 755 for the domain name example4.tld for the "claims2" launch phase. 757 758 759 760 761 Command completed successfully 762 763 764 766 claims2 767 768 example3.tld 769 770 771 example4.tld 772 abc123 773 774 775 776 777 ABC-12345 778 54322-XYZ 779 780 781 783 3.2. EPP Command 785 This extension defines additional elements to extend the EPP 786 command and response to be used in conjunction with the EPP domain 787 name mapping [RFC5731]. 789 The EPP command is used to retrieve information for a launch 790 phase registration or application. The Application Identifier 791 (Section 2.1) returned in the element of the Create 792 Response (Section 3.3) is used for retrieving information for a 793 launch application. A element is sent along with the 794 regular domain command. The element contains 795 the following child elements: 797 The phase during which the application or 798 registration was submitted or is associated with. Server policy 799 defines the phases that are supported. 800 OPTIONAL application identifier of the launch 801 application. 803 Example domain command with the extension to 804 retrieve information for the sunrise application for example.tld and 805 application identifier "abc123". 807 808 809 810 811 813 example.tld 814 815 816 817 819 sunrise 820 abc123 821 822 823 ABC-12345 824 825 826 Example domain command with the extension to 827 retrieve information for the sunrise registration for example.tld. 829 830 831 832 833 835 example.tld 836 837 838 839 841 sunrise 842 843 844 ABC-12345 845 846 848 If the query was successful, the server replies with an element along with the regular EPP . The contains the following child elements: 852 the phase during which the application was submitted 853 or is associated with that matches the associated command 854 . 855 OPTIONAL application identifier of the launch 856 application. 857 OPTIONAL status of the launch application using one 858 of the supported status values (Section 2.3). 859 zero or more elements. The 860 child elements are defined in the element 861 (Section 2.5) section. 863 Example domain response using the extension 864 with the mark information. 866 867 868 869 870 Command completed successfully 871 872 873 875 example.tld 876 EXAMPLE1-REP 877 878 jd1234 879 sh8013 880 sh8013 881 ClientX 882 ClientY 883 2012-04-03T22:00:00.0Z 884 885 2fooBAR 886 887 888 889 890 892 sunrise 893 abc123 894 895 897 Hello 898 IP Clearinghouse 899 GE 3933232 900 REG-TM-WORD 901 1 902 owner 903 2011-09-09 904 2011-10-09 905 2013-09-09 906 AU 907 VIC 908 909 Example Inc. 910 911 912 John Doe 913 Example Inc. 914 915 123 Example Dr. 916 Suite 100 917 Reston 918 VA 919 20190 920 US 921 922 +1.7035555555 923 +1.7035555556 924 jdoe@example.tld 925 926 927 928 929 930 ABC-12345 931 54322-XYZ 932 933 934 936 3.3. EPP Command 938 There are two forms of the extension to the EPP command that 939 are dependent on the supported launch phases (Section 2.2) as defined 940 below: 942 sunrise The EPP command with the "sunrise" launch phase is 943 used to submit an registration with trademark information that can 944 be verified by the server with the value. The 945 Sunrise Create Form (Section 3.3.1) is used for the "sunrise" 946 launch phase. Optionally, the server can support multiple 947 overlapping applications that are chosen asynchronously with a 948 server generated Application Identifier (Section 2.1) for later 949 reference. 950 landrush The EPP command with the "landrush" launch phase 951 is undefined but the form supported is up to server policy. 952 claims1 The EPP command with the "claims1" launch phase is 953 used to pass the information associated with the presentation and 954 acceptance of the "claims1" claims notice. The Claims Create Form 955 (Section 3.3.2) is used for the "claims1" launch phase. 956 claims2 The EPP command with the "claims2" launch phase is 957 used to pass the information associated with the presentation of 958 the "claims1" claims notice. The Claims Create Form 959 (Section 3.3.2) is used for the "claims2" launch phase. 960 open The EPP command with the "open" launch phase is 961 undefined but the form supported is up to server policy. 962 custom The EPP command with the "custom" launch phase is 963 undefined but the form supported is up to server policy. 965 3.3.1. Sunrise Create Form 967 The Sunrise Create Form of the extension to the EPP domain name 968 mapping [RFC5731] includes the verifiable trademark information that 969 the server uses to match against the domain name to authorize the 970 domain create. A server MUST support one of four models in Claim 971 Validation Models (Section 2.4) to verify the trademark information 972 passed by the client. 974 A element is sent along with the regular 975 domain command. The element contains the following 976 child elements: 978 The launch phase for the create like the "sunrise" 979 launch phase. 980 or or 981 zero or more elements. The 982 child elements are defined in the element (Section 2.4.1) section. 984 zero or more elements. The 985 child elements are defined in the element (Section 2.7.1) section. 987 zero or more 988 elements. The child elements are 989 defined in the element 990 (Section 2.7.2) section. 992 Following is an example domain command using the extension, following the "code" validation model, with 994 multiple sunrise codes. 996 997 998 999 1000 1002 example.tld 1003 jd1234 1004 sh8013 1005 sh8013 1006 1007 2fooBAR 1008 1009 1010 1011 1012 1014 sunrise 1015 1016 49FD46E6C4B45C55D4AC 1017 1018 1019 49FD46E6C4B45C55D4AD 1020 1021 1022 49FD46E6C4B45C55D4AE 1023 1024 1025 1026 ABC-12345 1027 1028 1030 Following is an example domain command using the extension, following the "mark" validation model, with the 1032 mark information. 1034 1035 1036 1037 1038 1040 exampleone.tld 1041 jd1234 1042 sh8013 1043 sh8013 1044 1045 2fooBAR 1046 1047 1048 1049 1050 1052 sunrise 1053 1054 1056 Example One 1057 example-one 1058 exampleone 1059 IP Clearinghouse 1060 GE 3933232 1061 REG-TM-WORD 1062 1 1063 owner 1064 2011-09-09 1065 2011-10-09 1066 2013-09-09 1067 AU 1068 VIC 1069 1070 Example Inc. 1071 1072 1073 John Doe 1074 Example Inc. 1075 1076 123 Example Dr. 1077 Suite 100 1078 Reston 1079 VA 1080 20190 1081 US 1082 1083 +1.7035555555 1084 +1.7035555556 1085 jdoe@example.tld 1086 1087 1089 1090 1091 1092 ABC-12345 1093 1094 1096 Following is an example domain command using the extension, following the "code with mark" validation model, 1098 with a code and mark information. 1100 1101 1102 1103 1104 1106 example.tld 1107 jd1234 1108 sh8013 1109 sh8013 1110 1111 2fooBAR 1112 1113 1114 1115 1116 1118 sunrise 1119 1120 49FD46E6C4B45C55D4AC 1121 1123 Hello 1124 IP Clearinghouse 1125 GE 3933232 1126 REG-TM-WORD 1127 1 1128 owner 1129 2011-09-09 1130 2011-10-09 1131 2013-09-09 1132 AU 1133 VIC 1134 1135 Example Inc. 1136 1137 1138 John Doe 1139 Example Inc. 1140 1141 123 Example Dr. 1142 Suite 100 1143 Reston 1144 VA 1145 20190 1146 US 1147 1148 +1.7035555555 1149 +1.7035555556 1150 jdoe@example.tld 1151 1152 1153 1154 1155 1156 ABC-12345 1157 1158 1160 Following is an example domain command using the extension, following the "signed mark" validation model, with 1162 the signed mark information. 1164 1165 1166 1167 1168 1170 exampleone.tld 1171 jd1234 1172 sh8013 1173 sh8013 1174 1175 2fooBAR 1176 1177 1178 1179 1180 1182 sunrise 1183 1185 123456 1186 2012-08-16T09:00:00.0Z 1187 1189 Example One 1190 example-one 1191 exampleone 1192 IP Clearinghouse 1193 GE 3933232 1194 REG-TM-WORD 1195 1 1196 owner 1197 2011-09-09 1198 2011-10-09 1199 2013-09-09 1200 AU 1201 VIC 1202 1203 Example Inc. 1204 1205 1206 John Doe 1207 Example Inc. 1208 1209 123 Example Dr. 1210 Suite 100 1211 Reston 1212 VA 1213 20190 1214 US 1215 1216 +1.7035555555 1217 +1.7035555556 1218 jdoe@example.tld 1219 1220 1221 1223 1224 1226 1228 1229 1230 1232 1233 1235 6651T5s9GZgQOxifdCFmDfSIoUc= 1236 1237 1238 1239 1240 Gm7RnEb6jcijKcgmwEmxJ6j1L0vt2wFyXv3oKc9a4b8nMOKdec8S3tG2hSx 1241 /NZa0RFHvx5zMsH/MjmxzrTBbl5d7W8Qql5VsW4XanSjJ+UgILs9k6XgVtZ 1242 E2EvffMLBiL4xbCJM48ewRYRY7lVEzoNms91pmm3U5IlNRNjU/YFqZ1pXhh 1243 rhyhPjSi9Uon8FnAJaiBEfHcjG6815IJV/9RT+MTXri7i0s82CqIS4wDGbG 1244 pyZAs7/kDY3A3upqSOwTtrFSCFX1F+Craec72lBB/dKJHxmoVkbIO5KQhqI 1245 Od+E+h2kguE++RHKa4xoBIeyTgWqpWcLuMoFpM+GxwFcpSA== 1246 1247 1248 1249 1250 1251 ABC-12345 1252 1253 1255 Following is an example domain command using the extension, following the "signed mark" validation model, with 1257 the base64 encoded signed mark information. 1259 1260 1261 1262 1263 1265 exampleone.tld 1266 jd1234 1267 sh8013 1268 sh8013 1269 1270 2fooBAR 1271 1272 1273 1274 1275 1277 sunrise 1278 1280 D94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c21kOnNpZ25 1281 lZE1hcmsgeG1sbnM6c21kPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNpZ25lZ 1282 E1hcmstMS4wIiBpZD0ic2lnbmVkTWFyayI-PHNtZDpzZXJpYWw-MTIzNDU2PC9 1283 zbWQ6c2VyaWFsPjxzbWQ6ZXhEYXRlPjIwMTItMTEtMjlUMTg6MTY6NTQuMDg4M 1284 Fo8L3NtZDpleERhdGU-PG1hcms6bWFyayB4bWxuczptYXJrPSJ1cm46aWV0Zjp 1285 wYXJhbXM6eG1sOm5zOm1hcmstMS4wIj48bWFyazpuYW1lPkV4YW1wbGUgT25lP 1286 C9tYXJrOm5hbWU-PG1hcms6bGFiZWw-ZXhhbXBsZS1vbmU8L21hcms6bGFiZWw 1287 -PG1hcms6bGFiZWw-ZXhhbXBsZW9uZTwvbWFyazpsYWJlbD48bWFyazppc3N1Z 1288 XI-SVAgQ2xlYXJpbmdob3VzZTwvbWFyazppc3N1ZXI-PG1hcms6bnVtYmVyPkd 1289 FIDM5MzMyMzI8L21hcms6bnVtYmVyPjxtYXJrOm51bWJlcj5vd25lcjwvbWFya 1290 zpudW1iZXI-PG1hcms6cmVnRGF0ZT4yMDEyLTExLTI5VDE4OjE2OjU0LjA3NDZ 1291 aPC9tYXJrOnJlZ0RhdGU-PG1hcms6ZXhEYXRlPjIwMTItMTEtMjlUMTg6MTY6N 1292 TQuMDc0Nlo8L21hcms6ZXhEYXRlPjxtYXJrOmNvdW50cnk-QVU8L21hcms6Y29 1293 1bnRyeT48bWFyazpyZWdpb24-VklDPC9tYXJrOnJlZ2lvbj48L21hcms6bWFya 1294 z48ZHNpZzpTaWduYXR1cmUgeG1sbnM6ZHNpZz0iaHR0cDovL3d3dy53My5vcmc 1295 vMjAwMC8wOS94bWxkc2lnIyI-PGRzaWc6U2lnbmVkSW5mbz48ZHNpZzpDYW5vb 1296 mljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmc 1297 vVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUjV2l0aENvbW1lbnRzIi8-P 1298 GRzaWc6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5 1299 vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8-PGRzaWc6UmVmZXJlbmNlI 1300 FVSST0iI3NpZ25lZE1hcmsiPjxkc2lnOlRyYW5zZm9ybXM-PGRzaWc6VHJhbnN 1301 mb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc 1302 2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48L2RzaWc6VHJhbnNmb3Jtcz48ZHN 1303 pZzpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yM 1304 DAwLzA5L3htbGRzaWcjc2hhMSIvPjxkc2lnOkRpZ2VzdFZhbHVlPktIdVFrdFd 1305 UMnRYbXg4Y2ZWd2NvZ0JSUm5oRT08L2RzaWc6RGlnZXN0VmFsdWU-PC9kc2lnO 1306 lJlZmVyZW5jZT48L2RzaWc6U2lnbmVkSW5mbz48ZHNpZzpTaWduYXR1cmVWYWx 1307 1ZT5RdWk2d2xLVUlRcHMxS2N6ajhUaTVuNTBjaTVDc2pML2k2YjBwS0Z2NG16Z 1308 ENhcWpWcXVvVDFiSzJCZnhKNG0rbXJiOWxLeFlrVnNFCnB4QnloSG5KSHpSMXV 1309 1MG1NMmt4VURyWkVCc0dpV3FuaHMzQVBxOTJBcVdGZHZnUmV6ZHcycmNVbVg3d 1310 GJyeWNGM3ZDMEJmRUg4RHoKb2FIUFRQb24xTUxObzF5bGtYTDA5bWJqTHVhRlJ 1311 SS3Z2UCs4djQ1VFJXRmkrbVJ0akJvMGg4blFiNTNtR2lKaU1OekFDaDBtK3pFe 1312 Ap2bmxEUmRpdWJFZVVWbG9LV2dMY1BiSkd4QmFWL1gvQjQvRnVRbXEzclcxaXN 1313 ZOUlEYzA3U3ZheEZ0a1l4emVra25GQkNCSWNibXFTCnlOckMvOEp4Y2RRSHN0T 1314 UZWc1Z2SjdWUFJqS2VZM0RLcUwrTGhRPT08L2RzaWc6U2lnbmF0dXJlVmFsdWU 1315 -PC9kc2lnOlNpZ25hdHVyZT48L3NtZDpzaWduZWRNYXJrPg 1316 1317 1318 1319 ABC-12345 1320 1321 1323 If the create was successful, the server MAY reply with the element along with the regular EPP to indicate the 1325 server generated Application Identifier (Section 2.1) when multiple 1326 applications of a given domain name is supported; otherwise no 1327 extension is included with the regular EPP . The element contains the following child elements: 1330 The phase of the application that mirrors the 1331 element included in the . 1332 the application identifier of the 1333 application. 1335 An example response when multiple overlapping applications are 1336 supported by the server. 1338 1339 1340 1341 1342 Command completed successfully 1343 1344 1345 1347 example.tld 1348 2010-08-10T15:38:26.623854Z 1349 2012-08-10T15:38:26.623854Z 1350 1351 1352 1353 1354 sunrise 1355 2393-9323-E08C-03B1 1356 1357 1358 1359 example:epp:239332 1360 server-8551292e23b 1361 1362 1363 1365 3.3.2. Claims Create Form 1367 The Claims Create Form of the extension to the EPP domain name 1368 mapping [RFC5731] includes the information related to the acceptance 1369 of the claims notice for the "claims1" launch phase and the display 1370 of the claims notice for the "claims2" launch phase. 1372 A element is sent along with the regular 1373 domain command. The element contains the following 1374 child elements: 1376 MUST contain the value of "claims1" or "claim2" to 1377 indicate the claims launch phase. 1378 1379 Unique notice identifier generated by the 1380 source of the claims notice information like the Claims 1381 Notice Information Service (CNIS). 1382 Contains the date and time that the claims 1383 notice was displayed or accepted. 1384 Contains the source information of the client 1385 that was displayed or that accepted the claims notice like 1386 the client IP address. 1388 Following is an example domain command using the extension with the information for the 1390 "claims1" claims launch phase. 1392 1393 1394 1395 1396 1398 example.tld 1399 jd1234 1400 sh8013 1401 sh8013 1402 1403 2fooBAR 1404 1405 1406 1407 1408 1410 claims1 1411 1412 49FD46E6C4B45C55D4AC 1413 2012-06-19T09:00:00.0Z 1414 192.0.2.29 1415 1416 1417 1418 ABC-12345 1419 1420 1422 This extension does not define any extension to the response of an 1423 domain command for the Claims Create Form. After processing 1424 the command, the server replies with a standard EPP response as 1425 defined in the EPP domain mapping. 1427 3.4. EPP Command 1429 This extension defines additional elements to extend the EPP 1430 command to be used in conjunction with the domain name mapping. 1432 A server that does not support allow multiple applications of a given 1433 domain name with a Application Identifier (Section 2.1) during its 1434 launch phase operations MUST return an EPP error result code of 2102. 1436 Registry policies permitting, clients may update an application 1437 object by submitting an EPP command along with an element to indicate the application object to be updated. 1439 The element contains the following child elements: 1441 the phase during which the application was submitted 1442 or is associated with. 1443 the application identifier for which the 1444 client wishes to update. 1446 This extension does not define any extension to the response of an 1447 domain command. After processing the command, the server 1448 replies with a standard EPP response as defined in the EPP domain 1449 mapping. 1451 Following is an example domain command with the extension to add and remove a name server of a sunrise 1453 application with the application identifier "abc123". 1455 1456 1457 1458 1459 1461 example.tld 1462 1463 1464 ns2.example.tld 1465 1466 1467 1468 1469 ns1.example.tld 1470 1471 1472 1473 1474 1475 1477 sunrise 1478 abc123 1479 1480 1481 ABC-12345 1482 1483 1484 An example response that corresponds to the above command. 1486 1487 1488 1489 1490 Command completed successfully 1491 1492 1493 example:epp:239333 1494 server-8551292e23c 1495 1496 1497 1499 3.5. EPP Command 1501 This extension defines additional elements to extend the EPP 1502 command to be used in conjunction with the domain name mapping. 1504 A server that does not support multiple applications of a given 1505 domain name with a Application Identifier (Section 2.1) during its 1506 launch phase operations MUST return an EPP error result code of 2102. 1508 Registry policies permitting, clients MAY withdraw an application by 1509 submitting an EPP command along with an 1510 element to indicate the application object to be deleted. The 1511 element contains the following child elements: 1513 the phase during which the application was submitted 1514 or is associated with. 1515 the application identifier for which the 1516 client wishes to delete. 1518 This extension does not define any extension to the response of an 1519 domain command. After processing the command, the server 1520 replies with a standard EPP response as defined in the EPP domain 1521 mapping. 1523 Following is an example domain command with the extension. 1526 1527 1528 1529 1530 1532 example.tld 1533 1534 1535 1536 1538 sunrise 1539 abc123 1540 1541 1542 ABC-12345 1543 1544 1546 An example response that corresponds to the above command. 1548 1549 1550 1551 1552 Command completed successfully 1553 1554 1555 example:epp:239334 1556 server-8551292e23d 1557 1558 1559 1561 3.6. EPP Command 1563 This extension does not define any extension to the EPP 1564 command or response described in the EPP domain name mapping 1565 [RFC5731]. 1567 3.7. EPP Command 1569 This extension does not define any extension to the EPP 1570 command or response described in the EPP domain name mapping 1572 [RFC5731]. 1574 4. Formal Syntax 1576 Three schemas are presented here. The first schema is the EPP Launch 1577 Phase Mapping schema. The second schema is a dependent schema for 1578 the Signed Mark. The third schema is a dependent schema for the 1579 Mark. 1581 The formal syntax presented here is a complete schema representation 1582 of the object mapping suitable for automated validation of EPP XML 1583 instances. The BEGIN and END tags are not part of the schema; they 1584 are used to note the beginning and ending of the schema for URI 1585 registration purposes. 1587 4.1. Launch Schema 1589 Copyright (c) 2012 IETF Trust and the persons identified as authors 1590 of the code. All rights reserved. 1592 Redistribution and use in source and binary forms, with or without 1593 modification, are permitted provided that the following conditions 1594 are met: 1596 o Redistributions of source code must retain the above copyright 1597 notice, this list of conditions and the following disclaimer. 1598 o Redistributions in binary form must reproduce the above copyright 1599 notice, this list of conditions and the following disclaimer in 1600 the documentation and/or other materials provided with the 1601 distribution. 1602 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1603 names of specific contributors, may be used to endorse or promote 1604 products derived from this software without specific prior written 1605 permission. 1607 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1608 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1609 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1610 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1611 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1612 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1613 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1614 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1615 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1616 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1617 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1619 BEGIN 1620 1621 1630 1633 1636 1639 1642 1643 1644 Extensible Provisioning Protocol v1.0 1645 domain name extension schema 1646 for the launch phase processing. 1647 1648 1650 1653 1654 1655 1656 1657 1659 1662 1663 1664 1665 1666 1668 1670 1673 1674 1675 1677 1683 1684 1685 1686 1687 1688 1689 1691 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1705 1708 1709 1710 1711 1712 1714 1717 1718 1719 1720 1721 1723 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1738 1741 1742 1743 1744 1746 1748 1749 1750 1751 1753 1757 1758 1759 1761 1764 1765 1767 1770 1771 1772 1773 1774 1776 1778 1780 1782 1783 1784 1786 1789 1790 1791 1792 1793 1794 1795 1797 1800 1801 1802 1803 1804 1806 1809 1810 1811 1812 1815 1816 1818 1821 1822 1823 1825 1828 1829 1830 1831 1833 1834 1836 1837 1838 1839 1841 1842 1844 1845 1846 1847 1849 1850 1851 1853 1856 1857 1858 1859 1862 1864 1866 1867 1869 1870 END 1872 4.2. Signed Mark Schema 1874 Copyright (c) 2012 IETF Trust and the persons identified as authors 1875 of the code. All rights reserved. 1877 Redistribution and use in source and binary forms, with or without 1878 modification, are permitted provided that the following conditions 1879 are met: 1881 o Redistributions of source code must retain the above copyright 1882 notice, this list of conditions and the following disclaimer. 1883 o Redistributions in binary form must reproduce the above copyright 1884 notice, this list of conditions and the following disclaimer in 1885 the documentation and/or other materials provided with the 1886 distribution. 1887 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1888 names of specific contributors, may be used to endorse or promote 1889 products derived from this software without specific prior written 1890 permission. 1892 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1893 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1894 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1895 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1896 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1897 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1898 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1899 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1900 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1901 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1902 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1904 BEGIN 1905 1906 1914 1917 1920 1923 1924 1925 Schema for representing a Signed Mark, also referred to 1926 as Signed Mark Data (SMD), that includes digitally 1927 signed trademark information. 1928 1929 1931 1934 1936 1939 1942 1945 1946 1947 1948 1950 1951 1952 1953 1954 1956 1959 1960 1961 1962 1964 1965 1966 1968 1969 END 1971 4.3. Mark Schema 1973 Copyright (c) 2012 IETF Trust and the persons identified as authors 1974 of the code. All rights reserved. 1976 Redistribution and use in source and binary forms, with or without 1977 modification, are permitted provided that the following conditions 1978 are met: 1980 o Redistributions of source code must retain the above copyright 1981 notice, this list of conditions and the following disclaimer. 1982 o Redistributions in binary form must reproduce the above copyright 1983 notice, this list of conditions and the following disclaimer in 1984 the documentation and/or other materials provided with the 1985 distribution. 1986 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1987 names of specific contributors, may be used to endorse or promote 1988 products derived from this software without specific prior written 1989 permission. 1991 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1992 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1993 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1994 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1995 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1996 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1997 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1998 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1999 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2000 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2001 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2003 BEGIN 2004 2005 2011 2012 2013 Schema for representing a Trademark, also referred to 2014 as Mark. 2015 2016 2018 2021 2023 2026 2027 2028 2030 2032 2034 2036 2038 2040 2042 2044 2046 2049 2051 2053 2055 2057 2059 2060 2062 2065 2066 2067 2068 2069 2070 2072 2075 2076 2077 2078 2079 2081 2084 2085 2086 2087 2088 2090 2093 2094 2095 2096 2097 2098 2099 2101 2104 2105 2106 2107 2108 2109 2111 2114 2115 2116 2118 2120 2122 2124 2126 2127 2129 2132 2133 2134 2135 2136 2138 2141 2142 2143 2145 2147 2149 2151 2153 2155 2156 2158 2159 END 2161 5. Acknowledgements 2163 [to be filled in] 2165 6. Change History 2167 6.1. Change from 00 to 01 2169 1. Changed to use camel case for the XML elements. 2170 2. Replaced "cancelled" status to "rejected" status. 2171 3. Added the child elements of the element. 2172 4. Removed the XML schema and replaced with "[TBD]". 2174 6.2. Change from 01 to 02 2176 1. Added support for both the ICANN and ARI/Neustar TMCH models. 2177 2. Changed the namespace URI and prefix to use "launch" instead of 2178 "launchphase". 2179 3. Added definition of multiple claim validation models. 2180 4. Added the and 2181 elements. 2182 5. Added support for Claims Info Command 2184 6.3. Change from 02 to 03 2186 1. Removed XSI namespace per Keith Gaughan's suggestion on the 2187 provreg list. 2189 2. Added extensibility to the launch:status element and added the 2190 pendingAuction status per Trung Tran's feedback on the provreg 2191 list. 2192 3. Added support for the Claims Check Command, updated the location 2193 and contents of the signedNotice, and replaced most references of 2194 Claim to Mark based on the work being done on the ARI/Neustar 2195 launch model. 2197 6.4. Change from 03 to 04 2199 1. Removed references to the ICANN model. 2200 2. Removed support for the Claims Info Command. 2201 3. Removed use of the signedClaim. 2202 4. Revised the method for referring to the signedClaim from the XML 2203 Signature using the IDREF URI. 2204 5. Split the launch-1.0.xsd into three XML schemas including launch- 2205 1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd. 2206 6. Split the "claims" launch phase to the "claims1" and "claims2" 2207 launch phases. 2208 7. Added support for the encodedSignedMark with base64 encoded 2209 signedMark. 2210 8. Changed the elements in the createNoticeType to include the 2211 noticeID, timestamp, and the source elements. 2212 9. Added the class and effectiveDate elements to mark. 2214 7. IANA Considerations 2216 This document uses URNs to describe XML namespaces and XML schemas 2217 conforming to a registry mechanism described in [RFC3688]. Three URI 2218 assignments have been registered by the IANA. 2220 Registration request for the Launch namespace: 2222 URI: urn:ietf:params:xml:ns:launch-1.0 2223 Registrant Contact: See the "Author's Address" section of this 2224 document. 2225 XML: None. Namespace URIs do not represent an XML specification. 2227 Registration request for the Signed mark namespace: 2229 URI: urn:ietf:params:xml:ns:signedMark-1.0 2230 Registrant Contact: See the "Author's Address" section of this 2231 document. 2232 XML: None. Namespace URIs do not represent an XML specification. 2234 Registration request for the Mark namespace: 2236 URI: urn:ietf:params:xml:ns:mark-1.0 2237 Registrant Contact: See the "Author's Address" section of this 2238 document. 2239 XML: None. Namespace URIs do not represent an XML specification. 2241 8. Security Considerations 2243 The mapping extensions described in this document do not provide any 2244 security services beyond those described by EPP [RFC5730], the EPP 2245 domain name mapping [RFC5731], and protocol layers used by EPP. The 2246 security considerations described in these other specifications apply 2247 to this specification as well. 2249 Updates to, and deletion of an application object must be restricted 2250 to clients authorized to perform the said operation on the object. 2252 As information contained within an application, or even the mere fact 2253 that an application exists may be confidential. Any attempt to 2254 operate on an application object by an unauthorized client MUST be 2255 rejected with an EPP 2303 (object does not exist) or an appropriate 2256 auhorization error. Server policy may allow operation with 2257 filtered output by clients other than the sponsoring client, in which 2258 case the and response SHOULD be 2259 filtered to include only fields that are publicly accessible. 2261 9. Normative References 2263 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2264 Extensions (MIME) Part One: Format of Internet Message 2265 Bodies", RFC 2045, November 1996. 2267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2268 Requirement Levels", BCP 14, RFC 2119, March 1997. 2270 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2271 January 2004. 2273 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2274 STD 69, RFC 5730, August 2009. 2276 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2277 Domain Name Mapping", STD 69, RFC 5731, August 2009. 2279 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 2280 Contact Mapping", STD 69, RFC 5733, August 2009. 2282 [WIPO.ST3] 2283 WIPO, "Recommended standard on two-letter codes for the 2284 representation of states, other entities and 2285 intergovernmental organizations", March 2007. 2287 [1] 2290 [2] 2292 [3] 2294 Authors' Addresses 2296 Wil Tan 2297 Cloud Registry 2298 Suite 32 Seabridge House 2299 377 Kent St 2300 Sydney, NSW 2000 2301 AU 2303 Phone: +61 414 710899 2304 Email: wil@cloudregistry.net 2305 URI: http://www.cloudregistry.net 2307 Gavin Brown 2308 CentralNic Ltd 2309 35-39 Mooregate 2310 London, England EC2R 6AR 2311 GB 2313 Phone: +44 8700 170 900 2314 Email: gavin.brown@centralnic.com 2315 URI: http://www.centralnic.com 2317 James Gould 2318 VeriSign, Inc. 2319 12061 Bluemont Way 2320 Reston, VA 20190 2321 US 2323 Email: jgould@verisign.com 2324 URI: http://www.verisigninc.com