Summary

  • RFC 3504 repaired IOTP v1 in three executable places: DTD grammar, the continuity of a transaction after authentication, and the list of content types that an IOTP signature could identify.
  • Applying the errata aligned an implementation with the corrected specification; it did not prove authentication success, signer authority, payment authorization, settlement, delivery, deployment or adoption.

Some protocol corrections look like punctuation. RFC 3504 changed one word from “restarted” to “continued.” In ordinary prose, the difference might appear editorial. Inside a transaction state machine, it decides whether software resumes the commercial context that reached an authentication gate or behaves as though the exchange began again.

The document was published in March 2003 as Informational, not as an Internet Standard. It collected errors found after the IOTP version 1 specifications appeared, especially the enormous RFC 2801. IOTP was a payment-system-independent framework for Internet commerce. Shopping, payment handling, delivery and customer support could be performed by different organizations, and the framework did not require a prior relationship between consumer and business.

That distribution of roles made exact protocol meaning consequential. A shopping site could hand payment work to a payment handler and delivery to another party. Messages, components and signatures had to retain enough structure for independently operated software to agree on what transaction and what act they were handling. A mistake in shared grammar or state language could travel across organizational boundaries.

RFC 3504's first correction concerned PackagedContent. In the original DTD, the types of its Name and Content attributes were swapped. The errata made Name an NMTOKEN and Content CDATA. This was not cosmetic metadata. PackagedContent was IOTP's extension envelope and appeared in authentication challenges and responses, order descriptions, brand data, payment-scheme material, receipts and delivery information.

An implementation generated from the old declaration could impose the wrong lexical constraint on a value. One parser might reject content another accepted. One generator might emit a value that fit its local schema yet failed elsewhere. “Supports RFC 2801” would then hide a version question: support for the printed DTD, or support for the corrected one?

The second grammar fix was smaller on the page. The element named Attribute was declared with ( ANY ), an incorrect content-model form. The corrected declaration was simply ANY. A validator cannot infer that an invalid grammar was intended to be liberal. If software could not compile the declaration, implementers might patch it differently, disable validation or write special cases. The erratum narrowed those divergent choices.

Grammar acceptance remained a limited receipt. A document that passed the corrected DTD showed that its element names, attribute classes and content structure matched the repaired contract. It did not show that an embedded claim was true, that a counterparty was authorized, or that an external payment system had moved money.

The third correction exposed a state boundary. RFC 2801 described combining an authentication transaction with another IOTP transaction. The original sentence said that after successful authentication, the original IOTP transaction was restarted. RFC 3504 replaced that word with continued.

The correction preserved identity across a gate. Authentication was a condition encountered within a larger exchange. When satisfied, processing moved forward in the original transaction context; it did not manufacture a second purchase or reset every prior decision. The distinction matters for transaction identifiers, accumulated components, idempotency records, authorization scope and the prevention of duplicate commercial acts.

“Continued” still did not assert that authentication had actually succeeded. The sentence described the consequence if it succeeded. A real system needed a separate authentication decision, tied to an actor, method, challenge, response and transaction. Nor did successful authentication authorize every later action. Payment and delivery remained their own exchanges, roles and receipts.

The fourth correction concerned IOTP signatures. RFC 2801 required a signature Attribute to state which IOTP signature type was represented. Its original list covered offer, payment, delivery, authentication request and response, plus ping request and response. The list omitted AuthenticationStatus, InquiryRequest and InquiryResponse.

RFC 3504 added all three and extended the role table so any role could use them. A verifier that treated the old list as exhaustive might reject a signature type the corrected specification allowed. A more permissive verifier might accept it without a clear dispatch rule. The erratum restored a shared mapping between a type marker and the class of IOTP content being signed.

Type recognition was not signature verification. Signature verification was not proof that the signer had commercial authority. Even an authentic inquiry response reported protocol state from some source; it did not alone prove that a bank settled funds, a delivery handler transferred goods, or a customer accepted an outcome. The receipt ladder had more steps.

RFC 3504 described its listed errors as not particularly security-related, then immediately warned that incorrect implementations caused by uncorrected specification errors could compromise security. The apparent tension is instructive. The mistakes did not introduce a new cryptographic algorithm or announce a named vulnerability. They altered the grammar, state transition and dispatch table on which security-sensitive processing relied.

This is why an erratum can become an executable dependency. An operator cannot adequately record “RFC 2801 implemented.” The build needs a specification bundle: base document, applied correction set, parser or schema artifact, and tests for the changed behaviors. Without that provenance, two conforming claims may refer to different machines.

The metadata history adds another layer. RFC 3504's header does not declare that it updates RFC 2801. The RFC Editor's current erratum 2947, held for a future document update, says it should be marked Updates: 2801 because it makes normative changes. The correction text existed even while the relationship metadata did not fully express its force.

That does not make every erratum silently normative. It means consumers must examine status, source and scope rather than treating an errata link as either harmless commentary or automatic law. A correction to executable grammar and state language needs explicit adoption and traceable implementation evidence.

An honest evidence chain therefore starts with the exact source edition and errata set. It continues through a reproducible parser or schema build, acceptance of a particular document, retention of transaction identity, a recorded authentication decision, recognition of the declared signature type, cryptographic verification, authorization of the business act, and external payment or delivery receipts.

Each rung answers a different question. Correct grammar says the message can be interpreted. Continuation says which transaction context survives. A type marker says what class of content a signature claims to cover. None of those statements, alone or together, says the purchase was paid and fulfilled.

RFC 3504's historical importance lies in that modesty. It shows how a six-page correction can determine the behavior of a much larger protocol without becoming the outcome of the commerce it coordinates. The errata repaired what implementations were meant to do. Reality still required its own receipts.

Sources