rfc-8590

Change Poll Extension for the Extensible Provisioning Protocol (EPP)

J. Gould, K. Feher

date2019-05 streamIETF areaops wgregext statusPROPOSED STANDARD pages20 canonicalhttps://www.rfc-editor.org/rfc/rfc8590 doi10.17487/RFC8590 errataview

This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.

Extracted elements (24)

design-rationale §2.3

The <changePoll:who> element is explicitly described as a free-form audit field not intended to drive client-side logic. This design choice acknowledges that the identifier scheme is server-policy-dependent and prevents clients from incorrectly relying on its format for automation.

design-rationale §1

The extension only extends the EPP <poll> response and does not extend the EPP <poll> command. This design allows clients to receive server-initiated change notifications via the existing poll mechanism without requiring changes to client-side command processing.

design-rationale §2.2

The extension supports both 'before' and 'after' state poll messages for a single operation, using separate poll messages for each state. This allows sponsoring clients to reconstruct exactly what changed on their objects without requiring direct participation in the operation.

interoperability-note §2.1

The 'restore' operation references RFC 3915 (Domain Registry Grace Period Mapping) and MUST set the 'op' attribute to either 'request' or 'report'. Implementations must be aware of this dependency on the grace period extension for restore sub-operation semantics.

interoperability-note §3

This extension only applies to the EPP <poll> response and does not add elements to any EPP command (<check>, <info>, <transfer>, <create>, <delete>, <renew>, <update>). Clients need not modify their command handling to support this extension.

normative-requirement §2.4 MUST

Date and time values MUST be represented in UTC using the Gregorian calendar, using the extended date-time form with uppercase 'T' and 'Z' characters as defined in XML Schema Part 2. Truncated date-time forms and lowercase 'T'/'Z' are not permitted.

normative-requirement §2.2 MUST

For operations that have no 'after' state (e.g., 'delete' with op='purge', 'autoPurge'), the server MUST use the 'before' state poll message, including the object's state prior to the operation.

normative-requirement §2.2 MUST

For operations that have no 'before' state (e.g., 'create'), the server MUST use the 'after' state poll message, including the object's state after the operation.

normative-requirement §2.1 MUST

For the 'custom' operation, the 'op' attribute MUST be set with the custom operation name. The supported custom operations are up to server policy.

normative-requirement §2.1 MUST

For the 'transfer' operation, the 'op' attribute MUST be set to one of: 'request', 'approve', 'cancel', or 'reject'.

normative-requirement §2.1 MUST

If the 'delete' operation results in an immediate purge of the object, then the 'op' attribute MUST be set to 'purge'. The same requirement applies to the 'autoDelete' operation.

normative-requirement §1.1 MUST NOT

Implementations MUST NOT depend on the 'changePoll' XML namespace prefix; instead they MUST employ a proper namespace-aware XML parser and serializer to interpret and output XML documents.

normative-requirement §2.2 MUST

When both 'before' and 'after' state poll messages are generated for an operation, the 'before' state poll message MUST be inserted into the message queue prior to the 'after' state poll message.

normative-requirement §1.1 MUST

XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation, because XML is case sensitive.

protocol-element §3.1.2

The <changePoll:caseId> element is an optional case identifier associated with the operation. Its required 'type' attribute is one of 'udrp', 'urs', or 'custom'; a 'name' attribute further qualifies custom case types using 7-bit US-ASCII.

protocol-element §3.1.2

The <changePoll:changeData> element is the root extension element carrying operation detail in EPP poll responses. It contains child elements: <changePoll:operation>, <changePoll:date>, <changePoll:svTRID>, <changePoll:who>, optional <changePoll:caseId>, and optional <changePoll:reason>, plus a 'state' attribute defaulting to 'after'.

yang, registry

protocol-element §2.1

The <changePoll:operation> element defines the transform operation type. It supports an enumerated set of values (create, delete, renew, transfer, update, restore, autoRenew, autoDelete, autoPurge, custom) and an optional 'op' attribute for sub-operations or custom operation names.

protocol-element §3.1.2

The <changePoll:reason> element is an optional free-text explanation for the operation. It MUST be in the language previously negotiated with the client, with an optional 'lang' attribute to identify a non-English language.

protocol-element §2.3

The <changePoll:who> element identifies who executed the operation for audit purposes. It is a free-form string (1–255 characters of normalizedString) representing an identifier, name, or role; its value scheme is up to server policy and is not intended to drive client-side logic.

registry §5.2

RFC 8590 registers the 'Change Poll Extension for the Extensible Provisioning Protocol (EPP)' in the EPP Extension Registry (RFC 7451) as a Standards Track extension applicable to any TLD, with Active status.

registry

registry §5.1

RFC 8590 registers the XML namespace 'urn:ietf:params:xml:ns:changePoll-1.0' in the IETF XML Registry (RFC 3688) with IESG as registrant contact.

registry

security-consideration §6

The changePoll extension does not provide any security services beyond those described by EPP (RFC 5730) and the protocol layers used by EPP. All security considerations from those specifications apply to this extension as well.

security

wire-format §4.1

The changeDataType XML complex type defines the wire structure: a sequence of operation (operationType), date (dateTime), svTRID (epp:trIDStringType), who (whoType, 1–255 char normalizedString), optional caseId (caseIdType), and optional reason (eppcom:reasonType), plus a 'state' attribute of stateType defaulting to 'after'.

wire-format §4.1

The operationType extends operationEnum (token-restricted enumeration) with an optional 'op' attribute of type token for sub-operations. The caseIdType extends token with a required 'type' attribute (caseTypeEnum: udrp, urs, custom) and optional 'name' attribute of type token.