Extensible Provisioning Protocol (EPP) Organization Mapping
Extracted elements (26)
Transfer and renew semantics do not apply to organization objects, so no EPP <transfer> or <renew> command mappings are defined. This reflects that organizations are managed entities without the subscription lifecycle of domain names.
This mapping extends EPP version 1.0 (RFC 5730) and inherits the internationalization conventions of the core protocol. UTF-8 encoding is RECOMMENDED; conformant XML processors must also support UTF-16.
A client MUST NOT alter server status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies.
An organization object MUST always have at least one associated role. Roles can be set only by the client that sponsors an organization object.
An organization object MUST NOT be deleted if it is associated with other known objects. A server MUST notify clients of existing object relationships by sending a 2305 error response code when a delete fails due to existing associations.
Date and time attribute values MUST be represented in UTC using the Gregorian calendar, with the extended date-time form using uppercase 'T' and 'Z' characters as defined in XML Schema.
Implementations MUST NOT depend on the 'org' XML namespace prefix; they should employ a proper namespace-aware XML parser and serializer, as the namespace URI 'urn:ietf:params:xml:ns:epp:org-1.0' is what matters.
Parent identifier loops MUST be prohibited: if organization A has organization B as its parent identifier, organization B cannot have organization A as its parent identifier, and this extends to larger loops involving three or more organizations.
'pendingDelete' status MUST NOT be combined with either 'clientDeleteProhibited' or 'serverDeleteProhibited' status, and the pendingCreate, pendingDelete, and pendingUpdate status values MUST NOT be combined with each other.
When a server defers completing a transform action for offline review, it MUST return response code 1001 and MUST notify the client via a service message (poll) when the offline action is completed.
An organization role consists of a mandatory type field (<org:type>), optional role statuses (<org:status>), and an optional third-party-assigned role identifier (<org:roleID>) such as the IANA ID for registrars.
Organization status values include server-managed states (ok, hold, terminated, linked) and client/server-prefixed prohibitions (clientDeleteProhibited, serverUpdateProhibited, clientLinkProhibited, etc.) plus pending states (pendingCreate, pendingUpdate, pendingDelete). 'pendingCreate', 'ok', 'hold', and 'terminated' are mutually exclusive; an organization MUST have exactly one of these.
Role status values are a restricted subset: ok, linked, clientLinkProhibited, and serverLinkProhibited. A role SHOULD have at least one associated status value.
The EPP <check> command for organizations uses <org:check> containing one or more <org:id> elements. The response returns <org:chkData> with <org:cd> elements, each containing an <org:id> with a boolean 'avail' attribute and an optional <org:reason> element.
The EPP <create> command uses <org:create> containing id, one or more roles, optional status values, optional parentId, zero to two <org:postalInfo> elements (type 'int' or 'loc'), optional voice/fax/email/url, and zero or more contact elements. The response returns <org:creData> with id and crDate.
The EPP <info> response for organizations returns <org:infData> containing id, roid, one or more roles, status values, optional parentId, postal info (up to two forms: 'int' and 'loc'), voice, fax, email, url, contacts, clID, crID, crDate, and optional upID/upDate fields.
The EPP organization object is identified by a server-unique identifier using the 'clIDType' client identifier syntax from RFC 5730. The corresponding XML element is <org:id>.
The EPP <update> command uses <org:update> containing the organization id, optional <org:add> and <org:rem> elements (for contacts, roles, and statuses), and an optional <org:chg> element (for parentId, postalInfo, voice, fax, email, url). At least one of add, rem, or chg MUST be provided unless an update extension is present.
The <org:panData> pending action notification element contains an <org:id> with a boolean 'paResult' attribute (approval/denial), an <org:paTRID> with client and server transaction identifiers, and an <org:paDate> timestamp for when the review was completed.
The parent identifier (<org:parentId>) represents the parent organization in a child organization, enabling N-tier hierarchies such as registrar-reseller chains. Loops in the parent-child relationship MUST be prohibited.
IANA created the 'EPP Organization Role Values' registry with Expert Review policy. Initial values are: registrar, reseller, privacyproxy, and dns-operator, each with a description and IESG as registrant.
IANA registered the organization XML namespace URI 'urn:ietf:params:xml:ns:epp:org-1.0' and schema URI 'urn:ietf:params:xml:schema:epp:org-1.0' in the IETF XML Registry per RFC 3688, and registered the EPP extension in the EPP Extension Registry per RFC 7451.
The organization object may contain personally identifiable information such as <org:contact>. If PII is provided, both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services as specified in RFC 5733. The security considerations of RFC 5730 also apply.
Contact elements use the contactType with a required 'type' attribute restricted to: admin, billing, tech, abuse, custom. An optional 'typeName' attribute defines the name of a 'custom' type.
Postal info supports two forms via a required 'type' attribute: 'int' (internationalized, content restricted to Unicode U+0020-U+007E) and 'loc' (localized, unrestricted UTF-8). Up to two <org:postalInfo> elements may be present. The <org:name> field is a normalizedString of 1-255 characters; postal code (pc) is limited to 16 characters; country code (cc) is exactly 2 characters.
Telephone number fields (voice, fax) use the e164Type with pattern '(\+[0-9]{1,3}\.[0-9]{1,14})?' and a maximum length of 17 characters, plus an optional 'x' attribute for extension.