Extensible Provisioning Protocol (EPP) Contact Mapping

No mapping is defined for the EPP <renew> command because renewal semantics do not apply to contact objects. Contacts have no expiration concept, unlike domain names.

This document obsoletes RFC 3733. Key changes include removal of a restriction on transform commands during pending states, clarification of the acID element semantics for non-pending transfers, and allowance for out-of-band notification of offline review results in addition to poll messages.

A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client subject to local server policies.

A contact object MUST always have at least one associated status value. Status values can be set only by the sponsoring client and the server.

registry

A contact object SHOULD NOT be deleted if it is associated with other known objects. A server SHOULD notify clients of object relationships when a <delete> command fails due to existing associations.

A server MUST reject any transaction that requests disclosure practices that do not conform to the announced data collection policy, returning a 2308 error response code.

privacy

At least one <contact:add>, <contact:rem>, or <contact:chg> element MUST be provided in an <update> command if the command is not being extended. All may be omitted if an update extension is present.

Date and time attribute values MUST be represented in UTC using the Gregorian calendar. The extended form using upper case 'T' and 'Z' characters as defined in the W3C XML Schema specification MUST be used; time zone offset identifiers MUST NOT be used with EPP.

Every EPP <transfer> command MUST contain an 'op' attribute identifying the transfer operation (request, approve, reject, cancel, or query) as defined in RFC 4930.

The <contact:authInfo> element in an <info> response MUST NOT be provided if the querying client is not the current sponsoring client.

security

The <contact:upID> and <contact:upDate> elements MUST NOT be present in an <info> response if the contact has never been modified. The <contact:trDate> element MUST NOT be provided if the contact has never been transferred.

The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other. Additionally, pendingDelete MUST NOT be combined with clientDeleteProhibited or serverDeleteProhibited, and analogous restrictions apply for pendingTransfer and pendingUpdate.

UTF-8 encoding is REQUIRED for all EPP XML documents. The XML Schema extended date-time form with upper case 'T' and 'Z' MUST be used; truncated forms and lower case characters are not supported.

When a pending action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status MUST be removed and all clients involved MUST be notified via a service message.

When a transform command is pending offline review, the server MUST return response code 1001, MUST manage object status to reflect the pending action, and MUST notify all involved clients when offline processing is completed.

The <contact:disclose> element enables clients to express per-element disclosure preferences (allow or restrict) for name, org, addr, voice, fax, and email fields. A flag value of '0'/'false' restricts disclosure; '1'/'true' permits it as an exception to the server's announced data collection policy.

privacy

Contact status values include clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited (client-settable), serverDeleteProhibited, serverTransferProhibited, serverUpdateProhibited (server-settable), linked, ok, pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate (server-managed).

The <contact:disclose> element allows a client to specify disclosure preferences for contact data elements. It MUST contain a 'flag' boolean attribute and at least one child element from: name (int/loc), org (int/loc), addr (int/loc), voice, fax, or email.

privacy

The EPP <check> command for contacts uses a <contact:check> element containing one or more <contact:id> elements. The response <contact:chkData> contains <contact:cd> elements each with an 'avail' boolean attribute and an optional <contact:reason> element.

The EPP <create> command for contacts requires a <contact:create> element with id, one or two postalInfo elements, optional voice/fax, email, authInfo, and optional disclose. The response <contact:creData> returns the id and crDate.

The EPP <info> response for contacts returns a <contact:infData> element containing id, roid, one or more status elements, up to two postalInfo elements (int/loc types), optional voice/fax, email, clID, crID, crDate, optional upID/upDate/trDate, conditional authInfo (only for sponsoring client), and optional disclose.

The offline review notification uses a <contact:panData> element containing id (with required 'paResult' boolean attribute indicating approval/denial), paTRID (original transaction identifiers), and paDate (review completion timestamp).

The <transfer> query response returns a <contact:trnData> element with id, trStatus, reID (requesting client), reDate, acID (acting client), and acDate (deadline or completion date).

This document registers two URIs with IANA via the IETF XML Registry (RFC 3688): the contact namespace URI 'urn:ietf:params:xml:ns:contact-1.0' and the contact XML schema URI 'urn:ietf:params:xml:schema:contact-1.0'.

registry

Authorization information is REQUIRED to create a contact object and is used in query and transfer operations to verify client authorization. Both client and server MUST ensure authorization information is stored and exchanged with high-grade encryption to provide privacy services, as inadvertent disclosure can result in unauthorized transfers and information release.

security, crypto

Country codes are represented as a 'ccType' restricted to exactly 2 characters per ISO 3166. Postal codes use 'pcType' with a maximum length of 16 characters. Street, city, and name fields use 'postalLineType' with min length 1 and max length 255.

Telephone numbers MUST begin with a plus sign ('+', 0x002B), followed by a country code per ITU E.164, a dot ('.', 0x002E), and digits. Maximum length is 17 characters. An optional 'x' attribute carries extension information.

The postalInfo element uses a 'type' attribute with enumerated values 'int' (internationalized, content restricted to 7-bit ASCII subset of UTF-8) or 'loc' (localized, content may be unrestricted UTF-8). Up to two postalInfo elements may appear per contact.