Summary

  • RFC 3632 reused -Approve:No for two different acts: the current sponsoring registrar rejected a pending transfer, while the requesting registrar cancelled its own request. Authenticated actor, role, prior state and time supplied the meaning that the command text did not.
  • A 200 response establishes successful RRP command processing. It does not prove registrant intent, human consent, completed sponsorship change, DNS publication or service outcome.
  • Decision-grade evidence must join the protocol transcript to session identity, authority rule, transfer clock, before-and-after state, out-of-band notices and later observations. Saving the payload alone preserves syntax while losing governance.

A command does not contain its own speaker

Modern audit systems are comfortable with objects. They retain an API path, request body, response code and perhaps a hash. They are less disciplined about the relationship that made the object meaningful: who spoke, under which role, about which state, before which deadline, and with what power to alter it.

RFC 3632 offers a compact historical demonstration. Published in December 2003, it documented version 2.0.0 of the VeriSign Registry Registrar Protocol. It was Informational, not an Internet Standard. Its interest here is not that operators should revive RRP. It is that the protocol made an authority dependency impossible to ignore.

The transfer command could carry -Approve:No. In the hands of the current sponsoring registrar, that meant rejection of a transfer requested by someone else. In the hands of the registrar that had initiated the transfer, RFC 3632 made the same option a cancellation of its own pending request. The token “No” did not choose between opposition and withdrawal. The authenticated session did.

That distinction is not semantics in the academic sense. Rejection and cancellation assign agency to different institutions, trigger different explanations, and can carry different obligations to customers. A record that preserves the line of text while dropping the session principal has not merely lost context. It has lost the act.

The RFC Editor information record, IETF Datatracker, document history and errata search establish publication and maintenance facts. None proves deployment, adoption, compliance or the outcome of a particular transfer.

The earlier protocol already put identity outside the payload

RFC 2832, the earlier RRP specification, explains where the actor came from. The identity of a registrar requesting a transfer was derived from the current active session. The registry knew which registrar currently sponsored the domain. Those two facts let it distinguish the would-be gaining registrar from the incumbent.

This design matters because the visible command did not need to repeat a self-asserted institutional identity. Nor would such a field have been sufficient. A payload saying “I am the sponsor” is a claim; the authenticated session and registry record are the inputs that let the registry decide whether the claim is true for that object at that moment.

RFC 2832 allowed the current sponsoring registrar to approve or reject a request. An unauthorized registrar attempting either act had to receive a failure. It also required the registry to notify the potential losing registrar through an out-of-band method such as email or reporting. The operational record was therefore distributed from the start: session authentication, protocol exchange, registry state, and a separate notification path each carried part of the evidence.

The protocol’s known limitations sharpen the point. RFC 2832 says RRP responses did not return timestamps or transaction identifiers. The described daily and weekly reports supplied timestamps in the registry’s local time. A team trying to reconstruct one transfer could possess a valid command and a valid report yet still need to resolve clock basis, ordering and identity before making a reliable claim.

Cancellation existed before the syntax that exposed it

RFC 3375 recorded the requirements for a registry–registrar protocol. It made the role allocation explicit. A requesting registrar initiates the transfer. That same registrar may cancel its request before approval or rejection. The current sponsor may approve or reject. Attempts by other actors must fail. Both parties need ways to monitor pending and completed transfers.

RFC 3632 did not invent the institutional idea of cancellation. It added an RRP operation for it. The implementation choice was economical: use the existing transfer command and the existing negative approval value. Economy at the wire layer created a stronger burden at the evidence layer, because a transcript reader could no longer infer the operation from the option alone.

This is a recurring design trade-off. A compact protocol can avoid redundant fields because the server already holds session and object state. An audit warehouse assembled later may not. If the warehouse stores only the explicitly transmitted fields, it can be less informative than the running system that evaluated them. Evidence design must export the implicit inputs of the decision, not just the visible request.

Time was another argument to the command

Cancellation was not always available. The requesting registrar could cancel while the transfer remained pending and before the current sponsor explicitly approved or rejected it. A registry could also reach an implicit approval or rejection after a configured interval. Once either decision occurred, the old request no longer occupied the state in which cancellation was valid.

