idnits 2.17.1 draft-tan-epp-launchphase-00.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 == Line 154 has weird spacing: '...lidated the a...' == Line 158 has weird spacing: '...located one o...' == Line 162 has weird spacing: '...ncelled the o...' -- The document date (April 13, 2011) is 4761 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: Experimental G. Brown 5 Expires: October 15, 2011 CentralNic Ltd 6 April 13, 2011 8 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) 9 draft-tan-epp-launchphase-00 11 Abstract 13 This document describes an Extensible Provisioning Protocol (EPP) 14 extension mapping for the provisioning and management of domain names 15 during the launch phase of a domain name registry. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 15, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 53 2. Application Object . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Element . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Element . . . . . . . . . . . . . . . . . . . 4 56 2.2.1. State Transition . . . . . . . . . . . . . . . . . . . 5 57 2.3. Trademark Elements . . . . . . . . . . . . . . . . . . . . 5 58 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 6 60 3.2. EPP Command . . . . . . . . . . . . . . . . . . . . 6 61 3.2.1. Client Processing Considerations . . . . . . . . . . . 7 62 3.2.2. Example command . . . . . . . . . . . . . . . . 7 63 3.3. EPP Command . . . . . . . . . . . . . . . . . . . 9 64 3.3.1. Example command . . . . . . . . . . . . . . . 10 65 3.3.2. Client Processing Considerations . . . . . . . . . . . 11 66 3.4. EPP Command . . . . . . . . . . . . . . . . . . . 11 67 3.4.1. Server Processing Considerations . . . . . . . . . . . 12 68 3.4.2. Example command . . . . . . . . . . . . . . . 13 69 3.5. EPP Command . . . . . . . . . . . . . . . . . . . 14 70 3.5.1. Server Processing Considerations . . . . . . . . . . . 14 71 3.5.2. Example command . . . . . . . . . . . . . . . 15 72 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 15 73 3.7. EPP Command . . . . . . . . . . . . . . . . . . 16 74 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 This document describes an extension mapping for version 1.0 of the 84 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 85 specifies a flexible schema that can be used to implement several 86 common use cases related to the provisioning and management of launch 87 phase extension in a domain name registry. 89 It is typical for domain registries to operate in a special mode 90 within a certain period of time to facilitate allocation of domain 91 names for a subset of the zone namespace that becomes available. 92 This document uses the term "launch phase" to refer to such a period. 94 The EPP domain name mapping [RFC5731] is designed for the steady 95 state operation of a registry. During a launch phase, however, 96 registries typically accept multiple applications for a given domain 97 name. This document proposes an extension to the domain name 98 extension in order to unambiguously manage the received applications. 100 1.1. Conventions Used in This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 XML is case sensitive. Unless stated otherwise, XML specifications 107 and examples provided in this document MUST be interpreted in the 108 character case presented in order to develop a conforming 109 implementation. 111 "launchphase-1.0" is used as an abbreviation for 112 "urn:ietf:params:xml:ns:launchphase-1.0". The XML namespace prefix 113 "lp" is used, but implementations MUST NOT depend on it and instead 114 employ a proper namespace-aware XML parser and serializer to 115 interpret and output the XML documents. 117 2. Application Object 119 It is common for domain registries to allow multiple applications of 120 a given domain name during its launch phase operations. 122 Upon receiving a request to create a domain, the server creates an 123 application object corresponding to the request and assigns an 124 identifier for the application and returns it to the client. This 125 mapping defines an "application_id" element for this purpose. 127 In order to facilitate correlation, all subsequent operations on the 128 domain object MUST be qualified by the previously assigned 129 application_id. 131 To support common use cases of launch phase operations, this mapping 132 also defines several other elements that may be used in 133 implementations. 135 2.1. Element 137 To allow for multiple launch phases, the application object MAY also 138 include an element whose content is a server-defined 139 opaque identifier corresponding to each launch phase. Depending on 140 the policy of the domain registry, the phase may be implicit (based 141 on the time of request or encoded as part of the application_id) or 142 explicitly required. 144 2.2. Element 146 The element is used to convey extended status(es) pertaining 147 to the application object, beyond what is specified in the object 148 mapping to which this application object represents. 150 The following status values are defiend: 152 pending the initial state of a newly-created application object. 154 validated the application meets relevant registry rules. 156 invalid the application does not validate according to registry rules 158 allocated one of two possible end states of an application object; 159 the object corresponding to the application has been 160 provisioned 162 cancelled the other possible end state; the object was not 163 provisioned 165 Certain status values MAY be combined. For example, an application 166 can be invalid and cancelled. [[Q1: Should we allow multiples? 167 --WT]] 169 2.2.1. State Transition 171 | request 172 v 173 +---------+ 174 | pending | 175 +----+----+ 176 | 177 | 178 +--------------+-----+-----------+--------------+ 179 | | | | 180 v v v v 181 +-----------+ +---------+ +-------+ +-------+ 182 | | | | / \ / \ 183 | validated | | invalid +----->| cancelled | | allocated | 184 | | | | \ / \ / 185 +----+------+ +----+----+ +-------+ +-------+ 186 | | ^ ^ 187 | | | | 188 | +-----------------+ | 189 | | | 190 +---------------------------------+ | 191 | | 192 +------------------------------------------------+ 194 Figure 1 196 2.3. Trademark Elements 198 Several optional trademark elements are defined: 200 o registered trademark 202 o registration number for the given trademark 204 o locality in which the trademark was registered 206 o capacity of the registrant in regards to the ownership or rights 207 to use the given trademark 209 o pre-verified code assigned by a third party verification service 210 to indicate trademark information that has been previously 211 validated. 213 3. EPP Command Mapping 215 This mapping is designed to be flexible, requiring only a minimum set 216 of required elements. 218 While it is meant to serve several use cases, it does not prescribe 219 any interpretation by the client or server. Such processing is 220 typically highly policy-dependent and therefore specific to 221 implementations. 223 Operations on application objects are done via one or more of the 224 existing EPP verbs defined in the EPP domain mapping. Registries may 225 choose to support a subset of the operations. 227 3.1. EPP Command 229 This extension does not define any extension to the EPP 230 command or response described in the EPP domain name mapping 231 [RFC5731]. 233 3.2. EPP Command 235 This extension defines additional elements to extend the EPP 236 command and response to be used in conjunction with the domain name 237 mapping. 239 In order to indicate that the query is meant for an application 240 object, an element is sent along with the regular 241 domain command. The element contains the following child 242 elements: 244 the application identifier for which the client 245 wishes to query. 247 (optional) the phase during which the application was 248 submitted or is associated with. 250 If the query was successful, the server replies with an 251 element along with the regular EPP . The the application identifier of the returned 255 application. 257 (optional) the phase during which the application was 258 submitted or is associated with. 260 (optional) status of the application. 262 (optional) registered trademark 264 (optional) registration number for the given 265 trademark 267 (optional) locality in which the trademark 268 was registered 270 (optional) capacity of the registrant in 271 regards to the ownership or rights to use the given trademark 273 (optional) pre-verified code assigned by a third party 274 verification service to indicate trademark information that 275 has been previously validated. 277 3.2.1. Client Processing Considerations 279 The client MUST ensure that any successful command results in 280 a response that an element is returned in the response. 281 This serves as a cross check that the server did receive the query 282 for the application (and not a domain of the same name) and processed 283 it as it was intended. 285 3.2.2. Example command 287 Following is an example domain command with the 288 extension. 290 291 292 293 294 296 example.tld 297 298 299 300 301 2393-9323-E08C-03B1 302 phase1 303 304 305 example:epp:239331 306 307 308 An example response that corresponds to the above command. 310 311 312 313 314 Command completed successfully 315 316 317 319 example.tld 320 32302393_TESTDOMAIN-TLD 321 322 ga3000 323 ue312987 324 ue312987 325 ue312987 326 327 ns1.example.com 328 ns2.example.net 329 330 client1 331 client1 332 2010-09-18T06:12:39.0Z 333 334 foo!bar#baz 335 336 337 338 339 340 2393-9323-E08C-03B1 341 phase1 342 343 Hello 344 GE 3933232 345 AU 346 owner 347 3828590-P1F-932391651E3A2900338C12 348 349 350 351 example:epp:239331 352 server-8551292e23a 353 354 355 357 3.3. EPP Command 359 This extension defines additional elements to extend the EPP 360 command and response to be used in conjunction with the domain name 361 mapping. 363 The EPP command is used to create an application. Typically 364 additional information is required to submit a domain name 365 application during a launch phase. This extension introduces an to encapsulate commonly used fields. Another use case that 367 extension addresses is the plausible need for a registry to 368 distinguish between multiple (possibly concurrent) launch phases. 369 Clients may specify the in which the application is meant 370 to be submitted. The element contains the following 371 child elements. 373 (optional) the phase during which the application was 374 submitted or is associated with. 376 (optional) registered trademark 378 (optional) registration number for the given 379 trademark 381 (optional) locality in which the trademark 382 was registered 384 (optional) capacity of the registrant in 385 regards to the ownership or rights to use the given trademark 387 (optional) pre-verified code assigned by a third party 388 verification service to indicate trademark information that 389 has been previously validated. 391 Upon successful processing, the server assigns an application 392 identifier and returns it in an element together with 393 the regular . The element contains a single 394 element as described below: 396 the application identifier assigned by the 397 server. 399 3.3.1. Example command 401 Following is an example domain command with the 402 extension. 404 405 406 407 408 410 example.tld 411 2 412 413 ns1.example.com 414 ns2.example.net 415 416 ga3000 417 ue312987 418 ue312987 419 ue312987 420 421 foo!bar#baz 422 423 424 425 426 427 phase1 428 Hello 429 GE 3933232 430 AU 431 owner 432 3828590-P1F-932391651E3A2900338C12 433 434 435 example:epp:239332 436 437 438 An example response that corresponds to the above command. 440 441 442 443 444 Command completed successfully 445 446 447 449 example.tld 450 2010-08-10T15:38:26.623854Z 451 2012-08-10T15:38:26.623854Z 452 453 454 455 456 2393-9323-E08C-03B1 457 458 459 460 example:epp:239332 461 server-8551292e23b 462 463 464 466 3.3.2. Client Processing Considerations 468 The client MUST ensure that any successful command results in 469 a response that an element is returned in the response. 470 This serves as a cross check that the server did receive the query 471 for the application (and not a domain of the same name) and processed 472 it as it was intended. 474 3.4. EPP Command 476 This extension defines additional elements to extend the EPP 477 command to be used in conjunction with the domain name mapping. 479 Registry policies permitting, clients may update an application 480 object by submitting an EPP command along with an element to indicate the application object to be updated. 482 The element contains the following child elements: 484 the application identifier for which the client 485 wishes to update. 487 (optional) the phase during which the application was 488 submitted or is associated with. 490 This extension does not define any extension to the response of an 491 domain command. After processing the command, the server 492 replies with a standard EPP response as defined in the EPP domain 493 mapping. 495 3.4.1. Server Processing Considerations 497 A server implementation that conforms to this specification MUST 498 respect and process the section, if present, and MUST 499 respond with an error if the application_id does not correspond with 500 the domain name in the element. 502 3.4.2. Example command 504 Following is an example domain command with the 505 extension. 507 508 509 510 511 513 example.tld 514 515 516 ns3.example.org 517 518 519 520 521 ns2.example.net 522 523 524 525 n3o2999 526 527 528 529 530 531 2393-9323-E08C-03B1 532 phase1 533 534 535 example:epp:239333 536 537 538 An example response that corresponds to the above command. 540 541 542 543 544 Command completed successfully 545 546 547 example:epp:239333 548 server-8551292e23c 549 550 551 553 3.5. EPP Command 555 This extension defines additional elements to extend the EPP 556 command to be used in conjunction with the domain name mapping. 558 Registry policies permitting, clients may withdraw an application by 559 submitting an EPP command along with an element 560 to indicate the application object to be deleted. The 561 element contains the following child elements: 563 the application identifier for which the client 564 wishes to delete. 566 (optional) the phase during which the application was 567 submitted or is associated with. 569 This extension does not define any extension to the response of an 570 domain command. After processing the command, the server 571 replies with a standard EPP response as defined in the EPP domain 572 mapping. 574 3.5.1. Server Processing Considerations 576 A server implementation that conforms to this specification MUST 577 respect and process the section, if present, and MUST 578 respond with an error if the application_id does not correspond with 579 the domain name in the element. 581 Depending on the server policy, an implementation may choose to 582 delete the application object immediately if business rules allow. 583 In that case, the server MUST respond with an EPP 1000 result code. 584 Alternatively, the server may choose to cancel the application 585 object, in which case it SHOULD respond with an EPP 1001 result code 586 to indicate that the object will be purged at a later date. 588 3.5.2. Example command 590 Following is an example domain command with the 591 extension. 593 594 595 596 597 599 example.tld 600 601 602 603 604 2393-9323-E08C-03B1 605 phase1 606 607 608 example:epp:239334 609 610 612 An example response that corresponds to the above command. 614 615 616 617 618 Command completed successfully 619 620 621 example:epp:239334 622 server-8551292e23d 623 624 625 627 3.6. EPP Command 629 This extension does not define any extension to the EPP 630 command or response described in the EPP domain name mapping 631 [RFC5731]. 633 3.7. EPP Command 635 This extension does not define any extension to the EPP 636 command or response described in the EPP domain name mapping 637 [RFC5731]. 639 4. Formal Syntax 641 Following is the content of "launchphase-1.0.xsd" 643 644 649 650 651 Extensible Provisioning Protocol v1.0 652 domain name extension schema for launch phase processing. 653 654 656 657 658 659 660 662 663 664 665 667 669 671 673 675 676 678 679 680 681 682 683 685 686 687 688 689 691 692 693 694 695 696 698 699 700 701 702 703 705 706 707 708 709 710 712 713 714 715 716 717 718 719 721 724 725 727 728 729 730 731 733 734 735 736 737 738 740 742 744 746 748 749 750 752 5. Acknowledgements 754 [to be filled in] 756 6. IANA Considerations 758 This document uses URNs to describe XML namespaces and XML schemas 759 conforming to a registry mechanism described in [RFC3688]. 761 Two URI assignments have been completed by the IANA. 763 Registration request for the extension namespace: 765 URI: urn:ietf:params:xml:ns:launchphase-1.0 767 Registrant Contact: IESG 769 XML: None. Namespace URIs do not represent an XML specification. 771 Registration request for the extension XML schema: 773 URI: urn:ietf:params:xml:schema:launchphase-1.0 775 7. Security Considerations 777 The mapping extensions described in this document do not provide any 778 security services beyond those described by EPP [RFC5730], the EPP 779 domain name mapping [RFC5731], and protocol layers used by EPP. The 780 security considerations described in these other specifications apply 781 to this specification as well. 783 Updates to, and deletion of an application object must be restricted 784 to clients authorized to perform the said operation on the object. 786 As information contained within an application, or even the mere fact 787 that an application exists may be confidential. Any attempt to 788 operate on an application object by an unauthorized client MUST be 789 rejected with an EPP 2303 (object does not exist) or an appropriate 790 auhorization error. Server policy may allow operation with 791 filtered output by clients other than the sponsoring client, in which 792 case the and response SHOULD be 793 filtered to include only fields that are publicly accessible. 795 8. Normative References 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 801 January 2004. 803 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 804 STD 69, RFC 5730, August 2009. 806 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 807 Domain Name Mapping", STD 69, RFC 5731, August 2009. 809 Authors' Addresses 811 Wil Tan 812 Cloud Registry 813 Suite 32 Seabridge House 814 377 Kent St 815 Sydney, NSW 2000 816 AU 818 Phone: +61 414 710899 819 Email: wil@cloudregistry.net 820 URI: http://www.cloudregistry.net 822 Gavin Brown 823 CentralNic Ltd 824 35-39 Mooregate 825 London, England EC2R 6AR 826 GB 828 Phone: +44 8700 170 900 829 Email: gavin.brown@centralnic.com 830 URI: http://www.centralnic.com