Summary

  • Mature FTP fixed the transfer byte at eight bits, but TYPE L declared a separate mandatory logical-byte size whose boundaries could cross those octets.
  • A receiving system could arrange the logical units for its own word size only through an invertible, publicized transformation. Identity was promised when storage and retrieval used the same parameters.
  • Image preserved contiguous bits; Local additionally declared their units. Command success did not prove application meaning, physical allocation, durable storage or universal support for the requested width.

The successful reply settled less than it seemed

A server that accepts TYPE L 36 has agreed to treat the coming file as a sequence of 36-bit logical units. It has not agreed to use 36-bit memory, to understand the values as numbers, or to reserve a particular amount of disk. The command selects a representation state. Other results still belong to other mechanisms.

The arithmetic makes that modest contract visible. Two logical units contain 72 bits. FTP's mature data connection carries eight-bit transfer bytes, so the pair occupies nine of them. The first four octets contain 32 bits of the first unit. The first half of the fifth octet completes it; the second half already begins the next.

There is no network delimiter at that midpoint. TCP may divide the stream before or after it without changing the file. A gateway that treats every octet or segment boundary as a logical boundary can preserve every transported bit and still corrupt the representation.

This is the historical interest of TYPE L. The protocol did not answer heterogeneity by insisting that every participant adopt the carrier's unit internally. It narrowed the common grammar and kept interpretation at the edges, where the necessary context lived.

The first catalogue tried to name the machines' differences

RFC 114, published in April 1971, exposed a much larger type surface than the later choice between text and binary. Its tentative descriptors included several ASCII forms, EBCDIC, SIXBIT, decimal, octal and hexadecimal encodings, differently signed integers, and machine-specific floating-point forms for the IBM 360 and PDP-10. Some integer descriptors carried an explicit size from one to 255 bits.

The information was interpretive. A host accepting a type could convert the received value into an internal form suited to that machine. A 36-bit-word computer might pack five seven-bit ASCII characters into a word, four eight- or nine-bit characters another way, and six SIXBIT characters another.

That 1971 table is not the TYPE command grammar of RFC 959. Treating it as such would collapse a historical transition. It does show the original commissioning problem: ARPANET hosts did not agree on character code, numeric representation, storage word or the unit conventionally called a byte.

A reliable bit path therefore left work unfinished. The receiver could possess the exact sequence yet not know which groups were meant to be manipulated together. The early response was to place many machine distinctions in the shared catalogue.

For a time, even the connection byte could vary

RFC 354, dated July 1972, separated representation type, structure and transfer mode, but its data connection could still use a selected byte size. ASCII and print representations used eight bits. Image and Local Byte could use the size chosen for the connection.

A server did not have to accept every possible size. It could implement the sizes for which its transfer machinery was efficient, while eight-bit support was recommended. Expressibility was not a certificate of deployment even in the protocol's early form.

The Local Byte transformation depended on the transfer size and the particular host. Its method had to be well publicized and invertible. If a file was stored using a representation and byte size, retrieving it with the same combination had to reproduce the identical file. The user was responsible for remembering those parameters.

That arrangement gave unlike machines room to preserve native forms, but it enlarged the interoperability matrix. A host might understand 36-bit values in memory and still decline a 36-bit data-connection byte. Meaning and carriage width both appeared on the negotiated surface.

Eight bits became the carrier, not the constitution

RFC 765 in 1980 simplified the model by fixing the transfer byte at eight bits. RFC 959 retained that decision and stated the distinction explicitly. FTP had a logical byte size for interpreting file structure and a transfer byte size for moving data. Neither was necessarily the unit in which a system stored the result.

TYPE L requires a decimal second parameter. It has no default. Without the number, the receiver knows the width of the arriving containers but not the width of the units to reconstruct from them.

When the two widths differ, logical bytes are packed contiguously, disregarding transfer-byte boundaries. The change did not ban nine-, 18- or 36-bit objects. It moved their packing to the endpoints and removed their geometry from the data connection itself.

This was a controlled reduction of common authority. Every implementation could rely on eight-bit carriage. No implementation could infer from that common carrier that the file, CPU and storage device all used eight-bit native objects.

The fifth octet belonged to both words

The specifications' TYPE L 36 example is unusually useful because it defeats a visual habit. Four full octets are not a 36-bit word. Five full octets are too many. The boundary sits inside the fifth, leaving that same transport unit partly owned by each neighboring logical unit.

A conforming packer therefore treats the stream as bits with a separately known stride. It does not restart the stride at an octet boundary, an IP packet, a TCP segment or a storage block. Those are containers or operational divisions, not declarations of file meaning.

The width still does not define a complete number format. Thirty-six bits might hold a floating-point value, an instruction, an image element or something else. L 36 does not specify sign, exponent, internal ordering or application semantics. It preserves a boundary on which another authoritative description can operate.

That limit matters in both directions. Accepting Local type does not prove that the receiver's application understands the content. An application that understands a 36-bit format does not prove that the FTP service will accept L 36. Representation support and application use remain separate observations.

Padding could discharge only the final remainder

If the total logical content does not fill the last transfer octet, RFC 765 and RFC 959 permit necessary padding at the end. They do not permit a receiver or intermediary to round every logical unit up to the next eight-bit boundary for convenience.

Position is what makes padding recoverable. Zeros inserted between units can be indistinguishable from original data. At the end of a file or record, the endpoint can combine the termination point with the declared logical width and identify the remainder.

A row of zeros in a packet capture is consequently weak evidence. It might be content. To call it padding, an investigator needs the active type and width, the relevant file or record structure, and a trustworthy end boundary. The transport bytes alone do not carry that verdict.

