Extensible Provisioning Protocol (EPP) Change Mapping

Introduction A change request object enables the creation, deletion, clearing, withdrawal, and submission of an ordered set of Extensible Provisioning Protocol (EPP) transform commands that are linked to a change request object with a change request identifier. The linked EPP transform commands will be executed only when the change request object is submitted. This document describes a change object mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) . This mapping is specified using the XML 1.0 as described in and XML Schema notation as described in and .

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples is provided only to illustrate element relationships and is not a REQUIRED feature of this specification. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. The XML namespace prefix "change" is used for the namespace "http://www.verisign-grs.com/epp/change-1.0", but implementations MUST NOT depend on it; instead, they should employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.

An EPP change request object has attributes and associated values that may be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references.

All EPP Change Requests are identified by a server-unique identifier that is generated and provided by the client. Change Request Identifiers are character strings with a specific minimum length, a specified maximum length, and a specified format. Change Request Identifiers use the "clIDType" client identifier syntax described in . Its corresponding element is <change:requestID>.

The change request object contains a status value that can be made to support various state machine implementations. It is up to server policy to define a set of statuses. Each implementation will specify different behaviors for the submit operation of the <update> command as it is related directly to status modification. The status values will be defined out-of-band of the protocol. Some of the examples of status values are:

"initial": Change Request has been created
"submitted": Change Request has been submitted
"complete": Change Request has been completed

The change request object contains a priority value that can support order in which the change requests are implemented. It is up to server policy to define a set of priorities. The priority values will be defined out-of-band of the protocol. Some of the examples of priority values are:

"normal": Change Request need to be implemented within normal SLA
"urgent": Change Request need to be implemented within urgent SLA
"emergency": Change Request need to be implemented within emergency SLA

The change request object contains an operation value for the <update> command to define the operation being performed. Operation values are case sensitive. Supported values are:

"upAttrs": Update the change request attributes
"clear": Remove all change action objects associated with this change request
"submit": Submit the change request to promote to next status
"withdraw": Withdraw the change request after submission

The EPP <poll> command and response is defined in section 2.9.2.3 of . For servers that support a change request object, the Change Info Response, as defined in Section 3.1.2, is inserted into the poll queue. Example <poll> command:

C: C: C: C: 51364-CLI C: C:]]> Example <poll> response:

S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2025-07-23T20:28:12.816Z S: This Change Request has been completed S: S: S: S: tk421 S: normal S: EXAMPLE S: A change request within .EXAMPLE S: completed S: 2025-07-11 S: 2025-07-23 S: userA S: userA S: S: S: S: 51364-CLI S: SRV-43659 S: S: S:]]>

EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification . The command mappings described here are specifically for use in provisioning and managing change information via EPP.

EPP Query Commands This document provides two commands to retrieve change information: <check> to determine if a change request object can be provisioned within a repository and <info> to retrieve detailed information associated with a change request object. This document does not define a mapping for the EPP <transfer> command to retrieve change-object transfer status information.

EPP <check> Command The EPP <check> command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the <create> command, as object-provisioning requirements are ultimately a matter of server policy. In addition to the standard EPP command elements, the <check> command MUST contain an <change:check> element. This element or its ancestor element MUST identify the change namespace. The <change:check> element contains the following child elements:

One or more <change:requestID> elements that contain the server-unique identifier of the change request objects to be queried.

Example <check> command:

C: C: C: C: C: tk421 C: thx1138 C: C: C: 51364-CLI C: C:]]> When a <check> command has been processed successfully, the EPP <resData> element MUST contain a child <change:chkData> element that identifies the change namespace. The <change:chkData> element contains the following child elements: one or more <change:cd> elements that contain the following child elements:

The element MUST contain an "exists" attribute whose value indicates the object existence at the moment the <check> command was completed. A value "1" or "true" means that the change request identifier exists and cannot be provisioned. A value of "0" or "false" means that the change request identifier does not exist and can be provisioned.

Example <check> response:

S: S: S: Command completed successfully S: S: S: tk421 S: thx1138 S: S: S: S: 51364-CLI S: SRV-43659 S: S: S:]]> An EPP error response MUST be returned if a <check> command cannot be processed for any reason.

EPP <info> Command The EPP <info> command is used to retrieve change request information based on the specified Change Request Identifier. In addition to the standard EPP command elements, the <info> command MUST contain a <change:info> element that identifies the change namespace. The <change:info> element contains the following child elements:

A <change:requestID> element that contain the server-unique identifier of the change request objects to be queried.

Example <info> command:

