Summary

  • RFC 3362 registered image/t38 as an SDP media descriptor for a real-time T.38 fax stream; the ITU-T recommendation, not the registry entry, defined the encoding and procedures.
  • The token removed a naming ambiguity. It did not prove offer/answer acceptance, compatible transport, encryption, gateway behavior, complete pages or human receipt.

Imagine the first machine in a call parsing a session description. It reaches a media line and recognizes the subtype. The parser no longer has to guess whether the offered stream is voice, video or real-time fax. That is a genuine gain. Yet the sheet at the other end is still blank.

In 2002, RFC 3362 created the small joint that let two standards worlds meet. ITU-T Recommendation T.38 described how Group 3 facsimile terminals and gateways could communicate in real time over IP networks. SIP and SDP supplied Internet session machinery. The RFC registered image/t38 so an SDP description could name the stream both sides were discussing.

The distinction between naming and defining was explicit. RFC 3362 did not reproduce the T.38 encoding. It pointed to the ITU-T recommendation. It noted that T.38 could use TCP or UDP according to the service environment. It related the call-establishment procedures in T.38 Annex D to the older SIP and SDP specifications and said they could also be applied with the revised SIP specification, RFC 3261.

That composition was an Internet strength. One institution did not need to own every layer. A common label could join an externally defined media system to IETF signaling. IANA could preserve the label. Implementers could decide whether to run the specifications. The seam was narrow enough to audit.

The registration itself was unusually spare. Required parameters: none. Optional parameters: none. Encoding consideration: binary. Intended usage: common. The absence of parameters was not an omission that the registry silently repaired. It set the evidentiary ceiling of the token. image/t38 identified a kind of media; it did not carry a complete compatibility profile.

RFC 3362 made one context boundary equally clear. The media type was intended to identify a T.38 stream in SDP. It was not intended for email. The interoperability section explained why: email use was undefined and therefore was not guaranteed to interoperate with a T.38 stream. A top-level name beginning with image did not turn the stream into an ordinary attachment.

That sentence is more important than it looks. Media types are often treated as universal descriptions of objects. Here, the meaning depended on where the token appeared and which procedures surrounded it. Moving the same string into a different protocol context could preserve syntax while losing operational meaning.

The security statement was bounded too. The content denoted a facsimile bitstream that might or might not be encrypted. The label did not claim confidentiality. It did not tell an observer whether signaling was protected, whether media protection was in use or whether a gateway exposed cleartext on another segment. Security remained a property of the implemented path and its configuration.

SDP itself imposed another limit. From RFC 2327 through RFC 4566 and the current RFC 8866, SDP is a format for describing multimedia sessions; it does not incorporate a transport protocol. A description can state addresses, ports, media and formats. It does not carry the packets merely by existing.

Nor does one description complete negotiation. RFC 3264's offer/answer model gives one participant's desired view in an offer and the other participant's desired view in an answer. Both are needed for the complete view. An answer can reject a media stream by setting its port to zero. Thus an offer containing a valid image/t38 token proves that one endpoint proposed the type. It does not prove that the peer accepted it.

Even acceptance is not the end. Both endpoints must implement compatible T.38 behavior. Their chosen transport must work through the network. Loss, delay and reordering must remain within the service's tolerance. Gateways must translate correctly between packet behavior and the timing expectations of fax terminals. A session may come up while a page is clipped, repeated or never confirmed.

The evidence ladder therefore has many rungs. The IANA row proves that image/t38 is registered and points to RFC 3362. Source code or a capability inventory may prove that an implementation recognizes it. An SDP capture may prove that an endpoint offered it. The answer may prove acceptance. Packet traces may prove transport. Gateway logs may prove conversion attempts. Page counts and terminal confirmations may prove completion. The recipient's workflow may provide the final receipt.

No rung can silently substitute for the one after it. A registry is not a deployment census. A recognized token is not an accepted stream. An accepted stream is not a delivered page. A delivered page is not necessarily a legible or acted-on document.

The history of media-type registration reinforces that narrow reading. RFC 2048 supplied the registration procedure in force around the time of RFC 3362. RFC 4288 and then RFC 6838 revised the general framework. The process exists to make type names reviewable, stable and discoverable. It reduces collisions and ambiguity. Registration does not run an endpoint or make an operator adopt a format.

BCP 14 language has a similar boundary. RFC 2119 and RFC 8174 help specifications distinguish requirements from recommendations when the capitalized words are used as defined. They discipline what compliant implementations are supposed to do. They cannot certify that a particular gateway did it at a particular moment.

The live IANA media-type record remains valuable. It preserves the token and its reference decades after publication. That continuity gives implementers a shared lookup point. But its persistence is evidence about registry custody, not about how many fax gateways operate today, what transports they select, whether their streams are encrypted or how often pages arrive intact.

Two Lu Heng essays provide the analytical lens used here. “Minimum Initial Specification” argues that a common layer should contain only the deterministic substance needed for interoperability and leave later choices with participants running code. RFC 3362 illustrates the productive version of that restraint: a small token joined systems without pretending to govern every operational choice. “On Reality Layers” warns against treating a record, declaration or symbolic status as the running system. Applied here, it keeps the registry row, the SDP offer, the accepted stream and the received page in separate columns.

That separation does not diminish the RFC. It explains why the document endured. image/t38 was useful because it made one statement precisely: this media description refers to a T.38 real-time fax stream. The moment an operator wants to say more—compatible, accepted, secure, transported, converted, completed—another receipt is required.

Sources