Summary

  • RFC 3485 let SigComp reference common SIP/SDP material in the first message by requiring every implementation to possess one immutable, byte-exact static state.
  • Its informative word lists explained where the material came from, but interoperability depended on the normative binary value, identifier, length and exact offset/length slices.

Compression usually learns from a past. The first SIP message had none. No earlier headers or session description had crossed the link, so a compressor could not yet point into message-derived state at the receiver. RFC 3485 created a shared past in advance: both endpoints would begin with the same static dictionary already installed.

That convenience imposed an unusually hard constitutional rule. The SIP/SDP dictionary was unique, mandatory for SigComp implementations used with those protocols, and not intended to evolve as SIP or SDP evolved. It was defined once and would remain unchanged. The rigidity avoided a question that would otherwise return at the worst possible time: before sending the first compressed message, which dictionary version does the remote endpoint have?

The answer was not a negotiated label such as “edition three.” It was a particular SigComp state. Section 3 fixed its identifier, its length, its minimum access length and every byte of its value. A compressor could use a six-byte partial state identifier in the shown STATE-ACCESS operation because SigComp state lookup provided the matching rules. The full object remained identified by a twenty-byte value and a state length of 0x12E4.

This makes the document's editorial structure important. Appendices A and B list the SIP and SDP input strings, priorities, offsets, lengths and references that motivated inclusion. Those tables are readable and useful, but informative. The normative dictionary is the binary representation in Section 3. Two implementers who agree on the names in an appendix but arrange a byte differently do not possess the same state.

The binary object had two joined regions. The string subset stored material so that each contributed string existed as a substring. The table subset stored a one-byte length and a two-byte offset for each entry, with 1024 added to the offset so it could directly address a dictionary loaded at UDVM address 1024. Algorithms could use string material directly; LZ78-related methods could also begin with tokens from the table.

The layout reused space aggressively. Several strings could occupy overlapping regions where common substrings allowed it. The familiar Proxy- prefix, for example, could be shared while separate remaining pieces represented authentication and authorization headers. A SIP response code could have one entry for the normative code and another for the code plus its merely suggested reason phrase, even though both entries pointed into shared bytes.

Formatting therefore belonged to the evidence. Dictionary strings were case-sensitive. Header material often included the preceding CRLF, the colon and expected whitespace. A SIP message could conform to its grammar while using alternate legal spacing and gain less from the dictionary. “The token exists in the dictionary” was not enough; the bytes in the message had to match the referenced byte sequence.

Priorities added a second layer. Values one through five expressed the authors' estimate of how often material would occur, with lower numbers meaning higher expected frequency. Common material was arranged toward positions that some compression algorithms could reference efficiently. These priorities were design judgments, not measurements of a later network's traffic.

They also enabled bounded loading. RFC 3485 supplied exact string and table offsets and lengths for priority one alone, priorities one through two, and progressively larger slices through all five. A memory-constrained UDVM could access a smaller, high-value region without treating the dictionary as a different evolving version. The full immutable state remained the reference object; the operands selected a byte range within it.

That distinction is easy to lose in an audit. A log that records only “static dictionary used” omits the partial identifier, selected offset, length and whether the program accessed the string region or the table. It also omits whether the incoming bytes actually decoded. Dictionary availability is a prerequisite and a naming convention, not a decompression receipt.

Nor did successful decompression prove that the decoded payload was valid SIP or SDP. RFC 3320 placed application authorization after decompression for persistent state creation. RFC 3321 later explored acknowledgement and lifetime of dynamic state. RFC 3322's performance figures came from a simplified model. RFC 3485 owned none of those outcomes. Its subject was the pre-existing static state that made immediate references possible.

Later documents clarify the lineage without rewriting the object. RFC 3486 described how SIP signaled SigComp use. RFC 4464 explained static dictionaries to implementers, and RFC 4465 included a torture test for accessing the RFC 3485 state. RFC 4896 restated the layout while correcting broader SigComp issues. RFC 5049 required SIP SigComp implementations to support the dictionary. RFC 5112 defined a different presence-specific static dictionary rather than silently revising this one.

The security section was deliberately brief: RFC 3320's considerations applied, and RFC 3485 claimed no new known risk. That statement did not turn compression into authentication. Knowing the correct dictionary identifier did not prove sender identity, authorization, message integrity, delivery or a successful session. Those remain separate receipts.

The document also did not report a named deployment or achieved compression ratio. Its introduction expected a better first-message compression rate and shorter setup than starting without stored state, but a standards-track mechanism is not a field measurement. Link speed, message formatting, algorithm choice, slice selection and actual content would all affect a result.

Heng Lu's reality-layer method suggests the right reconstruction order. First hash the full normative state and confirm its fixed metadata. Then preserve the partial identifier and every STATE-ACCESS operand. Resolve the addressed bytes and priority slice. Compare them with the compressed message and decompressor trace. Only afterward join protocol parsing, authentication, delivery and session evidence.

RFC 3485's historical bargain was austere and powerful. It made the first message smaller by manufacturing common memory before either endpoint had spoken. But shared memory worked only because it was not an editable book. It was a sealed byte array, permanent enough that the first message could borrow from it without asking which edition was on the other side.

Sources