Extensible Provisioning Protocol (EPP) Contact Mapping
Extracted elements (28)
Contact postal information supports two simultaneous representations via a 'type' attribute on <contact:postalInfo>: type='int' (internationalized, constrained to 7-bit ASCII-representable UTF-8 for broad readability) and type='loc' (localized, unrestricted UTF-8 for local optimization). This dual-form approach accommodates registries that must serve both international and local audiences without forcing a single encoding.
No mapping is defined for the EPP <renew> command because renewal semantics do not apply to contact objects; contacts have no expiration lifecycle unlike domain objects.
This document obsoletes RFC 4933. Key changes include: removal of pendingRenew status (since no <renew> mapping is defined), addition of the 2305 response code for delete failures due to associations, addition of the 2201 response code for unauthorized transform attempts, and updated normative references (RFC 5322 replacing RFC 0822, RFC 5730 replacing RFC 4930).
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 SHOULD NOT be deleted if it is associated with other known objects. A server SHOULD notify clients of existing object relationships by sending a 2305 error response code when a <delete> fails due to existing associations.
A server operator MUST reject any transaction that requests disclosure practices that do not conform to the announced data-collection policy, responding with a 2308 error response code.
Any attempt to transform an object by an unauthorized client MUST be rejected; the server MUST return a 2201 response code to note that the client lacks privileges to execute the requested command.
Date and time attribute values MUST be represented in UTC using the Gregorian calendar. The extended date-time form using upper-case 'T' and 'Z' characters defined in XML Schema MUST be used; time zone offset identifiers MUST NOT be used with EPP.
'pendingDelete' MUST NOT be combined with 'clientDeleteProhibited' or 'serverDeleteProhibited'; 'pendingTransfer' MUST NOT be combined with 'clientTransferProhibited' or 'serverTransferProhibited'; 'pendingUpdate' MUST NOT be combined with 'clientUpdateProhibited' or 'serverUpdateProhibited'. The four pending status values MUST NOT be combined with each other.
The <contact:authInfo> element MUST NOT be provided in an <info> response if the querying client is not the current sponsoring client. Similarly, <contact:upID> and <contact:upDate> MUST NOT be present if the contact has never been modified; <contact:trDate> MUST NOT be provided if the contact has never been transferred.
When a <create> command's internationalized postal info form (type='int') is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. The localized form (type='loc') MAY use unrestricted UTF-8.
When a server defers completion of a transform command for offline review, the server MUST return a 1001 response code, MUST manage the object status to reflect the pending action (e.g., pendingCreate), and MUST notify all involved clients via a service message when the action is completed.
The <contact:disclose> element enables clients to specify elements (name, org, addr, voice, fax, email in int/loc variants) that require exceptional server handling to allow or restrict third-party disclosure, overriding the server's default announced data-collection policy on a per-object basis.
A contact object is a named social information identifier stored in a shared central repository, identified by a server-unique identifier using the 'clIDType' syntax from RFC 5730. It carries postal address, telephone, email, authorization information, and optional disclosure preferences.
A contact object MUST always have at least one associated status value. Status values are prefixed 'client' when settable by the sponsoring client, 'server' when settable by the server, or unprefixed when server-managed. Valid values include: clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited, serverDeleteProhibited, serverTransferProhibited, serverUpdateProhibited, linked, ok, pendingCreate, pendingDelete, pendingTransfer, pendingUpdate.
The <contact:disclose> element allows a client to specify exceptional disclosure handling for individual data elements. It MUST contain a boolean 'flag' attribute ('true'/'1' to allow disclosure, 'false'/'0' to prohibit it) and at least one child element from: name(int), name(loc), org(int), org(loc), addr(int), addr(loc), voice, fax, email.
The EPP <check> command uses <contact:check> containing one or more <contact:id> elements. The response returns <contact:chkData> with <contact:cd> elements, each containing a <contact:id> with a boolean 'avail' attribute indicating whether the identifier can be provisioned.
The EPP <create> command's <contact:create> element requires: id, one or two postalInfo elements (type='int' or 'loc'), optional voice, optional fax, email, authInfo, and optional disclose. On success, the server returns <contact:creData> with id and crDate.
The EPP <info> response element <contact:infData> returns the full contact state: id, roid, one or more status values, up to two postalInfo elements (int/loc), optional voice and fax, email, sponsoring client ID, creator ID and date, last update ID and date (absent if never modified), last transfer date (absent if never transferred), authInfo (only to the sponsoring client), and optional disclose element.
The EPP <update> command's <contact:update> element contains the target id plus optional <contact:add>, <contact:rem>, and <contact:chg> elements. At least one of these MUST be provided unless an update extension is present. Add/rem elements carry status values; chg carries postalInfo, voice, fax, email, authInfo, and disclose.
The pending-action notification message <contact:panData> contains: <contact:id> with a boolean 'paResult' attribute (approved=true, denied=false), <contact:paTRID> with the original transaction IDs (client TRID is optional), and <contact:paDate> with the review completion timestamp.
The <transfer> query response element <contact:trnData> contains: id, trStatus (transfer state), reID (requesting client), reDate (request timestamp), acID (client that should act or did act), and acDate (deadline for pending response or completion timestamp).
This document registers two URIs in 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'.
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 that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services, as inadvertent disclosure can result in unauthorized transfers and unauthorized information release.
A contact object transitions into a pending state (pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate) when a transform command is processed but its action is not immediately completed. The pending status MUST be removed once the action is completed, and clients MUST be notified via a service message.
Country codes are represented as a 2-character string constrained to ISO 3166-1 values (ccType with exactly length 2). Postal codes are optPostalLineType with a maximum of 16 characters. Postal name/street/city/province lines are postalLineType with 1–255 characters.
Telephone numbers are encoded as e164Type: a string matching the pattern '(\+[0-9]{1,3}\.[0-9]{1,14})?' with a maximum length of 17 characters, plus an optional 'x' attribute for extension information. The number MUST begin with '+' followed by the ITU-T E.164 country code, a dot, then digits.
The <contact:transfer> command MUST carry an 'op' attribute identifying the transfer operation (query, request, approve, reject, or cancel as defined in RFC 5730), a <contact:id> element, and a <contact:authInfo> element containing the authorization credential.