The action therefore depended on at least five joined facts: the authenticated registrar; whether that registrar was requester or sponsor; the exact domain object; the transfer’s current state; and the command’s position relative to the explicit or implicit decision. None can be safely reconstructed from -Approve:No.

This creates an irreversible boundary. Before decision, the requester may still withdraw. After decision, a new transfer or another corrective process may be needed. An operator who logs only eventual state can say where the object ended but not whether a cancellation arrived in time, was refused correctly, or lost a race with an automatic timer.

Clock quality is thus governance infrastructure. The receipt needs a server-side acceptance time, timezone or monotonic basis, the policy version that set the interval, and the event that closed the pending state. A local timestamp in a later report is useful, but only if its clock and relationship to the command stream are explicit.

“Command completed” is a bounded receipt

RFC 3632’s cancellation example ends with response code 200 and the text Command completed successfully. It would be a mistake to dismiss that response as meaningless. It is valuable evidence that the registry server accepted and completed the command according to the RRP exchange.

It would be a larger mistake to let the response answer questions it was never designed to answer. It does not establish that the registrant asked for cancellation, that a human approved it, that the registrar’s internal workflow was lawful, or that a different transfer did not begin later. It does not by itself prove a public DNS change, because sponsorship and delegation are different records. It does not prove what end users observed.

Every receipt has a subject. Here the subject is protocol execution. The registrar’s customer authorization belongs to another system; registry sponsorship belongs to registry state; nameserver delegation belongs to DNS publication; reachability belongs to running service. A reliable dossier links those layers without using one to impersonate another.

This is the practical force of Lu Heng’s Authority and Belief: a statement derives force from an issuer with a bounded scope. A registry server can authoritatively report how it processed an RRP command. That authority does not silently extend to the registrant’s intention or the Internet’s later observation.

Later EPP made more of the state legible

The later Extensible Provisioning Protocol offers a useful comparison. RFC 5731 gives domain transfers distinct operation values: request, cancel, approve, reject and query. A pending transfer response can expose the requesting client, request date, acting client, action date and pending status. RFC 5730 provides client and server transaction identifiers.

Those fields reduce ambiguity. A reader no longer needs to interpret one negative option as either rejection or cancellation solely from external actor state. Transaction identifiers also improve correlation across client and server records.

But explicitness is not magic. An identifier does not prove that every relevant system retained it. A requesting-client field does not prove registrant consent. An action date does not prove clocks were trustworthy. A successful EPP response does not prove DNS publication or application reachability. The newer model makes a better minimum receipt possible; operators still have to preserve and join it.

RFC 3730, the earlier EPP base specification, helps place the transition historically. It should not be read as proof that a named registry moved from one protocol to another at a particular time or implemented every field correctly. Standards describe interfaces. Deployment evidence must come from the deployment.

Encoding success answers an encoding question

RFC 3632 added response code 510 for an invalid domain-name encoding during ADD or MOD operations. In its period, the document referred to an ASCII-compatible encoding and delegated validation to the registry’s rules. Later IDNA terminology, including the distinctions organized by RFC 5890, gives modern readers a more developed vocabulary.

The evidence boundary remains simple. Accepting a representation establishes that the input passed a syntax and policy check at a particular interface. It does not prove trademark rights, organisational identity, user intention, delegation, safe display or semantic equivalence to some other string. Rejecting it with 510 similarly reports an interface result, not a universal judgment about the name.

This is another example of a response code having a precise but limited issuer. A registry parser may be authoritative about what it accepted. It is not the sole authority for every identity or policy question attached to the label.

An IPv6 address in a host object is not a reachability claim

RFC 3632 also let nameserver objects carry IPv6 addresses, in full or compressed textual forms. RFC 4291 supplies the addressing architecture, while RFC 5952 later recommended a canonical text representation.

A parser accepting an IPv6 string proves a representation result. A registry saving it proves a registry-data transition. Neither proves that the address was placed in a delegation, routed, reachable, serving authoritative DNS correctly, or visible from the user’s network. These are different tests with different observers.