C: C: C: C: C: tk421 C: C: C: 51364-CLI C: C:]]> When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <change:infData> element that identifies the change namespace. The <change:infData> element contains the following child elements:

An <change:requestID> element that contains the change request identifier, defined in Section 2.1.

An <change:priority> element that contains the defined priority of the change request, described in Section 2.3.

One or more <change:category> elements that contain the Top Level Domain (TLD) for the change request. The TLD may contain a single dot character (0x2e) to represent a change to the root zone.

An <change:desc> element that contains a freeform description of the purpose or reason for the change request.

An <change:status> element that contains the server defined status of the change request, defined in Section 2.2.

An <change:crDate> element that contains the date of change request creation.

An <change:upDate> element that contains the date of the most recent change request modification. The element MUST NOT be present if the change request has never been modified.

An <change:crID> element that contains the identifier of the client that created the change request object.

An <change:upID> element that contains the identifier of the client that last updated the change request object. The element MUST NOT be present if the change request has never been modified.

Zero or more <change:action> elements with the following change action elements:
- An OPTIONAL <change:requestID> element that contains the change request identifier, defined in Section 2.1.
- An OPTIONAL <change:cltrid> element that contains client transaction identifier.
- An <change:svtrid> elements that contains the server transaction identifier that is assigned by and unique to the server.
- An OPTIONAL <change:crDate> element that contains the date of the change action.

Example <info> response:

S: S: S: Command completed successfully S: S: S: tk421 S: normal S: EXAMPLE S: . S: A change request within .EXAMPLE S: initial S: 2026-09-21 S: 2026-10-30 S: userA S: userA S: S: tk421 S: 51125-CLI S: SRV-10122 S: S: S: tk421 S: SRV-10321 S: S: S: tk421 S: 51345-CLI S: SRV-10122 S: S: S: S: S: 51364-CLI S: SRV-43659 S: S: S:]]> An EPP error response MUST be returned if a <info> command cannot be processed for any reason.

EPP <transfer> Query Command The transfer semantics do not apply to change request objects. No EPP <transfer> query command is defined in this document.

EPP Transform Commands This document provides three commands to transform change request object information: <create> to create an instance of a change request object, <delete> to delete an instance of a change request object, and <update> to change information associated with a change request object. This document does not define a mapping for the EPP <transfer> and <renew> command.

EPP <create> Command The EPP <create> command is used to construct a new change request object. In addition to the standard EPP command elements, the <create> command MUST contain a <change:create> element that identifies the change namespace. The <change:create> element contains the following child elements:

An <change:requestID> element that contains the change request identifier, described in Section 2.1.
An OPTIONAL <change:priority> element that contains the defined priority of the change request, described in Section 2.3.
One or more <change:category> elements that contain the Top Level Domain (TLD) for the change request. The TLD may contain a single dot character (0x2e) to represent a change to the root zone.
An <change:desc> element that contains a freeform description of the purpose or reason for the change request.

Example <create> command:

C: C: C: C: C: tk421 C: emergency C: EXAMPLE C: A new request within .EXAMPLE C: C: C: 51364-CLI C: C:]]> When a <create> command has been processed successfully, the server MUST respond with an EPP response with no <resData> element. Example <create> response:

S: S: S: Command completed successfully S: S: 51364-CLI S: SRV-43659 S: S: S:]]> An EPP error response MUST be returned if a <create> command cannot be processed for any reason.

EPP <update> Command The EPP <update> command is used to modify an existing change request object. In addition to the standard EPP command elements, the <update> command MUST contain a <change:update> element that identifies the change namespace. The <change:update> element contains the following child elements:

An <change:requestID> element that contains the change request identifier, described in Section 2.1.
A choice of one of the following change request operation elements, described in Section 2.4:
- An <change:upAttrs> element to update the change request attributes that contains the following child elements, where at least one child element MUST be set:
  - An OPTIONAL <change:priority> element that contains the defined priority of the change request, described in Section 2.3.
  - Zero or more <change:category> elements that contain the Top Level Domain (TLD) for the change request. The TLD may contain a single dot character (0x2e) to represent a change to the root zone.
  - An OPTIONAL <change:desc> that contains a freeform description of the purpose or reason for the change request.
- An <change:clear> element to clear the change request actions. After execution of the clear operation, the change request will no longer be associated with any change request actions.
- An <change:submit> element to submit the change request. Once the change request has been submitted, it can only be withdrawn.
- An <change:withdraw> element to withdraw the change request. Once the submitted change request has been withdrawn, it can be deleted.

