Summary

  • RFC 3529 used BEEP RPY for every XML-RPC methodResponse, including an XML-RPC fault; BEEP ERR was not the application-fault channel.
  • A completed BEEP exchange, a ready profile, privacy tuning and peer authentication were distinct from method authorization, procedure success and durable external effect.

The most revealing line in RFC 3529 was not a new XML tag. It was a rule about which BEEP frame carried bad news. A client sent an XML-RPC methodCall in MSG. The server returned the corresponding methodResponse in RPY. If the XML-RPC method produced a fault, that fault still travelled in RPY; the profile explicitly did not use BEEP ERR for it.

That choice made the layers visible. RPY was positive about the one-to-one BEEP exchange: a response had been generated and associated with the request. It was not a verdict on the remote procedure. The application verdict lived inside the XML document. An observer that counted every RPY as a successful RPC would turn precisely reported failures into false successes.

The distinction began before the call. RFC 3529 defined a two-state profile. A channel started in boot. The initiator sent bootmsg with a resource path. If the server recognized that resource, it answered with bootrpy and the profile entered ready. If the message was malformed or the resource unknown, it answered with BEEP error or ERR and the state did not advance.

Even ready was narrow evidence. It meant that this channel had bound to a recognized resource. It did not prove that every method name existed, that the caller could invoke it, that its parameters were valid, or that the requested action would finish. Those questions belonged to the XML-RPC application reached through the channel.

The URL schemes assembled another evidence chain. xmlrpc.beep and xmlrpc.beeps supplied an authority and a path. The authority became BEEP serverName; the path became the boot resource. Without an explicit port, DNS SRV could locate _xmlrpc-beep._tcp, followed by address lookup and the assigned service port when no suitable SRV record existed. Each step could succeed while the next failed. A registered name could resolve to an address; TCP could open; BEEP could greet; a channel could start; a resource could enter ready; and the eventual method could still return a fault.

The secure scheme added privacy, not magic. Before the XML-RPC profile started, xmlrpc.beeps required the BEEP session to be tuned for privacy through a transport-security profile or an authentication profile that also supplied transport security. When TLS was used, the client had to compare the URL authority with the server certificate identity. This strengthened the answer to “which protected peer did I reach?” It did not answer “was this method authorized?” or “did its business effect persist?”

The security section dates the experiment. Implementations were required to provide DIGEST-MD5 and a TLS profile using an RSA/3DES cipher suite, with client certificates for combined confidentiality and authentication. Those choices belonged to 2003. Later SASL and TLS documents changed the security landscape. The historical RFC should be read as a protocol-layering record, not as current cryptographic deployment advice.

Its registry requests were similarly bounded. RFC 3529 sought a BEEP profile identifier, two URI schemes and the xmlrpc-beep service on TCP port 602. Current registries can show that coordinated symbols exist. They cannot show that a listener is running, that one product implements the profile, that traffic uses it, or that a remote call succeeded.

The closest contemporary comparison, SOAP over BEEP, helps explain the architectural fashion: application envelopes could ride on a reusable session protocol rather than treating every operation as a new transport conversation. But the reusable substrate made layered receipts more important, not less. Channel success, message success and application success could no longer be safely collapsed into one green light.

An operator reconstructing one call therefore needed several records: the authority selected, the resolved endpoint, the protected peer identity, the channel and resource, the BEEP message number, whether the return frame was RPY or ERR, and whether the XML-RPC body contained normal parameters or a fault. For a state-changing method, another record was still needed: the application's own durable identifier, version, audit entry or later readback.

Retries exposed the cost of getting this wrong. A timeout before RPY did not reveal whether the method had executed. A received RPY containing a fault did reveal an application-level rejection, but not necessarily whether partial side effects occurred unless the method contract said so. Repeating a non-idempotent method merely because a generic dashboard missed the body could duplicate work.

RFC 3529 was Experimental. Its durable contribution is therefore not a claim that XML-RPC over BEEP won. It is a compact demonstration that success is owned by a layer. The outer protocol may successfully deliver a negative inner verdict. Good evidence preserves both truths.

Sources