Summary

  • RFC 3940 gave each in-flight NormObject a sender-scoped transport number for delivery and repair, not a global or permanent content identity.
  • The number occupied a finite 16-bit space and could repeat; durable naming had to come from application-defined NORM_INFO or from the content itself.

The receiver needed a small answer first

A sender has one large file and thousands of receivers. Some packets vanish on some paths, different receivers miss different pieces, and asking every receiver to acknowledge every packet would create more feedback than the network could comfortably carry. The NACK-Oriented Reliable Multicast protocol approached the problem from the other direction. Receivers remained quiet when delivery worked and asked for repair when something was absent. Forward-error-correction data could repair losses without reproducing every missing original packet.

That machinery needed a practical answer to a small question: which transmitted object did this segment or repair belong to? RFC 3940, published as Experimental in November 2004, supplied an object_transport_id. A sender allocated the value monotonically, and transmissions and repair requests for that object reused it. Together with the sender identifier carried by the protocol, it distinguished one NormObject while that object was moving through the session.

It was enough for transport. It was not the name of the content.

Three containers did not define three meanings

NORM offered static memory data, a file and a non-finite stream as its three object types. Even this classification was more operational than semantic. The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE merely hinted whether a receiver should allocate memory or non-volatile storage. Apart from that storage choice, the protocol treated both as finite content units. An application could even use the stream service for static data.

The labels therefore did not tell a receiver that an object was “the June ledger,” “version 7 of the map,” or “the signed emergency bulletin.” They told the receiver how a transmission should be handled. The difference matters whenever protocol fields are promoted into records they were never designed to become. A storage hint is not a content class. A repair sequence is not provenance. A successful decode is not proof that the recovered bytes belong to the business object a database expects.

Sixteen bits marked a journey, not a lifetime

The object field was 16 bits. RFC 3940 said it could be repeated in very long or indefinite sessions and assumed the sequence space was large enough to prevent confusion when receivers re-synchronized around implausibly distant values. Each sender assigned its own sequence independently. A bare number such as 817 therefore said little: it needed a sender, a sender instance, current session state and a moment in the transmission sequence.

The specification drew the boundary in unusually direct language. NORM message headers did not provide global or application-level identification of data content. Its transport identifiers applied only while the sender was transmitting or repairing the object. The counter's order was useful precisely because it was local and cheap. Giving it permanent meaning would have converted that efficiency into hidden state: every cache and archive would have needed to remember which sender, which session and which turn of the counter a reused value belonged to.

Five years later, RFC 5740 obsoleted the experiment and placed NORM on the Standards Track. It retained the separation and made the wraparound statement categorical: in a long-lived session the field will wrap and repeat. Standardization improved the transport specification; it did not quietly promote the sequence number into a content identifier.

Context could travel beside the object

NORM did offer a place for the application to attach meaning. NORM_INFO carried optional, application-defined context associated with a NormObject. MIME type was one suggested use. A receiver could inspect that small record and decide whether to join reliable reception of the bulk object. When INFO existed, data messages advertised its availability, and a receiver that missed it could request a repair.

But INFO was not a naming authority. Its semantics were not prescribed, it was optional, and its payload had to fit inside a single sender segment. The atomic design made a compact context record quick to recover; it did not guarantee that the record contained a global identifier, a digest, a version, a signature or even a filename. An application could put durable identification there, or embed it in the content, but it had to choose the scheme and retain the association.

This is the point at which reliability and memory separate. NORM could ensure that the same INFO transport ID accompanied the corresponding object during delivery. Once the repair window closed, however, an archive that kept only the transport number had kept the least durable part of the record. If the number later returned, the protocol had done nothing wrong. The application had forgotten the scope.

A complete object could still be the wrong object

Imagine a receiver cache indexed only by the protocol's sender identifier and the 16-bit object number. It disconnects, loses session-generation state and returns after the counter has wrapped. A fully repaired object arrives under a familiar key. Every segment is valid within the current transport context, yet the cache attaches yesterday's title, authorization or expiry rule to today's bytes. Reliability has made the misassociation complete.

That scenario is an inference from the boundary, not a documented incident. It shows why evidence must remain layered. Transport evidence can establish which sender instance and in-flight object a segment served. A content digest can compare bytes if an application supplies one. A durable application identifier can connect the transfer to a versioned record. Authorization and publication state require still other evidence. No single layer inherits the authority of the next merely because delivery succeeded.

RFC 3940 belongs in Internet history because it resisted an attractive shortcut. It created just enough identity for distributed repair, then stopped. The protocol coordinated movement; the application owned memory. The reusable number was not a defect waiting to be hidden. It was a warning written into the design: if meaning must outlive transport, meaning needs its own name.