Summary

  • FTP's COMPRESSED mode encoded ordinary data, arbitrary repeated bytes and distinguished filler in three different forms. Only the filler form omitted the repeated value.
  • The receiver reconstructed that value from TYPE: a space for ASCII or EBCDIC, and a zero byte for Image or Local byte representation.
  • A MODE C capture without its parameter timeline can preserve every transmitted octet yet remain insufficient to reproduce the file.

A valid count with no value after it

The shortest run in FTP's old compression grammar is easy to misread. Its leading two bits are 11; the remaining six bits give a count. That single byte represents a string of fillers. There is no sample byte after it.

This was not the universal form for repeated data. RFC 765 and RFC 959 separately defined a replicated-byte form. Its leading class was 10, its lower six bits carried the count, and the next byte supplied the value to repeat. An amber byte repeated twenty times therefore needed both a descriptor and an amber sample. Filler received a more privileged treatment: count alone was enough.

The difference gives a parser a useful invariant. After a replication descriptor, absence of the sample is truncation. After a filler descriptor, expecting a sample is the error. Correctness comes from recognizing the class before deciding what must follow.

TYPE supplied what MODE left out

The missing value lived in representation state. Under ASCII, filler meant a space with ASCII code 32. Under EBCDIC, it meant that representation's space, code 64. Under Image or Local byte representation, it meant a zero byte.

The same filler descriptor could therefore produce different output without changing a single transmitted bit. A receiver decoding it under TYPE A could produce blanks where the same bytes under TYPE I produced zeros. The mode did not contain enough information to settle the result by itself.

RFC 959 states the dependency unusually clearly. Transmission mode and representation are basically independent, it says, but Compressed mode is an exception because the nature of the filler byte depends on representation type. That sentence prevents a convenient but false abstraction: treating MODE C as a self-contained stream codec.

Three forms answered three different questions

Regular data used a descriptor whose high bit was zero and whose other seven bits held a positive count up to 127. The next n bytes were copied literally. That form said: here are several values, none inferred.

Replicated data used the 10 class, a six-bit count and one explicit byte. It said: repeat this supplied value. The one-byte filler form used the 11 class and only a six-bit count. It said: repeat the value that this representation has already designated as empty material.

Compression thus rested on a semantic distinction, not merely statistical repetition. A run of arbitrary zeros under ASCII was not automatically an ASCII filler run; ASCII's privileged filler was space. Conversely, Image mode could reconstruct zeros without receiving an explicit zero sample. Which form was valid depended on meaning established outside the run.

Control information occupied a fourth path. A zero escape byte followed by a descriptor carried Block-mode codes such as record or file boundaries and applied them to the succeeding string. The grammar had to distinguish literal spans, explicit replication, implicit filler and control before it could hand bytes to storage.

Printer files made the bargain attractive

RFC 959 described COMPRESSED mode as exchanging a little CPU work for bandwidth on very large transfers. It singled out printer files, including output produced by remote-job-entry hosts, as an especially effective case. Long fields of spaces were not an abstract possibility in that environment; they were a regular cost of fixed layouts and formatted output.

Giving space a one-byte run form made historical sense. So did giving zero that role for Image and Local byte data. The optimization was compact because representation had already narrowed what “filler” could mean.

That economy also created a dependency. A capture appliance that retained only the data connection discarded part of the decoder. A gateway that normalized TYPE in its log but left the compressed bytes unchanged could make later reconstruction disagree with the original receiver. A forensic tool that labels every count-without-value “truncated” would reject legal traffic.

Negotiation divided the stream into epochs

TYPE, STRU and MODE were transfer parameters carried over the control connection. MODE C selected the compressed grammar; TYPE selected representation. Their effects met inside the filler form.

A reliable trace therefore binds each data span to the parameter state active when the transfer began. It records accepted commands and replies, not merely the commands a client attempted. It resets or closes decoder state at the same boundaries as the protocol implementation. If parameters change before another transfer, the same descriptor needs a new interpretation context.

This is broader than FTP archaeology. Any encoding that draws a value from negotiated state makes that state part of the evidence. Payload hashes prove which encoded bytes were retained; they do not prove which decoded object those bytes denoted.

A base command did not prove every argument

RFC 959 assigned S, B and C to Stream, Block and Compressed modes and made Stream the default. RFC 1123 later defined the minimum implementation around Stream mode. It also observed that FTP contained real but not commonly implemented features. The historical specification should not be converted into a claim that MODE C was universal, or that current software accepts it.

RFC 5797 and the IANA FTP Commands and Extensions registry preserve MODE as a base parameter-setting command referenced to RFC 959. That is vocabulary evidence. It is not a live conformance test for the C argument, the run parser or round-trip preservation.

Preserve both sides of the reconstruction

Useful evidence keeps the raw data stream, its hash and length; the accepted TYPE/STRU/MODE timeline; every decoded span and control event; the final parser state; and a hash of canonical reconstructed output. It distinguishes a filler run from an explicit replication even if both happen to produce identical bytes.

Canaries should reuse one filler descriptor under ASCII, EBCDIC, Image and Local byte representation. They should place an arbitrary repeated value beside it, split descriptors and samples across receive calls, exercise the maximum regular span, and close after a replication descriptor without its sample. The expected outcomes differ by grammar, not by packet boundary.

The sender did not send the filler byte because the session had already named it. FTP saved bandwidth by borrowing meaning from negotiated context. The saving was real; so was the obligation to preserve that context whenever the bytes were expected to remain evidence.

Sources