idnits 2.17.1 draft-ietf-provreg-epp-container-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 59 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2002) is 7804 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 40 -- Looks like a reference, but probably isn't: 'EPP' on line 1861 == Unused Reference: '1' is defined on line 1870, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Eric Brunner-Williams 3 Internet-Draft Editor 4 May, 2002 Expires December 2002 6 Extensible Provisioning Protocol Container 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo defines an extension to EPP objects. The extension 33 supports hierarchy and inheritance amongst EPP objects. 35 Conventions Used In This Document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119]. 41 The convention "TRY" is used for identifiers which incorporate the 42 mnemonic acronymn for a registry, or the word "REGISTRY" is spelled 43 out. The convention "ANT" is used for identifiers which incorporate 44 the mnemonic acronymn for a registrar, or the word "REGISTRAR" is 45 spelled out. The case-independent and optionally hypenated example 46 "FooCorp" is used throughout as an example. 48 Table of Contents 50 Status of this Memo ............................................ 1 51 Copyright Notice ............................................... 1 52 Abstract ....................................................... 1 53 Table of Contents .............................................. 2 54 1. Introduction ................................................ 2 55 2. Containers .................................................. 3 56 2.1 EPP Command Summary for Containers ...................... 5 57 2.1.1 Container Query Commands ........................... 5 58 2.1.2 Container Transformation Commands .................. 5 59 2.2 EPP Commnand for Managing Objects with Containers ....... 5 60 2.3 Container Templates ..................................... 6 61 2.4 Container Attributes .................................... 8 62 2.5 Status Values ........................................... 11 63 3. EPP Command Mapping for Container ........................... 11 64 3.1 EPP Query Commands ...................................... 11 65 3.1.1 EPP Command ................................ 11 66 3.1.2 EPP Command ................................. 14 67 3.1.3 EPP Command ............................. 17 68 3.2 EPP Transform Commands .................................. 19 69 3.2.1 EPP Command ............................... 19 70 3.2.2 EPP Command ............................... 21 71 3.2.3 EPP Command ................................ 23 72 3.2.4 EPP Command ............................. 23 73 3.2.5 EPP Command ............................... 25 74 3.3 Formal Syntax for Container ............................. 27 75 4. EPP Command Mapping for Objects with Containers ............. 34 76 4.1 EPP Command for Domain Object With Container ... 34 77 4.2 EPP Command for Domain Object With Container ... 35 78 4.3 EPP Command for Domain Object With Container ..... 36 79 4.4 Formal Syntax for Domain Object with Container .......... 37 80 5. Internationalization Considerations ......................... 39 81 6. IANA Considerations ......................................... 39 82 7. Security Considerations ..................................... 40 83 References ..................................................... 40 84 Editor's Address ............................................... 40 85 Full Copyright Statement ....................................... 40 86 Acknowledgement ................................................ 41 88 1. Introduction 90 The Extensible Provisioning Protocol [2] defines generic object 91 management operations and an extensible framework that maps protocol 92 operations to objects stored in a shared central repository. 94 This memo documents how these generic object management operations 95 are extended to hierarchies of objects, called container objects or 96 containers. 98 This memo is being discussed on the "ietf-provreg" mailing list. To 99 join the list, send a message to with the words 100 "subscribe ietf-provreg" in the body of the message. There is a web 101 site for the list archives at http://www.cafax.se/ietf-provreg. 103 2. Containers 105 A container object is a collection of objects defined by a registry. 106 A container object may contain any number of these defined objects, 107 and may also contain other containers in a nested fashion. 108 Containers simplify administration and management of associated 109 objects. 111 Each object in a collection of objects in a container maintains a 112 parent-child relationship with the container. The collection of 113 containers and the objects are managed in a tree/forest fashion with 114 one root container node. In a Container tree, non-leaf nodes are 115 container objects, leaf nodes are other objects. Each object in the 116 collection of a container will maintain a link to its parent 117 container. A container without a parent container is the root node 118 of a container tree. 120 Each child container inherits properties from the parent container. 121 Additionally, each container derives properties from its directly 122 associated leaf child object nodes, which override any mutual 123 exclusive inherited properties. For root containers the properties 124 are the properties of its directly associated leaf child object nodes 125 alone. 127 This inheritance of properties among associated containers restricts 128 containers to a single parent, or no parent in the case of the root 129 container. Non-leaf nodes (containers) may maintain references to 130 leaf-notes without restriction. Restated, a container can only have 131 at most one parent container, and zero or more child containers. 133 Mutual exclusion of objects contained in registries and references to 134 objects in multiple containers may be defined by the registry. 135 Example Container: 137 +-------------+ 138 | Container 1 | 139 +------+------+ 140 | 141 --------------+----+----------------------+ 142 | | | 144 +------+-------+ +-------+-------+ +------+------+ 145 | Registrant 1 | | Host 1 | | Container 2 | 146 +--------------+ +---------------+ +------+------+ 147 | 148 +-----------------+----------------+ 149 | | | 150 +------+------+ +--------------+ +------+------+ 151 | Container 3 | | Contact 1 | | Container 4 | 152 +------+------+ +--------------+ +-------------+ 153 | ... 154 +-------------+----+----------------+ 155 | | | 156 +------+-------+ +-------+-------+ +-----+-----+ 157 | Host 2 | | Registrant 2 | | Contact 2 | 158 +--------------+ +---------------+ +-----------+ 160 Figure 1: An Example of Container Tree 162 Container 1 has the properties: 164 "Registrant 1" 165 "Host 1" 167 Container 2 inherits the Container 1 properties and its child 168 objects. 170 "Registrant 1" 171 "Host 1" 172 "Contact 1" 174 The derivation of Container 3, assuming the registry policy of type 175 Container 3 is Unique Registrant, evaluates as: 177 "Registrant 2" 178 "Contact 1" 179 "Contact 2" 180 "Host 1" 181 "Host 2" 183 This example shows property derivation with a local policy 184 (registrant 2 preference). 186 2.1 EPP Command Summary for Containers 188 2.1.1 Container Query Commands 190 check 191 check on a container 193 info 194 query the collection of objects using a container object 196 transfer query 197 query the status of a container transfer command 199 2.1.2 Container Transformation Commands 201 create 202 create a container 204 delete 205 delete a container 207 update 208 update a container (add/remove objects) 210 update 211 update a collection of associated objects by updating properties 212 of a container object 214 delete 215 delete a container with an option to delete all associated 216 objects. 218 transfer 219 transfer a container with an option to transfer all associated 220 objects. 222 transfer 223 transfer a container with an option to transfer all directly 224 associated leaf child objects and child containers. 226 transfer 227 transfer a container with an option to transfer both linked 228 objects and directly associated leaf child objects and child 229 containers. 231 2.2 EPP Command for Managing Objects with Containers 233 A detailed description of the EPP syntax and semantics can be found 234 in [2]. The extended command mappings summarized here are described 235 in section 5. 237 2.3 Container Templates 239 Each container can be subjected to a set of registry policies by 240 binding a container to a template supported by Registry. Templates 241 are well-documented Registry policies that determine the functions 242 and objects supported in a container. 244 Example Templates 246 Registrant Template 248 supports child objects: 249 o registrant 250 o contacts (multiple type associations: admin, tech, billing), 251 o hosts (1-13), 252 o domain and/or registrant containers 254 supports functions/commands: 255 o create a registrant container with supported child objects, 256 o create associated objects (domains, registrant container) using the 257 registrant container, 258 o update container add/delete 259 registrant, 260 contacts (admin, tech, billing), 261 hosts (1-13), 262 container 263 o update container with an option to update associated objects 264 o delete container 265 o delete container with an option to delete all associated objects 266 o update add/delete other registrant containers, domain containers 267 o transfer a container to a different registrar 268 o transfer a container to a different registrar along with associated 269 objects 271 Domain Template 273 support child objects: 274 o domains, 276 supports functions/commands to: 277 o create a domain container with supported child objects 278 o create a domain container under a registrant template 279 and supported child objects 280 o create a domain container using a registrant template 281 and supported child objects 282 o update container add/delete domains or other domain container 283 o transfer a container to a different registrar 284 o transfer a container to a different registrar along with child 285 objects 286 o delete a container 287 o delete a container with an option to delete all child objects 289 Registrar Account Template 291 support child objects: 292 o contacts, 293 o hosts (1-13), 294 o registrant containers 296 supports functions/commands to: 297 o create a registrant account container with supported child 298 objects. 299 o create associated objects (registrant containers) 300 o update container add/delete any of the child objects 301 o delete container 302 o delete container with an option to delete all associated objects 304 Registrant Account Template 306 A Registrant Account Template can be used to group various objects or 307 containers into a single aggregation. However, objects or containers 308 in the registry should only belong to at most one container created 309 with the Registrant Account Template. 311 support child objects: 312 o domain objects, 313 o host objects, 314 o contact objects, 315 o registrant containers, 316 o domain containers 318 supports functions/commands to: 319 o create a registrant account template with supported child objects 320 o update container add/delete any supported child objects 321 o delete a container 322 o delete a container with an option to delete all child objects 323 o transfer a container to a different registrar 325 2.4 Container Attributes 327 An EPP container object has attributes and associated values that may 328 be viewed and modified by the sponsoring client or the server. This 329 section describes each attribute type in detail. 331 id 332 This element is the unique identifier of the container given by 333 the registrar. The format is alphanumeric with the minimum and 334 maximum length and character set specified in the XML [3] Schema 335 Definition [4], [5]. 337 Example: 339 ANT-CONTAINER-42 341 roid 342 This element is the unique identifier of the container given by 343 the registry. Container identifiers use the "roidType" syntax 344 described in [2]. 346 Example: 348 CONTAINER001-TRY 350 status 351 This element describes the status of the container. This element 352 may have multiple occurrences. 354 Example: 356 357 359 parent 360 This element is the reference of the parent container object in 361 the container tree by its . This element is optional and if 362 not specified the container is the root node of the tree. 364 The format is alphanumeric with the minimum and maximum length and 365 character set specified in the XML [3] Schema Definition [4], [5]. 367 Example: 369 00-CONT-21 371 template 372 This optional element is the registry provided template for 373 creating containers. For a given template there are set of 374 Registry defined policies for supported objects in a template and 375 other validations for a container. 377 The format is alphanumeric with the minimum and maximum length and 378 character set specified in the XML [3] Schema Definition [4], [5]. 380 Example: 382 384 child 385 This element is the reference to objects in the container. This 386 element may have multiple occurrences. The child element in a 387 container has attribute "obj" and optional "type" to reflect 388 supported object types and optional type of association. The 389 object types include all registry supported objects including 390 containers. 392 Example: 394 foo-corp-corp 395 foo-corp-admin 397 derived 398 This element is the reference to objects inherited from ancestor 399 containers. This element may have multiple occurrences. The 400 derived element in a container has attribute "container", "object" 401 and optional "type" to reflect the container from which the object 402 is inherited, object type, and optional type of association. The 403 object types include all registry supported objects. 405 Example: 407 foo-corp-corp 409 411 foo-corp-admin 414 416 linked 417 This element is the reference to other objects linked to this 418 container. These are the objects created using container 419 properties. Updates made to a container will result in updates to 420 all linked objects. The "linked" element has attribute "type" to 421 reflect the type of the linked object. 423 Example: 425 foo-corp-corp 426 foo-corp-admin 428 clID 429 This element contains the identifier of the sponsoring registrar. 430 The sponsoring registrar client has all the necessary 431 administrative privileges to manage the object. 433 Example: 435 clientXX 437 crID 438 This element contains the reference to the registrar client that 439 created the container. 441 Example: 443 clientXX 445 crDate 446 This element contains the reference to the date the container was 447 created. The format of the time field is UCT extended format of 448 ISO 8601. 450 Example: 452 2001-07-04:00:00.0Z 454 upID 455 This element contains the reference to the registrar client that 456 modified the container. 458 Example: 460 clientXX 462 upDate 463 This element contains the reference to the date the container was 464 modified. The format of the time field is UCT extended format of 465 ISO 8601. 467 Example: 469 2001-07-04:00:00.0Z 471 trDate 472 This element contains the reference to the date the container was 473 transferred. The format of the time field is UCT extended format 474 of ISO 8601. 476 Example: 478 2001-07-04:00:00.0Z 480 authInfo 481 This element contains information associated with containers to 482 facilitate transfer operations. Authorization information is 483 assigned when a container is created, and it MAY be updated in the 484 future. This specification describes password or certificate- 485 based authorization information, though other mechanisms are 486 possible. 488 Example: 490 2fooBAR 492 2.5 Status Values 494 A container object MUST always have at least one associated status 495 value. Status values MAY be set only by the client that sponsors a 496 domain object and by the server on which the container resides. A 497 client MAY change the status of a container object using the EPP 498 command. Each status value MAY be accompanied by a string 499 of human-readable text that describes the rationale for the status 500 applied to the container. 502 Status value Descriptions: 504 active 505 Supports updates and usage in transactions. 507 inactive 509 Does not support updates or usage in transactions. 511 pendingTransfer 512 A transfer request has been received for the container, and 513 completion of the request is pending. Container transformation 514 commands other than MUST be rejected while a container 515 is in this state. 517 pendingDelete 518 A delete request has been received for the container, but the 519 container has not yet been purged from the server database. 521 TransferProhibited, clientTransferProhibited 522 Requests to transfer the container MUST be rejected. 524 UpdateProhibited, clientUpdateProhibited 525 Requests to update the container MUST be rejected. 527 DeleteProhibited, clientDeleteProhibited 528 Requests to delete the container MUST be rejected. 530 linked 531 The container has at least one active association, such as a 532 domain object of another container. Servers SHOULD provide 533 services to determine existing object associations. 535 ok 536 This is the nominal status value for an container that has no 537 pending operations or prohibitions. 539 3. EPP Command Mapping for Containers 541 A detailed description of the EPP syntax and semantics can be found 542 in [2]. The command mappings described here are specifically for use 543 in provisioning and managing containers via EPP. 545 3.1 EPP Query Commands 547 EPP provides two commands to retrieve container information: 548 to determine if a container is known to the server, to 549 retrieve detailed information associated with a container. [Editor: 550 Resolve tri-value issue for container extensions, e.g., to 551 retrieve container transfer status information.] 553 3.1.1 EPP Command 555 The EPP command is used to determine if a container is known 556 to the server. In addition to the standard EPP command elements, the 557 command MUST contain a element that 558 identifies the container namespace and the location of the container 559 schema. The element contains the following child 560 elements: 562 One or more elements that contain the server-unique 563 identifier of the containers to be queried. 565 Example command: 567 C: 568 C: 571 C: 572 C: 573 C: 576 C: CONTAINER-FooCorp-USA 577 C: CONTAINER-FooCorp-Asia 578 C: CONTAINER-FooCorp-Europe 579 C: 580 C: 581 C: 582 C: ABC-12346 583 C: 584 C: 586 When a command has been processed successfully, the EPP 587 element MUST contain a child element 588 that identifies the container namespace and the location of the 589 container schema. The element contains the 590 following child elements: 592 One or more elements that contain the server-unique 593 identifier for the queried containers and an "x" attribute whose 594 value identifies the object as either "+" for a known object or "-" 595 for an unknown container. 597 Example response: 599 S: 600 S: 603 S: 604 S: 605 S: Command completed successfully 606 S: 607 S: 608 S: 611 S: CONTAINER-FooCorp-USA 612 S: CONTAINER-FooCorp-Asia 613 S: CONTAINER-FooCorp-Europe 614 S: 615 S: 616 S: 617 S: 618 S: ABC-12346 619 S: 54322-XYZ 620 S: 621 S: 622 S: 624 An EPP error response MUST be returned if a command can not 625 be processed for any reason. 627 3.1.2 EPP Command 629 The EPP command is used to retrieve information associated 630 with a container. In addition to the standard EPP command elements, 631 the command MUST contain a element that 632 identifies the container namespace and the location of the container 633 schema. The element contains the following child 634 elements: 636 A element that contains the server-unique identifier 637 of the container to be queried. 639 Example command: 641 C: 642 C: 645 C: 646 C: 647 C: 650 C: CONTAINER-FooCorp-USA 651 C: 652 C: 653 C: 654 C: ABC-12346 655 C: 656 C: 658 When an command has been processed successfully, the EPP 659 element MUST contain a child element 660 that identifies the container namespace and the location of the 661 container schema. The element contains the 662 following child elements: 664 A element that contains the server-unique identifier 665 of the container. 667 A element that contains the Repository Object 668 IDentifier assigned to the container when the container was created. 670 One or more elements that describe the status of 671 the container. 673 An OPTIONAL element that contains the server- 674 unique identifier of the parent container of which the container is a 675 child. 677 An OPTIONAL element that identifies the registry 678 provided template, which is a set of registry defined policies, for 679 maintaining the container. 681 Zero or more elements that specify the server- 682 unique identifiers of objects or containers that are included in the 683 container. Each element MUST include one required "object" attribute 684 for identifying the type of the child, and an OPTIONAL "type" 685 attribute for identifying the sub-type of the child within the 686 specific object type. 688 If supported by the server, one or more elements 689 specify the server-unique identifiers of objects, excluding 690 containers, that the container inherited from its ancestor 691 containers. Each element MUST inlude one required "container" 692 attribute for identifying the container from which the object is 693 inherited, one required "object" attribute for identifying the type 694 of the child, and an OPTIONAL "type" attribute for identifying the 695 sub-type of the child within the specific object type. 697 If supported by the server, one or more elements 698 that identifies types (via a REQUIRED "type" attribute) and server- 699 unique identifiers of objects associated with the container, either 700 directly or indirectly, specified by the OPTIONAL "directly" 701 attribute, with either a "true" or "false" value, with "false" as the 702 default. 704 A element that contains the identifier of the 705 sponsoring client. 707 A element that contains the identifier of the client 708 that created the container. 710 A element that contains the date and time of the 711 container creation. 713 A element that contains the identifier of the client 714 that last updated the container. This element MUST NOT be present if 715 the container has never been modified. 717 A element that contains the date and time of the 718 most recent container modification. This element MUST NOT be present 719 if the container has never been modified. 721 A elements that contains the date and time of the 722 most recent successful container transfer. This element MUST NOT be 723 provided if the container has never been transferred. 725 A element that contains authorization 726 information to be associated with the container. This element MUST 727 NOT be provided if the querying client is not the current sponsoring 728 client. 730 Example response: 732 S: 733 S: 736 S: 737 S: 738 S: Command completed successfully 739 S: 740 S: 741 S: 744 S: CONTAINER-FooCorp-USA 745 S: CONTAINER12345-REGISTRY 746 S: 747 S: 748 S: 749 S: CONTAINER-FooCorp 750 S: TEMPLATE-FooCorp 751 S: CONTAINER-FooCorp-Georgia 752 S: 753 S: CONTACT-FooCorp-USA 754 S: 755 S: CONTACT-FooCorp-Tech 756 S: 757 S: ns1.foocorp.tld 758 S: ns2.foocorp.tld 759 S: ns3.foocorp.tld 760 S: 761 S: ns.foocorp.tld 762 S: foocorp.tld 763 S: 764 S: foocorp-ga.tld 765 S: 766 S: foocorp-va.tld 767 S: 768 S: ClientY 769 S: ClientX 770 S: 2001-04-03T22:00:00.0Z 771 S: ClientX 772 S: 2001-12-03T09:00:00.0Z 773 S: 2002-04-08T09:00:00.0Z 774 S: 2fooBAR 775 S: 776 S: 777 S: 778 S: 779 S: ABC-12346 780 S: 54322-XYZ 781 S: 782 S: 783 S: 785 An EPP error response MUST be returned if an command can not 786 be processed for any reason. 788 3.1.3 EPP Command 790 The EPP command provides a query operation that allows a 791 client to determine real-time status of pending and completed 792 transfer requests. In addition to the standard EPP command elements, 793 the command MUST contain an "op" attribute with value 794 "query", and a element that identifies the 795 container namespace and the location of the container schema. The 796 element MUST contain the following child 797 elements: 799 A element that contains the server-unique identifier 800 of the container to be queried. 802 Example query command: 804 C: 805 C: 808 C: 809 C: 810 C: 811 C: 814 C: CONTAINER-FooCorp-USA 815 C: 816 C: 817 C: 818 C: ABC-12346 819 C: 820 C: 822 When a query command has been processed successfully, the 823 EPP element MUST contain a child 824 element that identifies the container namespace and the location of 825 the container schema. The element contains the 826 following child elements: 828 A element that contains the server-unique identifier 829 for the queried container. 831 A element that contains the state of the most 832 recent transfer request. 834 A element that contains the identifier of the client 835 that requested the object transfer. 837 A element that contains the date and time that the 838 transfer was requested. 840 A element that contains the identifier of the client 841 that SHOULD act upon the transfer request. 843 A element that contains the date and time of a 844 required or completed response. For a pending request, the value 845 identifies the date and time by which a response is required before 846 an automated response action SHOULD be taken by the server. For all 847 other status types, the value identifies the date and time when the 848 request was completed. 850 Example query response: 852 S: 853 S: 856 S: 857 S: 858 S: Command completed successfully 859 S: 860 S: 861 S: 864 S: CONTAINER-FooCorp-USA 865 S: pending 866 S: ClientX 867 S: 2000-06-06T22:00:00.0Z 868 S: ClientY 869 S: 2000-06-11T22:00:00.0Z 870 S: 871 S: 872 S: 873 S: 874 S: ABC-12346 875 S: 54322-XYZ 876 S: 877 S: 878 S: 880 An EPP error response MUST be returned if a query command 881 can not be processed for any reason. 883 3.2 EPP Transform Commands 885 EPP provides four commands to transform container information: 886 to create an instance of a container, to delete an 887 instance of a container, to manage container sponsorship 888 changes, and to change information associated with a 889 container. This document does not define a mapping for the EPP 890 command. 892 3.2.1 EPP Command 894 The EPP command provides a transform operation that allows a 895 client to create a container. In addition to the standard EPP 896 command elements, the command MUST contain a 897 element that identifies the container namespace 898 and the location of the container schema. The 899 element contains the following child elements: 901 A element that contains the desired server-unique 902 identifier for the container to be created. 904 An OPTIONAL element that contains the server- 905 unique identifier of the parent container of which the container is a 906 child. 908 An OPTIONAL element that identifies the registry 909 provided template, which is a set of registry defined policies, in 910 maintaining the container. 912 Zero or more elements that specify the server- 913 unique identifiers of objects or containers that are included in the 914 container. Each element MUST include one required "object" attribute 915 for identifying the type of the child, and an OPTIONAL "type" 916 attribute for identifying the sub-type of the child within the 917 specific object type. If an element is a container, its "parent" 918 value MUST NOT have been specified. 920 A element that contains authorization 921 information to be associated with the container. 923 Example command: 925 C: 926 C: 929 C: 930 C: 931 C: 934 C: CONTAINER-FooCorp-USA 935 C: CONTAINER-FooCorp 936 C: TEMPLATE-FooCorp 937 S: CONTAINER-FooCorp-Georgia 938 S: 939 S: CONTACT-FooCorp-USA 940 S: 941 S: CONTACT-FooCorp-Tech 942 S: 943 S: ns1.foocorp.tld 944 S: ns2.foocorp.tld 945 S: ns3.foocorp.tld 946 C: 2fooBAR 947 C: 948 C: 949 C: 950 C: ABC-12345 951 C: 952 C: 953 When a command has been processed successfully, the EPP 954 element MUST contain a child element 955 that identifies the container namespace and the location of the 956 container schema. The element contains the 957 following child elements: 959 A element that contains the server-unique identifier 960 for the created container. 962 Example response: 964 S: 965 S: 968 S: 969 S: 970 S: Command completed successfully 971 S: 972 S: 973 S: 976 S: CONTAINER-FooCorp-USA 977 S: 978 S: 979 S: 980 S: 981 S: ABC-12345 982 S: 54321-XYZ 983 S: 984 S: 985 S: 987 An EPP error response MUST be returned if a command can not 988 be processed for any reason. 990 3.2.2 EPP Command 992 The EPP command provides a transform operation that allows a 993 client to delete a container. In addition to the standard EPP 994 command elements, the command MUST contain a 995 element that identifies the container namespace 996 and the location of the container schema. The 997 element MUST contain the following child elements: 999 A element that contains the server-unique identifier 1000 of the container to be deleted. 1002 An OPTIONAL elements that indicates if all objects 1003 associated with the container should be deleted or the associations 1004 to be broken. This element MAY take one of the following possible 1005 values, with "none" as the default: 1007 "none" for taking no actions on associated objects 1009 "delete" for deleting all associated objects 1011 "break" for breaking the association relationship of all 1012 associated objects without deleting them. 1014 A element that contains authorization 1015 information to be associated with the container. 1017 A container object SHOULD NOT be deleted if it is associated with 1018 other known objects or containers. An associated container SHOULD 1019 NOT be deleted until associations with other known objects or 1020 containers have been broken. 1022 Example command: 1024 C: 1025 C: 1028 C: 1029 C: 1030 C: 1033 C: CONTAINER-FooCorp-USA 1034 C: break 1035 C: 1036 C: 1037 C: 1038 C: ABC-12346 1039 C: 1040 C: 1042 When a command has been processed successfully, a server 1043 MUST respond with an EPP response with no element. 1045 Example response: 1047 S: 1048 S: 1051 S: 1052 S: 1053 S: Command completed successfully 1054 S: 1055 S: 1056 S: 1057 S: ABC-12346 1058 S: 54322-XYZ 1059 S: 1060 S: 1061 S: 1063 An EPP error response MUST be returned if a command can not 1064 be processed for any reason. 1066 3.2.3 EPP Command 1068 Renewal semantics do not apply to containers, so there is no mapping 1069 defined for the EPP command. 1071 3.2.4 EPP Command 1073 The EPP command provides a transform operation that allows 1074 a client to manage requests to transfer the sponsorship of a 1075 container. In addition to the standard EPP command elements, the 1076 command MUST contain a element that 1077 identifies the container namespace and the location of the container 1078 schema. The element contains the following child 1079 elements: 1081 A element that contains the server-unique identifier 1082 of the container for which a transfer request is to be created, 1083 approved, rejected, or cancelled. 1085 An OPTIONAL element that contains instruction if 1086 and how the objects associated with container are transferred. This 1087 element is REQUIRED only when a transfer is requested, and it MUST be 1088 ignored if used otherwise. The element takes one of the following 1089 possible values, with "none" as default: 1091 "none" for no actions to be taken for all associated objects 1093 "linked" for transferring all directly associated objects 1095 "child" for transferring all child objects or containers 1097 "all" for transferring both all associated objects, directly or 1098 indirectly, and all child objects or containers. 1100 If there are any objects or containers with a status that 1101 prohibites transfer operation, the transfer operation as a whole 1102 will fail. 1104 A element that contains authorization 1105 information associated with the container. This element is REQUIRED 1106 only when a transfer is requested, and it MUST be ignored if used 1107 otherwise. 1109 Every EPP command MUST contain an "op" attribute that 1110 identifies the transfer operation to be performed as defined in [2]. 1112 The EPP command MAY be restricted to certain containers, 1113 based on the container templates or registry policies. 1115 Example request command: 1117 C: 1118 C: 1121 C: 1122 C: 1123 C: 1126 C: CONTAINER-FooCorp-USA 1127 C: 2fooBAR 1128 C: 1129 C: 1130 C: 1131 C: ABC-12346 1132 C: 1133 C: 1135 When a command has been processed successfully, the EPP 1136 element MUST contain a child element 1137 that identifies the container namespace and the location of the 1138 container schema. The element contains the same 1139 child elements defined for a transfer query response. 1141 Example response: 1143 S: 1144 S: 1147 S: 1148 S: 1149 S: Command completed successfully 1150 S: 1151 S: 1152 S: 1155 S: CONTAINER-FooCorp-USA 1156 S: pending 1157 S: ClientX 1158 S: 2000-06-08T22:00:00.0Z 1159 S: ClientY 1160 S: 2000-06-13T22:00:00.0Z 1161 S: 1162 S: 1163 S: 1164 S: 1165 S: ABC-12346 1166 S: 54322-XYZ 1167 S: 1168 S: 1169 S: 1171 An EPP error response MUST be returned if a command can not 1172 be processed for any reason. 1174 3.2.5 EPP Command 1176 The EPP command provides a transform operation that allows a 1177 client to modify the attributes of a container. In addition to 1178 the standard EPP command elements, the command MUST contain a 1179 element that identifies the container namespace and the 1180 location of the container schema. The element contains 1181 the following child elements: 1183 A element that contains the server-unique identifier of 1184 the container object to be updated. 1186 An OPTIONAL element that contains attribute values to 1187 be added to the container 1189 An OPTIONAL element that contains attribute values to 1190 be removed from the container. 1192 An OPTIONAL element that contains container attribute 1193 values to be changed. 1195 At least one , , or element 1196 MUST be provided. The and elements 1197 contain the following child elements. 1198 At least one child element MUST be present: 1200 Zero or more elements that specify the server-unique 1201 identifiers of objects or containers that are included in the container. 1202 Each element MUST include one required "object" attribute for 1203 identifying the type of the child, and an OPTIONAL "type" attribute 1204 for identifying the sub-type of the child within the specific object type. 1205 The removal of any children of a container MUST ensure data integrity 1206 of all objects associated with the container, directly or indirectly. 1208 Zero or more elements that contain status values to 1209 be associated with or removed from the container. When specifying a 1210 value to be removed, only the attribute value is significant; element 1211 text is not required to match a value for removal. 1213 A element contains the following OPTIONAL child 1214 elements. At least one child element MUST be present: 1216 A element that contains the server-unique 1217 identifier of the new parent container of which the container is a child. 1218 The change of the container child-parent relationship MUST ensure data 1219 integrity of all objects associated with the container, directly or 1220 indirectly. 1222 If supported by the server, an element that identifies 1223 the new registry provided template, which is a set of registry defined 1224 policies, in maintaining the container. 1226 A element that contains authorization information 1227 associated with the container object. 1229 Example command: 1231 C: 1232 C: 1235 C: 1236 C: 1237 C: 1240 C: CONTAINER-FooCorp-USA 1241 C: 1242 C: 1243 C: ns4.foocorp.tld 1244 C: 1245 C: 1246 C: CONTAINER-FooCorp-All 1247 C: 1248 C: 1249 C: 1250 C: 1251 C: ABC-12346 1252 C: 1253 C: 1255 When an command has been processed successfully, a server 1256 MUST respond with an EPP response with no element. 1258 Example response: 1260 S: 1261 S: 1264 S: 1265 S: 1266 S: Command completed successfully 1267 S: 1268 S: 1269 S: 1270 S: ABC-12346 1271 S: 54322-XYZ 1272 S: 1273 S: 1274 S: 1276 An EPP error response MUST be returned if an command can not 1277 be processed for any reason. 1279 3.3 Formal Syntax for Container 1281 An EPP object mapping is specified in XML Schema notation. The 1282 formal syntax presented here is a complete schema representation of 1283 the object mapping suitable for automated validation of EPP XML 1284 instances. 1286 1287 1293 1296 1298 1300 1301 1302 Extensible Provisioning Protocol v1.0 1303 container provisioning schema. 1304 1305 1306 1309 1310 1313 1314 1315 1316 1317 1318 1319 1322 1323 1324 1325 1326 1327 1328 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1369 1370 1371 1372 1373 1374 1375 1378 1379 1380 1381 1383 1385 1386 1388 1389 1390 1391 1392 1393 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1408 1409 1410 1411 1412 1413 1416 1417 1418 1420 1421 1422 1425 1426 1427 1428 1430 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1445 1446 1447 1448 1449 1451 1453 1455 1456 1457 1458 1461 1462 1463 1465 1467 1468 1469 1472 1473 1474 1476 1478 1480 1481 1482 1486 1487 1488 1489 1490 1493 1494 1495 1497 1498 1499 1500 1501 1502 1504 1505 1506 1507 1510 1511 1512 1513 1514 1515 1518 1519 1520 1521 1522 1524 1526 1528 1530 1532 1534 1535 1536 1537 1539 1541 1543 1544 1545 1546 1550 1551 1552 1553 1555 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1590 1592 4. EPP Command Mapping for Objects with Containers 1594 A detailed description of the EPP syntax and semantics can be found 1595 in [2]. The extended command mappings described here are 1596 specifically for use in provisioning and managing objects using 1597 containers via EPP. The objects can be maintained with containers 1598 specified here are domains. Other types of objects managed with 1599 containers will be included in the future as required. However, any 1600 objects included in a container cannot be removed via the 1601 commands, or modified via the command unless the data 1602 integrity of all objects associated with the container are ensured. 1604 The EPP commands that can be applied to domain objects MUST be 1605 or commands. In addition, the responses to 1606 commands MAY contains an OPTIONAL "container" element that indicating 1607 the container used in maintaining domain objects. Finally, in order 1608 to a domain object that is associated with a container, 1609 the association MUST be cut-off first via the command for 1610 nullifying its container value. 1612 4.1 EPP Command for Domain Object With Container 1614 A domain object can be created with a container. The extended schema 1615 for domain object will include an OPTIONAL "container" element in the 1616 command. 1618 If the OPTIONAL "container" element is present in the 1619 command for creating a domain object, all other required elements 1620 described in [6], except for the fully required name of the domain 1621 object, become OPTIONAL. All other REQUIRED or OPTIONAL elements 1622 specified in [6] are derived from the container specified. If some of 1623 the REQUIRED elements cannot be found in the container or any of the 1624 ancestor containers of the container, the domain object will not be 1625 created. Any REQUIRED or OPTIONAL elements specified in the 1626 command will override the values derived from the container object. 1628 Example command with container: 1630 C: 1631 C: 1634 C: 1635 C: 1636 C: 1639 C: foocorp-ga.tld 1640 C: CONTAINER-FooCorp-USA 1641 C: FooCorp-Georgia 1642 C: 1643 C: 1644 C: 1645 C: ABC-12345 1646 C: 1647 C: 1649 The response to a command is described in [6]. 1651 4.2 EPP Command for Domain Object With Container 1653 Additional domain attribute values can be added or changed via the 1654 command to override the default values derived from 1655 containers. However, only attribute values specified via the 1656 command or added via the command can be removed, and data 1657 integrity of the domain object is ensured. 1659 When a domain object is associated with a container, the association 1660 can be cut-off or changed with another container. All attribute 1661 values for the domain object will be copied from containers into the 1662 domain object itself. 1664 When the element of the command for a domain object 1665 contains an OPTIONAL element, which is either empty or a 1666 server-unique container identifier, the association to the current 1667 container, if present, will be cut-off or changed to the new 1668 container. However, if the domain object does not associated with any 1669 container, the update command SHOULD fail. 1671 Example command for updating container association: 1673 C: 1674 C: 1677 C: 1678 C: 1679 C: 1682 C: foocorp-va.com 1683 C: 1684 C: CONTAINER-FooCorp-Virginia 1685 C: 2BARfoo 1686 C: 1687 C: 1688 C: 1689 C: 1690 C: ABC-12346 1691 C: 1692 C: 1693 The response to a command is described in [6]. 1695 4.3 EPP Command for Domain Object With Container 1697 If a domain object is associated with a container, the response data to 1698 the command will contain an OPTIONAL "container" element whose 1699 value is the server-unique identifier of the container used for maintaining 1700 the domain object. 1702 Example response: 1704 S: 1705 S: 1708 S: 1709 S: 1710 S: Command completed successfully 1711 S: 1712 S: 1713 S: 1716 S: foocorp-va.tld 1717 S: FOOCORP-12-REGISTRY 1718 S: 1719 S: CONTAINER-FooCorp-USA 1720 S: FooCorp-Corp 1721 S: FooCorpAdmin 1722 S: FooCorpTech 1723 S: FooCorpBilling 1724 S: ns1.foocorp.tld 1725 S: ns2.foocorp.tld 1726 S: ns1.foocorp.tld 1727 S: ns2.foocorp.tld 1728 S: ClientX 1729 S: ClientY 1730 S: 2001-04-03T22:00:00.0Z 1731 S: ClientX 1732 S: 2001-12-03T09:00:00.0Z 1733 S: 2005-04-03T22:00:00.0Z 1734 S: 2002-04-08T09:00:00.0Z 1735 S: 2fooBAR 1736 S: 1737 S: 1738 S: 1739 S: 1740 S: ABC-12346 1741 S: 54322-XYZ 1742 S: 1743 S: 1744 S: 1746 4.4 Formal Syntax for Domain Object with Container 1748 An EPP object mapping is specified in XML Schema notation. The 1749 formal syntax presented here is a complete schema representation of 1750 the object mapping suitable for automated validation of EPP XML 1751 instances. 1753 Instead of giving a full XML Schema for domain object with container 1754 extension, the following is the diff output comparing to the original 1755 [6] schema. [Editor: This needs to be updated when [6] finishes 1756 WGLC.] 1758 *** domain-1.0.xsd Tue Jun 26 08:33:20 2001 1759 --- domain-1.1.xsd Thu Aug 2 10:48:50 2001 1760 *************** 1761 *** 1,7 **** 1762 1764 ! 1772 ! 1780 1781 Extensible Provisioning Protocol v1.0 1782 ! domain provisioning schema. 1783 1784 1786 --- 18,24 ---- 1787 1788 1789 Extensible Provisioning Protocol v1.0 1790 ! domain provisioning schema, with container extension. 1791 1792 1794 *************** 1795 *** 28,33 **** 1796 --- 28,42 ---- 1797 1799 1802 + 1803 + 1804 + 1805 + 1806 + 1807 + 1808 + 1811 1812 *************** 1813 *** 44,49 **** 1814 --- 53,60 ---- 1815 1816 1817 1818 + 1820 1823 1827 1829 ! 1830 1831 1833 --- 63,70 ---- 1834 minOccurs="0"/> 1835 1837 ! 1839 1840 1842 *************** 1843 *** 228,233 **** 1844 --- 240,246 ---- 1845 1846 1847 1848 + 1849 1851 , work in progress. 1876 [3] Bray, T., et al, "Extensible Markup Language (XML) 1.0 (Second 1877 Edition)", 6 October 2000. 1879 [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 1880 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 1881 . 1883 [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C 1884 REC-xmlschema-2, May 2001, . 1886 [6] Hollenbeck, S., "EPP Domain mapping", Internet-Draft , work in progress. 1889 Editor's Address 1891 Eric Brunner-Williams 1892 1415 Forest Ave., 1893 Portland, ME 04103 1895 brunner@nic-naa.net 1897 Full Copyright Statement 1899 Copyright (C) The Internet Society (2001). All Rights Reserved. 1901 This document and translations of it may be copied and furnished to 1902 others, and derivative works that comment on or otherwise explain it 1903 or assist in its implementation may be prepared, copied, published 1904 and distributed, in whole or in part, without restriction of any 1905 kind, provided that the above copyright notice and this paragraph are 1906 included on all such copies and derivative works. However, this 1907 document itself may not be modified in any way, such as by removing 1908 the copyright notice or references to the Internet Society or other 1909 Internet organizations, except as needed for the purpose of 1910 developing Internet standards in which case the procedures for 1911 copyrights defined in the Internet Standards process must be 1912 followed, or as required to translate it into languages other than 1913 English. 1915 The limited permissions granted above are perpetual and will not be 1916 revoked by the Internet Society or its successors or assigns. 1918 This document and the information contained herein is provided on an 1919 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1920 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1921 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1922 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1923 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1925 Acknowledgement 1927 Many people have contributed input and commentary to earlier versions 1928 of this document, including but not limited to: Ayesha Demaraju (co- 1929 author), Ning Zhang (co-author), and Scott Hollenbeck and Dan Manley, 1930 working group participants. 1932 Funding for the RFC editor function is currently provided by the 1933 Internet Society.