Internet Engineering Task Force Eric Brunner-Williams Internet-Draft wampumpeag Ayesha Damaraju Ning Zhang NeuStar November, 2001 Expires April 2002 Extensible Provisioning Protocol Container Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo documents how EPP container objects extends EPP objects, supporting hierarchy and inheritance, simplifying administration and mangement of the associated objects. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Brunner, et al Expires April 2002 [Page 1] Internet-Draft EPP Container November 2001 Table of Contents Status of this Memo ............................................ 1 Copyright Notice ............................................... 1 Abstract ....................................................... 1 Table of Contents .............................................. 2 1. Introduction ................................................ 2 2. Containers .................................................. 3 2.1 EPP Command Summary for Containers ...................... 5 2.1.1 Container Query Commands ........................... 5 2.1.2 Container Transformation Commands .................. 5 2.2 EPP Commnand for Managing Objects with Containers ....... 5 2.3 Container Templates ..................................... 6 2.4 Container Attributes .................................... 8 2.5 Status Values ........................................... 11 3. EPP Command Mapping for Container ........................... 11 3.1 EPP Query Commands ...................................... 11 3.1.1 EPP Command ................................ 11 3.1.2 EPP Command ................................. 14 3.1.3 EPP Command ............................. 17 3.2 EPP Transform Commands .................................. 19 3.2.1 EPP Command ............................... 19 3.2.2 EPP Command ............................... 21 3.2.3 EPP Command ................................ 23 3.2.4 EPP Command ............................. 23 3.2.5 EPP Command ............................... 25 3.3 Formal Syntax for Container ............................. 27 4. EPP Command Mapping for Objects with Containers ............. 34 4.1 EPP Command for Domain Object With Container ... 34 4.2 EPP Command for Domain Object With Container ... 35 4.3 EPP Command for Domain Object With Container ..... 36 4.4 Formal Syntax for Domain Object with Container .......... 37 5. Internationalization Considerations ......................... 39 6. IANA Considerations ......................................... 39 7. Security Considerations ..................................... 40 References ..................................................... 40 Authors' Addresses ............................................. 40 Full Copyright Statement ....................................... 41 Acknowledgement ................................................ 41 1. Introduction EPP (Extensible Provisioning Protocol) defines generic object management operations and an extensible framework that maps protocol operations to objects stored in a shared central repository. This memo documents how these generic object management operations are extended to hierarchies of objects, called container objects or Brunner, et al Expires April 2002 [Page 2] Internet-Draft EPP Container November 2001 containers. This memo is being discussed on the "ietf-provreg" mailing list. To join the list, send a message to with the words "subscribe ietf-provreg" in the body of the message. There is a web site for the list archives at http://www.cafax.se/ietf-provreg. 2. Containers A container object is a collection of objects defined by a registry. A container object may contain any number of these defined objects, and may also contain other containers in a nested fashion. Containers simplify administration and management of associated objects. Each object in a collection of objects in a container maintains a parent-child relationship with the container. The collection of containers and the objects are managed in a tree/forest fashion with one root container node. In a Container tree, non-leaf nodes are container objects, leaf nodes are other objects. Each object in the collection of a container will maintain a link to its parent container. A container without a parent container is the root node of a container tree. Each child container inherits properties from the parent container. Additionally, each container derives properties from its directly associated leaf child object nodes, which override any mutual exclusive inherited properties. For root containers the properties are the properties of its directly associated leaf child object nodes alone. This inheritance of properties among associated containers restricts containers to a single parent, or no parent in the case of the root container. Non-leaf nodes (containers) may maintain references to leaf-notes without restriction. Restated, a container can only have at most one parent container, and zero or more child containers. Mutual exclusion of objects contained in registries and references to objects in multiple containers may be defined by the registry. Example Container: +-------------+ | Container 1 | +------+------+ | --------------+----+----------------------+ | | | Brunner, et al Expires April 2002 [Page 3] Internet-Draft EPP Container November 2001 +------+-------+ +-------+-------+ +------+------+ | Registrant 1 | | Host 1 | | Container 2 | +--------------+ +---------------+ +------+------+ | +-----------------+----------------+ | | | +------+------+ +--------------+ +------+------+ | Container 3 | | Contact 1 | | Container 4 | +------+------+ +--------------+ +-------------+ | ... +-------------+----+----------------+ | | | +------+-------+ +-------+-------+ +-----+-----+ | Host 2 | | Registrant 2 | | Contact 2 | +--------------+ +---------------+ +-----------+ Figure 1: An Example of Container Tree Container 1 has the properties: "Registrant 1" "Host 1" Container 2 inherits the Container 1 properties and its child objects. "Registrant 1" "Host 1" "Contact 1" The derivation of Container 3, assuming the registry policy of type Container 3 is Unique Registrant, evaluates as: "Registrant 2" "Contact 1" "Contact 2" "Host 1" "Host 2" This example shows property derivation with a local policy (registrant 2 preference). 2.1 EPP Command Summary for Containers 2.1.1 Container Query Commands check check on a container Brunner, et al Expires April 2002 [Page 4] Internet-Draft EPP Container November 2001 info query the collection of objects using a container object transfer query query the status of a container transfer command 2.1.2 Container Transformation Commands create create a container delete delete a container update update a container (add/remove objects) update update a collection of associated objects by updating properties of a container object delete delete a container with an option to delete all associated objects. transfer transfer a container with an option to transfer all associated objects. transfer transfer a container with an option to transfer all directly associated leaf child objects and child containers. transfer transfer a container with an option to transfer both linked objects and directly associated leaf child objects and child containers. 2.2 EPP Command for Managing Objects with Containers A detailed description of the EPP syntax and semantics can be found in [EPP]. The extended command mappings summarized here are described in section 5. 2.3 Container Templates Each container can be subjected to a set of registry policies by binding a container to a template supported by Registry. Templates Brunner, et al Expires April 2002 [Page 5] Internet-Draft EPP Container November 2001 are well-documented Registry policies that determine the functions and objects supported in a container. Example Templates Registrant Template supports child objects: o registrant o contacts (multiple type associations: admin, tech, billing), o hosts (1-13), o domain and/or registrant containers supports functions/commands: o create a registrant container with supported child objects, o create associated objects (domains, registrant container) using the registrant container, o update container add/delete registrant, contacts (admin, tech, billing), hosts (1-13), container o update container with an option to update associated objects o delete container o delete container with an option to delete all associated objects o update add/delete other registrant containers, domain containers o transfer a container to a different registrar o transfer a container to a different registrar along with associated objects Domain Template support child objects: o domains, supports functions/commands to: o create a domain container with supported child objects o create a domain container under a registrant template and supported child objects o create a domain container using a registrant template and supported child objects o update container add/delete domains or other domain container o transfer a container to a different registrar o transfer a container to a different registrar along with child Brunner, et al Expires April 2002 [Page 6] Internet-Draft EPP Container November 2001 objects o delete a container o delete a container with an option to delete all child objects Registrar Account Template support child objects: o contacts, o hosts (1-13), o registrant containers supports functions/commands to: o create a registrant account container with supported child objects. o create associated objects (registrant containers) o update container add/delete any of the child objects o delete container o delete container with an option to delete all associated objects Registrant Account Template A Registrant Account Template can be used to group various objects or containers into a single aggregation. However, objects or containers in the registry should only belong to at most one container created with the Registrant Account Template. support child objects: o domain objects, o host objects, o contact objects, o registrant containers, o domain containers supports functions/commands to: o create a registrant account template with supported child objects o update container add/delete any supported child objects o delete a container o delete a container with an option to delete all child objects o transfer a container to a different registrar 2.4 Container Attributes An EPP container object has attributes and associated values that may be viewed and modified by the sponsoring client or the server. This Brunner, et al Expires April 2002 [Page 7] Internet-Draft EPP Container November 2001 section describes each attribute type in detail. id This element is the unique identifier of the container given by the registrar. The format is alphanumeric with the minimum and maximum length and character set specified in the XML Schema Definition [XML-SCHEMA]. Example: MIT-CONTAINER-42 roid This element is the unique identifier of the container given by the registry. Container identifiers use the "roidType" syntax described in [EPP]. Example: CONTAINER001-BIZ status This element describes the status of the container. This element may have multiple occurrences. Example: parent This element is the reference of the parent container object in the container tree by its . This element is optional and if not specified the container is the root node of the tree. The format is alphanumeric with the minimum and maximum length and character set specified in the XML Schema Definition [XML-SCHEMA]. Example: 00-CONT-21 template This optional element is the registry provided template for creating containers. For a given template there are set of Registry defined policies for supported objects in a template and other validations for a container. Brunner, et al Expires April 2002 [Page 8] Internet-Draft EPP Container November 2001 The format is alphanumeric with the minimum and maximum length and character set specified in the XML Schema Definition [XML-SCHEMA]. Example: child This element is the reference to objects in the container. This element may have multiple occurrences. The child element in a container has attribute "obj" and optional "type" to reflect supported object types and optional type of association. The object types include all registry supported objects including containers. Example: coca-cola-corp coco-cola-admin derived This element is the reference to objects inherited from ancestor containers. This element may have multiple occurrences. The derived element in a container has attribute "container", "object" and optional "type" to reflect the container from which the object is inherited, object type, and optional type of association. The object types include all registry supported objects. Example: coca-cola-corp coco-cola-admin linked This element is the reference to other objects linked to this container. These are the objects created using container properties. Updates made to a container will result in updates to all linked objects. The "linked" element has attribute "type" to reflect the type of the linked object. Example: Brunner, et al Expires April 2002 [Page 9] Internet-Draft EPP Container November 2001 coca-cola-corp coca-cola-admin clID This element contains the identifier of the sponsoring registrar. The sponsoring registrar client has all the necessary administrative privileges to manage the object. Example: clientXX crID This element contains the reference to the registrar client that created the container. Example: clientXX crDate This element contains the reference to the date the container was created. The format of the time field is UCT extended format of ISO 8601. Example: 2001-07-04:00:00.0Z upID This element contains the reference to the registrar client that modified the container. Example: clientXX upDate This element contains the reference to the date the container was modified. The format of the time field is UCT extended format of ISO 8601. Example: 2001-07-04:00:00.0Z trDate This element contains the reference to the date the container was Brunner, et al Expires April 2002 [Page 10] Internet-Draft EPP Container November 2001 transferred. The format of the time field is UCT extended format of ISO 8601. Example: 2001-07-04:00:00.0Z authInfo This element contains information associated with containers to facilitate transfer operations. Authorization information is assigned when a container is created, and it MAY be updated in the future. This specification describes password or certificate- based authorization information, though other mechanisms are possible. Example: 2fooBAR 2.5 Status Values A container object MUST always have at least one associated status value. Status values MAY be set only by the client that sponsors a domain object and by the server on which the container resides. A client MAY change the status of a container object using the EPP command. Each status value MAY be accompanied by a string of human-readable text that describes the rationale for the status applied to the container. Status value Descriptions: active Supports updates and usage in transactions. inactive Does not support updates or usage in transactions. pendingTransfer A transfer request has been received for the container, and completion of the request is pending. Transform (??) commands other than MUST be rejected while a container is in this state. pendingDelete A delete request has been received for the container, but the container has not yet been purged from the server database. Brunner, et al Expires April 2002 [Page 11] Internet-Draft EPP Container November 2001 TransferProhibited, clientTransferProhibited Requests to transfer the container MUST be rejected. UpdateProhibited, clientUpdateProhibited Requests to update the container MUST be rejected. DeleteProhibited, clientDeleteProhibited Requests to delete the container MUST be rejected. linked The container has at least one active association, such as a domain object of another container. Servers SHOULD provide services to determine existing object associations. ok This is the nominal status value for an container that has no pending operations or prohibitions. 3. EPP Command Mapping for Containers A detailed description of the EPP syntax and semantics can be found in [EPP]. The command mappings described here are specifically for use in provisioning and managing containers via EPP. 3.1 EPP Query Commands EPP provides two commands to retrieve container information: to determine if a container is known to the server, to retrieve detailed information associated with a container. [Editor: Resolve tri-value issue for container extensions, e.g., to retrieve container transfer status information.] 3.1.1 EPP Command The EPP command is used to determine if a container is known to the server. In addition to the standard EPP command elements, the command MUST contain a element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - One or more elementshat contain the server-unique identifier of the containers to be queried. Example command: C: Brunner, et al Expires April 2002 [Page 12] Internet-Draft EPP Container November 2001 C: C: C: C: C: CONTAINER-CocaCola-USA C: CONTAINER-CocaCola-Asia C: CONTAINER-CocaCola-Europe C: C: C: C: ABC-12346 C: C: When a command has been processed successfully, the EPP element MUST contain a child element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - One or more elements that contain the server-unique identifier for the queried containers and an "x" attribute whose value identifies the object as either "+" for a known object or "-" for an unknown container. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: CONTAINER-CocaCola-USA S: CONTAINER-CocaCola-Asia S: CONTAINER-CocaCola-Europe S: S: Brunner, et al Expires April 2002 [Page 13] Internet-Draft EPP Container November 2001 S: S: S: ABC-12346 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if a command can not be processed for any reason. 3.1.2 EPP Command The EPP command is used to retrieve information associated with a container. In addition to the standard EPP command elements, the command MUST contain a element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - A element that contains the server-unique identifier of the container to be queried. Example command: C: C: C: C: C: C: CONTAINER-CocaCola-USA C: C: C: C: ABC-12346 C: C: When an command has been processed successfully, the EPP element MUST contain a child element that identifies the container namespace and the location of the container schema. The element contains the following child elements: Brunner, et al Expires April 2002 [Page 14] Internet-Draft EPP Container November 2001 - A element that contains the server-unique identifier of the container. - A element that contains the Repository Object IDentifier assigned to the container when the container was created. - One or more elements that describe the status of the container. - An OPTIONAL element that contains the server- unique identifier of the parent container of which the container is a child. - An OPTIONAL element that identifies the registry provided template, which is a set of registry defined policies, for maintaining the container. - Zero or more elements that specify the server- unique identifiers of objects or containers that are included in the container. Each element MUST include one required "object" attribute for identifying the type of the child, and an OPTIONAL "type" attribute for identifying the sub-type of the child within the specific object type. - If supported by the server, one or more elements specify the server-unique identifiers of objects, excluding containers, that the container inherited from its ancestor containers. Each element MUST inlude one required "container" attribute for identifying the container from which the object is inherited, one required "object" attribute for identifying the type of the child, and an OPTIONAL "type" attribute for identifying the sub-type of the child within the specific object type. - If supported by the server, one or more elements that identifies types (via a REQUIRED "type" attribute) and server- unique identifiers of objects associated with the container, either directly or indirectly, specified by the OPTIONAL "directly" attribute, with either a "true" or "false" value, with "false" as the default. - A element that contains the identifier of the sponsoring client. - A element that contains the identifier of the client that created the container. - A element that contains the date and time of the container creation. Brunner, et al Expires April 2002 [Page 15] Internet-Draft EPP Container November 2001 - A element that contains the identifier of the client that last updated the container. This element MUST NOT be present if the container has never been modified. - A element that contains the date and time of the most recent container modification. This element MUST NOT be present if the container has never been modified. - A elements that contains the date and time of the most recent successful container transfer. This element MUST NOT be provided if the container has never been transferred. - A element that contains authorization information to be associated with the container. This element MUST NOT be provided if the querying client is not the current sponsoring client. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: CONTAINER-CocaCola-USA S: CONTAINER12345-NEULEVEL S: S: S: S: CONTAINER-CocaCola S: TEMPLATE-CocaCola S: CONTAINER-CocaCola-Georgia S: S: CONTACT-CocaCola-USA S: S: CONTACT-CocaCola-Tech S: S: ns1.cocacola.biz S: ns2.cocacola.biz S: ns3.cocacola.biz S: Brunner, et al Expires April 2002 [Page 16] Internet-Draft EPP Container November 2001 S: ns.cocacola.biz S: cocacola.biz S: S: cocacola-ga.biz S: S: cocacola-va.biz S: S: ClientY S: ClientX S: 2001-04-03T22:00:00.0Z S: ClientX S: 2001-12-03T09:00:00.0Z S: 2002-04-08T09:00:00.0Z S: 2fooBAR S: S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if an command can not be processed for any reason. 3.1.3 EPP Command The EPP command provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. In addition to the standard EPP command elements, the command MUST contain an "op" attribute with value "query", and a element that identifies the container namespace and the location of the container schema. The element MUST contain the following child elements: - A element that contains the server-unique identifier of the container to be queried. Example query command: C: C: C: Brunner, et al Expires April 2002 [Page 17] Internet-Draft EPP Container November 2001 C: C: C: C: CONTAINER-CocaCola-USA C: C: C: C: ABC-12346 C: C: When a query command has been processed successfully, the EPP element MUST contain a child element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - A element that contains the server-unique identifier for the queried container. - A element that contains the state of the most recent transfer request. - A element that contains the identifier of the client that requested the object transfer. - A element that contains the date and time that the transfer was requested. - A element that contains the identifier of the client that SHOULD act upon the transfer request. - A element that contains the date and time of a required or completed response. For a pending request, the value identifies the date and time by which a response is required before an automated response action SHOULD be taken by the server. For all other status types, the value identifies the date and time when the request was completed. Example query response: S: S: S: Brunner, et al Expires April 2002 [Page 18] Internet-Draft EPP Container November 2001 S: S: Command completed successfully S: S: S: S: CONTAINER-CocaCola-USA S: pending S: ClientX S: 2000-06-06T22:00:00.0Z S: ClientY S: 2000-06-11T22:00:00.0Z S: S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if a query command can not be processed for any reason. 3.2 EPP Transform Commands EPP provides four commands to transform container information: to create an instance of a container, to delete an instance of a container, to manage container sponsorship changes, and to change information associated with a container. This document does not define a mapping for the EPP command. 3.2.1 EPP Command The EPP command provides a transform operation that allows a client to create a container. In addition to the standard EPP command elements, the command MUST contain a element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - A element that contains the desired server-unique identifier for the container to be created. - An OPTIONAL element that contains the server- Brunner, et al Expires April 2002 [Page 19] Internet-Draft EPP Container November 2001 unique identifier of the parent container of which the container is a child. - An OPTIONAL element that identifies the registry provided template, which is a set of registry defined policies, in maintaining the container. - Zero or more elements that specify the server- unique identifiers of objects or containers that are included in the container. Each element MUST include one required "object" attribute for identifying the type of the child, and an OPTIONAL "type" attribute for identifying the sub-type of the child within the specific object type. If an element is a container, its "parent" value MUST NOT have been specified. - A element that contains authorization information to be associated with the container. Example command: C: C: C: C: C: C: CONTAINER-CocaCola-USA C: CONTAINER-CocaCola C: TEMPLATE-CocaCola S: CONTAINER-CocaCola-Georgia S: S: CONTACT-CocaCola-USA S: S: CONTACT-CocaCola-Tech S: S: ns1.cocacola.biz S: ns2.cocacola.biz S: ns3.cocacola.biz C: 2fooBAR C: C: C: C: ABC-12345 C: C: Brunner, et al Expires April 2002 [Page 20] Internet-Draft EPP Container November 2001 When a command has been processed successfully, the EPP element MUST contain a child element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - A element that contains the server-unique identifier for the created container. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: CONTAINER-CocaCola-USA S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: An EPP error response MUST be returned if a command can not be processed for any reason. 3.2.2 EPP Command The EPP command provides a transform operation that allows a client to delete a container. In addition to the standard EPP command elements, the command MUST contain a element that identifies the container namespace and the location of the container schema. The element MUST contain the following child elements: - A element that contains the server-unique identifier of the container to be deleted. Brunner, et al Expires April 2002 [Page 21] Internet-Draft EPP Container November 2001 - An OPTIONAL elements that indicates if all objects associated with the container should be deleted or the associations to be broken. This element MAY take one of the following possible values, with "none" as the default: - "none" for taking no actions on associated objects - "delete" for deleting all associated objects - "break" for breaking the association relationship of all associated objects without deleting them. - A element that contains authorization information to be associated with the container. A container object SHOULD NOT be deleted if it is associated with other known objects or containers. An associated container SHOULD NOT be deleted until associations with other known objects or containers have been broken. Example command: C: C: C: C: C: C: CONTAINER-CocaCola-USA C: break C: C: C: C: ABC-12346 C: C: When a command has been processed successfully, a server MUST respond with an EPP response with no element. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if a command can not be processed for any reason. 3.2.3 EPP Command Renewal semantics do not apply to containers, so there is no mapping defined for the EPP command. 3.2.4 EPP Command The EPP command provides a transform operation that allows a client to manage requests to transfer the sponsorship of a container. In addition to the standard EPP command elements, the command MUST contain a element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - A element that contains the server-unique identifier of the container for which a transfer request is to be created, approved, rejected, or cancelled. - An OPTIONAL element that contains instruction if and how the objects associated with container are transferred. This element is REQUIRED only when a transfer is requested, and it MUST be ignored if used otherwise. The element takes one of the following possible values, with "none" as default: - "none" for no actions to be taken for all associated objects - "linked" for transferring all directly associated objects - "child" for transferring all child objects or containers - "all" for transferring both all associated objects, directly or Brunner, et al Expires April 2002 [Page 23] Internet-Draft EPP Container November 2001 indirectly, and all child objects or containers. If there are any objects or containers with a status that prohibites transfer operation, the transfer operation as a whole will fail. - A element that contains authorization information associated with the container. This element is REQUIRED only when a transfer is requested, and it MUST be ignored if used otherwise. Every EPP command MUST contain an "op" attribute that identifies the transfer operation to be performed as defined in [EPP]. The EPP command MAY be restricted to certain containers, based on the container templates or registry policies. Example request command: C: C: C: C: C: C: CONTAINER-CocaCola-USA C: 2fooBAR C: C: C: C: ABC-12346 C: C: When a command has been processed successfully, the EPP element MUST contain a child element that identifies the container namespace and the location of the container schema. The element contains the same child elements defined for a transfer query response. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: CONTAINER-CocaCola-USA S: pending S: ClientX S: 2000-06-08T22:00:00.0Z S: ClientY S: 2000-06-13T22:00:00.0Z S: S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if a command can not be processed for any reason. 3.2.5 EPP Command The EPP command provides a transform operation that allows a client to modify the attributes of a container. In addition to the standard EPP command elements, the command MUST contain a element that identifies the container namespace and the location of the container schema. The element contains the following child elements: - A element that contains the server-unique identifier of the container object to be updated. - An OPTIONAL element that contains attribute values to be added to the container - An OPTIONAL element that contains attribute values to be removed from the container. - An OPTIONAL element that contains container attribute Brunner, et al Expires April 2002 [Page 25] Internet-Draft EPP Container November 2001 values to be changed. At least one , , or element MUST be provided. The and elements contain the following child elements. At least one child element MUST be present: - Zero or more elements that specify the server-unique identifiers of objects or containers that are included in the container. Each element MUST include one required "object" attribute for identifying the type of the child, and an OPTIONAL "type" attribute for identifying the sub-type of the child within the specific object type. The removal of any children of a container MUST ensure data integrity of all objects associated with the container, directly or indirectly. - Zero or more elements that contain status values to be associated with or removed from the container. When specifying a value to be removed, only the attribute value is significant; element text is not required to match a value for removal. A element contains the following OPTIONAL child elements. At least one child element MUST be present: - A element that contains the server-unique identifier of the new parent container of which the container is a child. The change of the container child-parent relationship MUST ensure data integrity of all objects associated with the container, directly or indirectly. - If supported by the server, an element that identifies the new registry provided template, which is a set of registry defined policies, in maintaining the container. - A element that contains authorization information associated with the container object. Example command: C: C: C: C: C: C: CONTAINER-CocaCola-USA Brunner, et al Expires April 2002 [Page 26] Internet-Draft EPP Container November 2001 C: C: C: ns4.cocacola.biz C: C: C: CONTAINER-CocaCola-All C: C: C: C: C: ABC-12346 C: C: When an command has been processed successfully, a server MUST respond with an EPP response with no element. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if an command can not be processed for any reason. 3.3 Formal Syntax for Container An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. Extensible Provisioning Protocol v1.0 container provisioning schema. Brunner, et al Expires April 2002 [Page 28] Internet-Draft EPP Container November 2001 Brunner, et al Expires April 2002 [Page 29] Internet-Draft EPP Container November 2001 Brunner, et al Expires April 2002 [Page 30] Internet-Draft EPP Container November 2001 Brunner, et al Expires April 2002 [Page 31] Internet-Draft EPP Container November 2001 Brunner, et al Expires April 2002 [Page 33] Internet-Draft EPP Container November 2001 4. EPP Command Mapping for Objects with Containers A detailed description of the EPP syntax and semantics can be found in [EPP]. The extended command mappings described here are specifically for use in provisioning and managing objects using containers via EPP. The objects can be maintained with containers specified here are domains. Other types of objects managed with containers will be included in the future as required. However, any objects included in a container cannot be removed via the commands, or modified via the command unless the data integrity of all objects associated with the container are ensured. The EPP commands that can be applied to domain objects MUST be or commands. In addition, the responses to commands MAY contains an OPTIONAL "container" element that indicating the container used in maintaining domain objects. Finally, in order to a domain object that is associated with a container, the association MUST be cut-off first via the command for nullifying its container value. 4.1 EPP Command for Domain Object With Container A domain object can be created with a container. The extended schema for domain object will include an OPTIONAL "container" element in the command. If the OPTIONAL "container" element is present in the command for creating a domain object, all other required elements described in [EPP-D], except for the fully required name of the domain object, become OPTIONAL. All other REQUIRED or OPTIONAL elements specified in [EPP-D] are derived from the container specified. If some of the REQUIRED elements cannot be found in the container or any of the ancestor containers of the container, the domain object will not be created. Any REQUIRED or OPTIONAL elements specified in the command will override the values derived Brunner, et al Expires April 2002 [Page 34] Internet-Draft EPP Container November 2001 from the container object. Example command with container: C: C: C: C: C: C: cocacola-ga.biz C: CONTAINER-CocaCola-USA C: CocaCola-Georgia C: C: C: C: ABC-12345 C: C: The response to a command is described in [EPP-D]. 4.2 EPP Command for Domain Object With Container Additional domain attribute values can be added or changed via the command to override the default values derived from containers. However, only attribute values specified via the command or added via the command can be removed, and data integrity of the domain object is ensured. When a domain object is associated with a container, the association can be cut-off or changed with another container. All attribute values for the domain object will be copied from containers into the domain object itself. When the element of the command for a domain object contains an OPTIONAL element, which is either empty or a server-unique container identifier, the association to the current container, if present, will be cut-off or changed to the new container. However, if the domain object does not associated with any container, the update command SHOULD fail. Example command for updating container association: C: Brunner, et al Expires April 2002 [Page 35] Internet-Draft EPP Container November 2001 C: C: C: C: C: cocacola-va.com C: C: CONTAINER-CocaCola-Virginia C: 2BARfoo C: C: C: C: C: ABC-12346 C: C: The response to a command is described in [EPP-D]. 4.3 EPP Command for Domain Object With Container If a domain object is associated with a container, the response data to the command will contain an OPTIONAL "container" element whose value is the server-unique identifier of the container used for maintaining the domain object. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: cocacola-va.biz S: COCACOLA-12-NEULEVEL S: S: CONTAINER-CocaCola-USA S: CocaCola-Corp S: CocaColaAdmin Brunner, et al Expires April 2002 [Page 36] Internet-Draft EPP Container November 2001 S: CocaColaTech S: CocaColaBilling S: ns1.cocacola.biz S: ns2.cocacola.biz S: ns1.cocacola.biz S: ns2.cocacola.biz S: ClientX S: ClientY S: 2001-04-03T22:00:00.0Z S: ClientX S: 2001-12-03T09:00:00.0Z S: 2005-04-03T22:00:00.0Z S: 2002-04-08T09:00:00.0Z S: 2fooBAR S: S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: 4.4 Formal Syntax for Domain Object with Container An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. Instead of giving a full XML Schema for domain object with container extension, the following is the diff output comparing to the original [EPP-D] schema. [Editor: This needs to be updated when EPP-D finishes WGLC.] *** domain-1.0.xsd Tue Jun 26 08:33:20 2001 --- domain-1.1.xsd Thu Aug 2 10:48:50 2001 *************** *** 1,7 **** ! ! Extensible Provisioning Protocol v1.0 ! domain provisioning schema. --- 18,24 ---- Extensible Provisioning Protocol v1.0 ! domain provisioning schema, with container extension. *************** *** 28,33 **** --- 28,42 ---- + + + + + + + *************** *** 44,49 **** --- 53,60 ---- Brunner, et al Expires April 2002 [Page 38] Internet-Draft EPP Container November 2001 + ! --- 63,70 ---- minOccurs="0"/> ! *************** *** 228,233 **** --- 240,246 ---- + , work in progress. [EPP-C] Hollenbeck, S., "EPP Contact mapping", Internet-Draft , work in progress. [EPP-D] Hollenbeck, S., "EPP Domain mapping", Internet-Draft , work in progress. [EPP-H] Hollenbeck, S., "EPP Host mapping", Internet-Draft , work in progress. [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [XML] Bray, T., et al, "Extensible Markup Language (XML) 1.0 (Second Edition)", 6 October 2000. http://www.w3.org/TR/REC-xml [XML-SCHEMA] XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. April 2000. http://www.w3.org/TR/2000/xmlschema-1/ XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. April 2000. http://www.w3.org/TR/2000/xmlschema-2/ Editors' Addresses Eric Brunner-Williams wampumpeag 1415 Forest Ave., Portland, ME 04103 Email: brunner@nic-naa.net Ayesha Damaraju NeuStar, Inc. 1120 Vermont Ave, N.W. Suite 400 Washington, DC 20005 Phone: +1 202 533 2600 Brunner, et al Expires April 2002 [Page 40] Internet-Draft EPP Container November 2001 Email: ayesha.damaraju@neustar.com Ning Zhang NeuStar, Inc. 1120 Vermont Ave, N.W. Suite 400 Washington, DC 20005 Phone: +1 202 533 2600 Email: ning.zhang@neustar.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Brunner, et al Expires April 2002 [Page 41]