Summary

  • RFC 5731 gives clientTransferProhibited and serverTransferProhibited a strong, narrow effect: requests to transfer the domain object must be rejected.
  • The code identifies the side that controls the status, but not the policy cause, human authority, review date or security of the account and process behind it. Even a rationale string is optional.
  • A defensible transfer decision joins a time-bounded status receipt to a separate decision receipt, while tracking update, deletion, renewal, DNS and account controls independently.

A prohibition is a predicate, not a biography

The most useful word in RFC 5731's transfer-status definition is “must.” This is no vague hint to an operator. clientTransferProhibited and serverTransferProhibited require the server to reject requests to transfer the domain object. A monitoring system that observes either status has learned something consequential about what the EPP command path will accept at that moment.

Trouble begins when the observation is made to explain itself. A product may translate the status into “owner protected,” “security incident,” “registry lock,” or simply “safe.” None of those labels is contained in the token. The protocol says what should happen to a transfer request. It does not say why the restriction was chosen.

RFC 5731 permits human-readable text describing the rationale to accompany a status. The permission is optional. A conforming object can carry the status without a mandatory reason, case number, instruction from the registrant, expiry time or evidence that anyone reviewed it recently. Absence of that text is not protocol failure. It is a warning that the explanation has to come from another record.

This distinction makes the status more useful, not less. A narrow field can be compared reliably across implementations. Asking it to carry consent, policy, identity and incident history would turn a clear protocol predicate into an ambiguous dossier.

The prefix names a control side

The two transfer prohibitions are not duplicates. RFC 5731 uses the client prefix for a status added or removed by the sponsoring client, normally the registrar in the registry–registrar relationship. The server prefix belongs to the server, normally the registry. A client cannot alter a server-set status; a server may alter or override a client-set status subject to local server policy.

That grammar locates a control surface. It still does not identify the person or policy behind a particular decision. A registrar may set a client status automatically at registration, after a holder's request, as part of a time-limited policy lock, or while resolving an account problem. A registry-side prohibition may accompany a dispute, a registrant-requested service, redemption or another local-policy condition. The same visible code can therefore be the projection of different decisions.

ICANN's registrant guidance reflects the operational difference. It describes client codes as registrar-set and server codes as registry-set. To remove a client transfer prohibition, a holder normally goes to the registrar. For a server prohibition, the registrar may have to work with the registry, so release can take longer. That tells the operator where to begin. It does not allow an observer to guess the cause.

Policy owns the reason the protocol does not contain

For ICANN-accredited registrar transfers in its stated scope, the current Transfer Policy supplies a layer that RFC 5731 deliberately does not. It distinguishes who can authorize a transfer, how a gaining registrar submits the request, when a registrar of record may deny it, and when a reason must be given.

The listed grounds are not one security story. Evidence of fraud is different from a reasonable dispute over the holder's identity. A defined non-payment case is different from an express objection by the holder. Court and dispute proceedings, recent registration or transfer, and a Change of Registrant lock have their own authority and timing. A dashboard that maps all of them to “suspected hijack” is inventing evidence. One that maps all of them to “holder requested” makes the opposite mistake.

The policy also limits what the bare fact of a registrar lock can accomplish. A transfer may not be denied merely because the domain is in registrar-lock status unless the holder has a reasonable opportunity and ability to unlock it before the request. For an express general objection, informed opt-in and an accessible removal path matter. The protocol token enforces the current state; the policy record explains whether the state is justified and how it changes.

This is why two receipts are required. The status receipt answers: which domain, which exact status, observed where, at what time, and superseded by what later state? The decision receipt answers: who requested or imposed it, under which rule, using what authorization, until what review or expiry condition, with which notification and removal route?

One status can project several clocks

A transfer restriction has at least three clocks. The server clock determines when the status became effective in authoritative EPP state. The policy clock determines when the reason became valid and when review or expiry is due. The observation clock records when RDAP, Whois, a registrar portal or a monitoring vendor happened to see and render the state.

Those clocks need not align. A public response can be cached. A portal can retain a friendly label after an operator action. A policy case can expire before its projection is removed, or a status can be lifted before a downstream monitor refreshes. A screenshot proves what one interface displayed at one time. It does not automatically prove the server's current value, the setter, or the underlying decision.

The protocol supplies one valuable consistency test. RFC 5731 says pendingTransfer cannot coexist with either transfer-prohibited status. Pending means a transfer action has been processed but not completed; prohibited means the transfer request must be rejected. When a dataset shows both, the first questions should concern observation time, cache age, aggregation from several sources or malformed presentation. The contradiction is evidence that the record needs reconstruction, not instant proof of fraud or registry non-conformance.

“Locked” does not cover every verb

Everyday language makes lock sound comprehensive. EPP names several different prohibitions because the controlled verbs differ. Transfer, update, delete and renew each have client and server forms. Hold status affects DNS delegation publication. A domain can reject transfers while remaining exposed to an account takeover that changes contact information or removes the client-set status. Conversely, a tightly controlled registry-lock product may add out-of-band approval well beyond what the visible EPP token says.

ICANN's security guidance makes the layering explicit. It presents a transfer lock as useful protection but not a fail-safe, and separately advises holders to secure their account information and consider multistep authentication. The practical lesson is not to collect every green icon. It is to state which action each control constrains and which credential or actor can change it.

A complete operational record therefore keeps transfer state apart from registrar-account authentication, privilege changes, authorization-information handling, update and deletion restrictions, DNS delegation, renewal and recovery contacts. These controls may reinforce one another. None inherits proof from the status name beside it.

Hollenbeck's role is also a scoped attribution

RFCs 5730 and 5731 name Scott Hollenbeck as their author. The IETF Datatracker says he has participated since the mid-1990s, chaired several working groups and served as Applications Area Director from 2004 to 2006. Its current snapshot lists 39 RFCs associated with him.

Those facts establish an unusually substantial standards contribution. They do not make Hollenbeck the operator of a registry, the author of ICANN's transfer decision in a particular case, or the controller of anyone's domain. His name belongs to the specification's provenance, just as a registrar or registry belongs to the provenance of a status change. Precise attribution does not diminish the contribution; it prevents credit from becoming imaginary authority.

Keep the command result and the decision reason together

The minimum useful evidence package begins with the domain, exact status value, authoritative or observed source, time and next state. It adds the EPP transaction or query identifiers when available. It then links, without merging, the external decision: policy or contract version, requesting party, accountable registrar or registry role, authorization evidence, start time, expiry or review trigger, notification, removal path and eventual outcome.

If a transfer is actually attempted, preserve a third receipt: request time, relevant authorization handling, server result, any pending state, denial reason delivered under the applicable policy and final resolution. Secrets and unnecessary personal data do not belong in that record. The provenance needed to explain a consequential denial does.

The strongest countercase should remain visible. A transfer prohibition is real protection. While present in a conforming server state, it blocks the transfer request. Default registrar locks and carefully operated registry-lock services can materially increase resistance to hijacking. The error is not trusting the protocol. It is trusting the protocol to testify about decisions outside its field.

Hollenbeck's mapping gives operations a clean sentence: reject this class of command. The institution applying it owes the rest of the sentence. Who decided? On what authority? For how long? Who can reverse it? A status can stop a transfer. Only attributable evidence can explain the lock.

Sources