Extensible Provisioning Protocol (EPP) Contact Mapping
obsoleted by
- rfc-4933 — Extensible Provisioning Protocol (EPP) Contact Mapping
Extracted elements (28)
Postal address information may be provided in both an 'int' (internationalized, ASCII-subset UTF-8) and a 'loc' (localized, unrestricted UTF-8) form. This dual representation is provided so entities can supply a broadly readable ASCII form alongside a locally optimized native-script form.
XML is case sensitive; all XML specifications and examples in this document MUST be interpreted in the character case presented to develop a conforming implementation. UTF-8 encoding is RECOMMENDED in environments where parser encoding support incompatibility exists.
A contact object MUST always have at least one associated status value. Status values can be set only by the sponsoring client or the server, and a client MUST NOT alter status values set by the server.
A contact object SHOULD NOT be deleted if it is associated with other known objects; associated contacts SHOULD NOT be deleted until associations have been broken. A server SHOULD notify clients of object relationships when a <delete> fails due to existing associations.
A server MUST reject any transaction requesting disclosure practices that do not conform to the announced data collection policy with a 2308 error response code. The <contact:disclose> element MUST contain a required boolean 'flag' attribute and at least one child element.
All date-time values MUST be represented in UTC using the Gregorian calendar. The extended form using upper-case 'T' and 'Z' characters defined in RFC 3339 MUST be used; time zone offset identifiers MUST NOT be used with EPP.
Contact telephone numbers MUST begin with a plus sign ('+', ASCII 0x002B) followed by an E.164 country code, a dot ('.', ASCII 0x002E), and a digit sequence representing the telephone number.
For offline-reviewed transform commands, the server MUST return response code 1001, MUST manage the object status to reflect the pending action, and MUST notify all involved clients via a service message when the action is completed.
In the <update> command, at least one <contact:add>, <contact:rem>, or <contact:chg> element MUST be provided. Within <contact:chg>, at least one child element MUST be present.
pendingDelete MUST NOT be combined with clientDeleteProhibited or serverDeleteProhibited; pendingTransfer MUST NOT be combined with the corresponding transfer-prohibited values; pendingUpdate MUST NOT be combined with the corresponding update-prohibited values; and the four pending status values MUST NOT be combined with each other.
The <contact:authInfo> element returned in an <info> response MUST NOT be provided if the querying client is not the current sponsoring client. Similarly, <contact:upID> and <contact:upDate> MUST NOT be present if the object has never been modified; <contact:trDate> MUST NOT be provided if the object has never been transferred.
Transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set, with the sole exception that a <transfer> command to approve, reject, or cancel MAY be processed while in pendingTransfer status.
When a pending action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status MUST be removed and all clients involved in the transaction MUST be notified using a service message.
When postalInfo type='int' is provided, element content MUST be represented in a subset of UTF-8 representable in 7-bit US-ASCII. When type='loc' is provided, content MAY be unrestricted UTF-8.
The <contact:disclose> mechanism allows clients to identify fields requiring exceptional handling to allow or restrict disclosure to third parties. The server announces a default policy at session establishment; per-object overrides are set at create/update time and reviewable via <info>.
The <contact:check> command queries server availability of one or more contact identifiers. The response <contact:chkData> contains one <contact:cd> per queried ID, each with a required boolean 'avail' attribute and an optional <contact:reason> element for unavailable objects.
The <contact:create> command requires a contact id, one or two postalInfo elements, optional voice/fax, required email, required authInfo, and optional disclose. The response <contact:creData> returns only the id and creation timestamp.
The <contact:disclose> element allows clients to declare per-field disclosure exceptions to the server's announced data collection policy. Its required boolean 'flag' attribute indicates allow (1/true) or deny (0/false), and child elements identify affected fields: name, org, addr (each with int/loc type), voice, fax, and email.
The <contact:infData> response returns the full contact record: id, roid, status values, up to two postalInfo elements (int/loc types), optional voice/fax, required email, sponsoring client ID, creation/update/transfer timestamps, authInfo (only to sponsoring client), and optional disclose preferences.
The <contact:panData> pending action notification element contains id with a required boolean 'paResult' attribute (approved/denied), paTRID referencing the original client and server transaction identifiers, and paDate indicating when review was completed. It is delivered via the <poll> service message queue.
The <contact:trnData> transfer status element contains id, trStatus, requesting client ID (reID), request date (reDate), acting client ID (acID), and the deadline or completion date (acDate). It is used in both query and transform transfer responses.
The <contact:update> command accepts a contact id and at least one of <contact:add> (status values to add), <contact:rem> (status values to remove), or <contact:chg> (postal info, voice, fax, email, authInfo, disclose to change). A successful response carries no <resData> element.
This document registers two URIs in the IETF XML Registry per RFC 3688: the contact object namespace 'urn:ietf:params:xml:ns:contact-1.0' and the contact XML schema '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 authorization information is stored and exchanged with high-grade encryption to prevent unauthorized transfer operations and unauthorized information disclosure.
Contact object lifecycle states: 'ok' is the normal state (set/removed by server); client/server prohibit flags (clientDeleteProhibited, etc.) block corresponding operations; transform commands transition to pendingCreate/pendingDelete/pendingTransfer/pendingUpdate; on action completion the pending state is removed. 'linked' may be combined with any state; 'ok' may only be combined with 'linked'.
Postal line fields use postalLineType (minLength=1, maxLength=255, normalizedString) for required fields and optPostalLineType (maxLength=255) for optional fields. Postal codes use pcType (maxLength=16). Country codes use ccType (exact length=2, token), restricted to ISO 3166-1 values.
Telephone numbers use the e164Type: a string matching the pattern (\+[0-9]{1,3}\.[0-9]{1,14})? with a maximum length of 17 characters, extended with an optional 'x' attribute (token) for telephone extension information.
The statusType is a normalizedString extended with a required 's' attribute (statusValueType enumeration of 12 values) and an optional 'lang' attribute (XML language type, default 'en'). Up to 7 status elements may appear on a contact object.