An intermediary that inserts four zero bits after every 36-bit unit has not merely optimized alignment. It has invented another encoding before the authorized interpreter consumed the original. Removing those zeros later would require a new rule outside the FTP declaration.

The receiver could choose a larger drawer

RFC 959 imagines 36-bit floating-point units arriving at a host with 32-bit words. The host could store each logical unit in a 64-bit double word so it remained easy to manipulate. The unused 28 bits belong to the local drawer, not to the file transported by FTP.

The freedom to choose that drawer is constrained by invertibility. The transformation must allow the server to return an identical file when the same parameters are used, and implementers should publicize how the transformation works.

The phrase "same parameters" is a condition, not reassurance. A file stored as TYPE L 36 is not generally promised to emerge identically when requested as TYPE L 8. An archive that retains only the padded 64-bit storage form while discarding the original width and conversion rule may later be unable to distinguish content from local space.

The durable object is thus larger than a blob. It includes the bit sequence, representation parameters and the provenance of the local mapping. A checksum over the drawer can prove that the drawer survived; it cannot reconstruct the lost instruction that said which 36 bits mattered.

Image and Local could coincide without saying the same thing

Image type treats the file as contiguous bits, packed into eight-bit transfer bytes. The receiving site must preserve that continuity. If its storage system needs alignment at a byte, word or block boundary, zero padding may appear only at the end of the file or record, and it must be identifiable for removal on retrieval.

Local also moves a contiguous bit stream, but it declares a logical unit. That declaration authorizes the receiver to arrange each unit into a host-appropriate, reversible form. The two types can produce the same bits in particular machine arrangements without carrying the same evidence.

RFC 1123 explains that TYPE L 8 is equivalent to Image on an eight-bit-byte machine. Between two m-bit-word machines, TYPE L m should have the same effect as Image. The equivalence is conditional on a known organization. It does not allow a receiver to invent an m-bit boundary when the sender selected Image alone.

This is a useful distinction between outcome and authority. Two procedures may happen to yield identical output. Only one may contain the parameter that justified a host-specific transformation.

The mandatory floor was deliberately narrow

RFC 1123 requires FTP programs to support TYPE I and TYPE L 8. A machine whose memory is organized into m-bit words, where m is not a multiple of eight, may also support TYPE L m.

That rule establishes an eight-bit interoperability floor and leaves room for native-word extensions. It does not require every server to accept every decimal integer after L. Defined syntax, implemented capability and session acceptance are three different facts.

A rejection of TYPE L 36 proves that the requested representation was not accepted in that session. It does not prove a broken path, insufficient storage or damaged content. The client can choose Image, convert into an externally shared format before transfer, or stop.

Silently substituting L 8 would make the immediate command easier to satisfy while deleting the statement the sender meant to make. Compatibility achieved by changing the requested unit is not evidence that the original representation survived.

Type did not swallow structure, mode or restart state

FTP kept representation type, file structure and transfer mode as separate parameters. Knowing that a logical unit is 36 bits does not define record boundaries, page indexes, Stream, Block or Compressed behavior. It also does not say that a completion reply means modern durable storage.

The published history of FTP restart markers examined why a marker was not necessarily a byte number: a receiver performing a transformation might need to encode enough local state to resume it. TYPE L supplies an input unit to that transformation. The marker supplies a restart point. Preserving one does not recreate the other.

This distinction is also why the one incidental production search match is not a duplicate commission. The restart article mentions heterogeneous word sizes to explain receiver-owned checkpoints. This article studies how logical units themselves cross the fixed carrier and constrain reversible storage.

ALLO counted a unit defined elsewhere

FTP's ALLO command could express expected storage in logical bytes. The active representation supplied the unit. The allocation command did not create a 36-bit boundary, and its positive reply did not necessarily prove that physical space had been reserved.

The recently published ALLO article asks whether a preliminary quantity changed server resources. TYPE L asks what that quantity counts and how its boundary survives the data connection. Sufficient space cannot repair a mispacked logical stream; correct packing cannot prove a reservation.

The two mechanisms also assign authority differently. TYPE lets the sender declare representation subject to server acceptance. ALLO lets the sender estimate a need while the server decides whether advance allocation matters. Treating both as one generic binary-transfer success would erase the control surface of each.

A registry entry is not a map of host memory

The IANA FTP Commands and Extensions registry records TYPE as the Representation Type command and points to its specification. It establishes a name and documentary reference.

It does not list every Local size accepted by a server, the mapping used on its filesystem or the command's current prevalence. Those claims require implementation evidence, the particular session reply, a same-parameter round trip and, for usefulness, an application that understands the restored units.

Registration, acceptance, correct transformation and application interpretation form an evidence ladder. None can be inferred automatically from the rung below it.

The wire's modesty made provenance an endpoint duty

FTP moved from an expansive catalogue of machine representations, through variable connection byte sizes, to fixed eight-bit carriage plus a separate logical width. The common layer became simpler without declaring the attached machines homogeneous.

That modesty works only when endpoints retain what the wire intentionally declines to interpret. Type, logical size, structure, mode and conversion provenance cannot safely collapse into a label such as "binary." Nine pristine octets might still be an incomplete record of two 36-bit words.

The historical lesson is not that modern systems should revive every old FTP mode. It is that simplifying a shared layer does not abolish the context excluded from that layer. It relocates the duty to preserve it.

Sources and evidence boundary

The evidence comprises RFC 114, RFC 354, RFC 765, RFC 959, RFC 1123 and the IANA registry. These sources establish designs and requirements. They do not establish current deployment, a product's accepted widths, a disk layout, the application meaning of a 36-bit value or a guarantee of durable storage.