If the <change:upAttrs> element is present, then the change request record will be modified as specified by the <change:priority>, <change:category>, and <change:desc> elements. NOTE: The <change:upAttrs> element MUST not be empty. The schema will not allow a <change:upAttrs> element without at least one of the <change:priority>, <change:category> or <change:desc> elements, described in Section 2.3. If instead the <change:clear> element is present, then all change action objects associated with this change request will be removed. After execution the specified change request record will no longer be associated with any change action records. If instead the <change:submit> element is present, then the specified change request record is promoted to a new status. Statuses supported will be implementation specific. Example <update> command with <upAttrs>:

C: C: C: C: C: tk421 C: C: EXAMPLE C: . C: A change request within .EXAMPLE C: C: C: C: 51364-CLI C: C:]]> Example <update> command with <clear>:

C: C: C: C: C: tk421 C: C: C: C: 51364-CLI C: C:]]> Example <update> command with <submit>:

C: C: C: C: C: tk421 C: C: C: C: 51364-CLI C: C:]]> When an <update> command has been processed successfully, the EPP <resData> element MUST contain a child <change:updData> element that identifies the change namespace. The <change:updData> element contains the following child elements:

An OPTIONAL <change:receipt> element that contains a submission receipt from change request submit operation. No <change:receipt> element will be returned for non-submit operations.

NOTE: The <change:receipt> element will appear only in a response to a <update> command with the <change:submit< element. No receipt is required when updating attributes or clearing a Change Request. Example <update> response from an <update> command with a <change:submit> element:

S: S: S: Command completed successfully S: S: S: S: [+] Begin Change Request Summary: DO NOT EDIT BELOW S: S: Change Request Id: tk421 S: Request Priority: NORMAL S: Top-level domain: EXAMPLE S: Purpose/Description: A change request within .EXAMPLE S: S: Operations: S: S: Domain Create S: Name: EXAMPLE S: S: [-] End Change Request Summary: DO NOT EDIT ABOVE S: S: S: S: S: 51364-CLI S: SRV-43659 S: S: S:]]> Example <update> response from an <update> command with a <change:clear> or <change:upAttrs> element:

S: S: S: Command completed successfully S: S: S: S: S: S: 51364-CLI S: SRV-43659 S: S: S:]]> An EPP error response MUST be returned if a <update> command cannot be processed for any reason.

EPP <delete> Command The EPP <delete> command is used to delete a change request object before it is submitted. In addition to the standard EPP command elements, the <delete> command MUST contain a <change:delete> element that identifies the change namespace. The <change:delete> element contains the following child elements:

An <change:requestID> element that contains the change request identifier, described in Section 2.1, for the change request object to be deleted.

Example <delete> command:

C: C: C: C: C: tk421 C: C: C: 51364-CLI C: C: ]]> When a <delete> command has been processed successfully, the server MUST respond with an EPP response with no <resData> element. Example <delete> response:

S: S: S: Command completed successfully S: S: 51364-CLI S: SRV-43659 S: S: S: ]]> An EPP error response MUST be returned if a <delete> command cannot be processed for any reason.

EPP <renew> Command Renewal semantics do not apply to change request objects, so there is no mapping defined for the EPP <renew> command.

EPP <transfer> Command Transfer semantics do not apply to change request objects, so there is no mapping defined for the EPP <transfer> command.

Formal Syntax 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. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. Extensible Provisioning Protocol v1.0 Change provisioning schema END]]>

IANA Considerations

XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . The following URI assignment has been made by IANA: Registration request for the Change Mapping namespace:

URI:: http://www.verisign-grs.com/epp/change-1.0
Registrant Contact:: VeriSign Inc., <epp-registry@verisign.com>
XML:: None. Namespace URIs do not represent an XML specification.

Registration request for the Change Mapping XML Schema:

URI:: http://www.verisign-grs.com/epp/change-1.0
Registrant Contact:: VeriSign Inc., <epp-registry@verisign.com>
XML:: See the "Formal Syntax" section of this document.

EPP Extension Registry The EPP extension described in this document has been registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in . The details of the registration are as follows:

Name of Extension:: "Extensible Provisioning Protocol (EPP) Change Mapping"
Document Status:: Informational
Reference:: (insert reference to RFC version of this document)
Registrant Name and Email Address:: VeriSign Inc., <epp-registry@verisign.com>
TLDs:: Any
IPR Disclosure:: None
Status:: Active
Notes:: None

Security Considerations The mapping extensions described in this document do not provide any security services beyond those described by EPP and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.