Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping
Extracted elements (15)
New RDAP status values are derived from EPP status values by converting the EPP 'camelCase' representation to lowercase with a space character inserted between word boundaries (e.g., 'clientDeleteProhibited' becomes 'client delete prohibited').
The existing RDAP 'prohibited' statuses ('renew prohibited', 'update prohibited', 'transfer prohibited', 'delete prohibited') do not directly map to EPP prohibited statuses because EPP distinguishes whether an action is prohibited due to server policy versus a client request. This distinction must be preserved in RDAP, necessitating new status values.
This document covers EPP statuses from RFC 5731 (Domain Name Mapping), RFC 5732 (Host Mapping), RFC 5733 (Contact Mapping), and RFC 3915 (Domain Registry Grace Period Mapping). Not all EPP statuses apply to all object types (e.g., 'client hold' and 'server hold' apply only to domains).
Each EPP status MUST map to a single RDAP status to ensure that data in Domain Name Registries (DNRs) that use EPP can be accurately presented in RDAP.
Under 'server hold', the server sets the status so that DNS delegation information MUST NOT be published for the object.
Under 'server update prohibited', the server sets the status so that requests to update the object (other than to remove this status) MUST be rejected.
Under the 'client delete prohibited' status, requests to delete the object MUST be rejected because the client requested this restriction.
Under the 'client hold' status, DNS delegation information MUST NOT be published for the object, as requested by the client.
Direct EPP-to-RDAP status mappings that required no new registrations: 'ok' maps to 'active', 'inactive' maps to 'inactive', and 'linked' maps to 'associated'. All pending statuses map directly: pendingCreate/Delete/Renew/Transfer/Update map to their lowercase space-separated equivalents.
EPP client-prohibited statuses added to RDAP: 'client delete prohibited', 'client hold' (DNS delegation MUST NOT be published), 'client renew prohibited', 'client transfer prohibited', and 'client update prohibited' (all reflecting client-requested restrictions).
EPP grace period statuses added to RDAP: 'add period' (grace after initial registration, credit if deleted), 'auto renew period' (grace after server auto-renewal, credit if deleted), 'renew period' (grace after explicit client renewal, credit if deleted), and 'transfer period' (grace after successful sponsorship transfer, credit if deleted).
EPP redemption/restore statuses added to RDAP: 'redemption period' (delete received but object not yet purged, opportunity to restore exists) and 'pending restore' (object is in the process of being restored after being in redemption period state).
EPP server-prohibited statuses added to RDAP: 'server delete prohibited', 'server hold' (DNS delegation MUST NOT be published), 'server renew prohibited', 'server transfer prohibited', and 'server update prohibited' (all reflecting server-policy-imposed restrictions).
This document registers 15 new status values in the IANA 'RDAP JSON Values' registry (described in RFC 7483 Section 10.2): add period, auto renew period, client delete prohibited, client hold, client renew prohibited, client transfer prohibited, client update prohibited, pending restore, redemption period, renew period, server delete prohibited, server renew prohibited, server transfer prohibited, server update prohibited, server hold, and transfer period.
The status values described in this document can be subject to server-side information disclosure policies that restrict display of the values to authorized clients. Implementers may wish to review RFC 7481 for a description of RDAP security services that can be used to implement such information disclosure policies.