The temptation to collapse them is strong because all may be represented by a single “nameserver healthy” badge. Leadership should resist it. Preserve the host object, delegation set, root or parent-zone publication, routing view, DNS protocol answers and geographically distributed probes as separate evidence. Agreement is informative; disagreement is the signal that one layer has drifted.

Code 557 drew a boundary around the root

Response code 557 meant a nameserver object was locked because it was associated with a top-level domain. RFC 3632 directed the registrar to coordinate an update out of band with registry support. The lock did not say that change was impossible. It said the ordinary registrar path lacked unilateral authority.

Current IANA root-zone management is a separate contemporary system. Its management guidance, consent process, nameserver technical requirements and credentialed RZMS API illustrate multiple controls: authenticated users have bounded permissions; contacts or managers authorize changes; changes affecting shared nameservers may involve other parties; technical checks test a baseline; implementation and later verification remain distinct steps.

Those pages do not explain an old RRP transaction, and RRP did not define today’s root process. Their value is architectural. A host object inside a registry, a TLD nameserver configuration, an authorized root-zone request, an implemented root change and working authoritative service are not one state. Code 557 was a refusal to let a lower control surface pretend otherwise.

The minimum receipt is a join, not a bigger payload

The answer is not to place every business fact inside every command. That would make the protocol the sovereign of systems whose decisions it cannot own. The more useful approach follows Heng’s Minimum Initial Specification: standardise the smallest portable evidence interface and leave later authorities free to make their own bounded decisions.

For a transfer, that minimum joins protocol and implementation version; authenticated client identifier; requester and current sponsor; object; request time; before-state; command bytes; policy and timer version; authorization evaluation; server response; after-state; out-of-band notices; later explicit or implicit action; final sponsorship state; and any DNS or service observations being claimed.

Heng’s Reality Layers supplies the discipline for presenting it. The symbolic command, institutional authority, registry record, DNS publication and lived network result can be correlated without being declared identical. Running Code Primary adds the test: formal semantics matter, but the executed transition and observed result must be retained.

The consequence is a better incident question. Do not ask only, “What command was sent?” Ask, “Which authenticated actor, occupying which role, changed which state under which rule before which deadline, and what did every downstream authority subsequently record?” The first question retrieves a line. The second reconstructs an act.

The missing actor is not missing metadata

RFC 3632 is easy to treat as a historical protocol note. Its deeper lesson is current. Compact interfaces often rely on authenticated context and server state that disappear when events are exported to a generic log. The export then looks exact because it preserves every character of the payload. Exactness of text can coexist with ambiguity of authority.

The same “No” was able to reject or cancel because the speaker and state were part of the language. Preserve them, and the old command becomes legible. Discard them, and even a successful response can no longer tell leadership who exercised power.

Sources

  1. RFC 3632 — VeriSign Registry Registrar Protocol Version 2.0.0
  2. RFC 3632 plain text
  3. RFC Editor information for RFC 3632
  4. IETF Datatracker record for RFC 3632
  5. IETF history for RFC 3632
  6. RFC 3632 errata search
  7. RFC 2832 — Network Solutions Registry Registrar Protocol Version 1.1
  8. RFC 3375 — Generic Registry-Registrar Protocol Requirements
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — EPP Domain Name Mapping
  12. RFC 5732 — EPP Host Mapping
  13. RFC 4291 — IP Version 6 Addressing Architecture
  14. RFC 5952 — A Recommendation for IPv6 Address Text Representation
  15. RFC 5890 — IDNA Definitions and Document Framework
  16. IANA — Root Zone Management
  17. IANA — Managing a Top-Level Domain
  18. IANA — Obtaining Consent for a Root Zone Change
  19. IANA — Nameserver Technical Requirements
  20. IANA — Root Zone Management System API
  21. Lu Heng — On Authority and Belief
  22. Lu Heng — On Reality Layers
  23. Lu Heng — Running Code Primary
  24. Lu Heng — Minimum Initial Specification