Resumen

  • La RFC 913 propuso tres tipos para su Simple File Transfer Protocol. Una página TOPS-20 de 512 palabras de 36 bits produce, en sus ejemplos, 2560 bytes en ASCII, 2048 en Binary y 2304 en Continuous.
  • Binary toma cuatro bytes de cada palabra y omite los cuatro bits finales; Continuous empaqueta los bits sin detenerse en el borde de la palabra. Una transferencia correcta puede cumplir el protocolo y, aun así, representar el archivo de otra manera.

Primero, las cajas. El ordenador guardaba una página en piezas de 36 bits; el transporte solo aceptaba cajas de ocho. Había tres formas de llenarlas. Podían meterse letras de siete bits, extraerse cuatro cajas completas de cada pieza o pasar todos los bits a una cinta sin cortes. Las tres operaciones cumplían las instrucciones y daban archivos de tamaños distintos. Ahora sí: la pantalla anuncia que el archivo ha llegado. ¿Cuál de esas tres cargas recibió el otro ordenador? En septiembre de 1984, Mark Lottor puso la elección en la RFC 913. Su Simple File Transfer Protocol, un SFTP por el puerto TCP 115, pertenecía a otra época que la posterior herramienta de archivos asociada a SSH, aunque compartieran siglas. Buscaba algo más útil que TFTP y más fácil de implementar que FTP, con una sola conexión TCP. El comando TYPE elegía cómo llenar las cajas.

La página de ejemplo viene de TOPS-20. Tiene 512 palabras de 36 bits: 18 432 bits almacenados. En modo ASCII, cada palabra aporta cinco caracteres de siete bits. Eso ocupa 35 bits; el último queda fuera de la representación de texto. Los caracteres salen en unidades de ocho bits con el bit superior a cero, y los finales de línea locales pasan a CRLF según NETASCII. Las cuentas dan 2560 bytes para la página. Es una forma de transportar texto inteligible entre máquinas distintas. Nadie debería confundirla con una copia literal de todos los bits del disco.

Binary parece prometer una copia integral. En realidad aplica la segunda forma de llenar cajas: de cada pieza de 36 bits toma cuatro grupos de ocho. El resultado son 32 bits por palabra; los cuatro restantes quedan en el origen. Para las 512 palabras de la página, salen 2048 bytes. Esos cuatro bits podrían ser relleno o contener información útil: eso lo decide la forma en que se guardó cada archivo. La regla del transporte no lo averigua. En esta propuesta, «binario» nombra el tamaño de las cajas, no una garantía de que todo lo almacenado quepa en ellas.

Continuous no corta el flujo al terminar cada palabra. Tras cuatro bytes del primer grupo, sus últimos cuatro bits se juntan con los cuatro primeros del grupo siguiente. Así se trasladan los 18 432 bits de la página, equivalentes a 2304 bytes de ocho bits. Cuando las palabras de una máquina ya tienen un ancho múltiplo de ocho, el documento espera que Binary y Continuous coincidan. TOPS-20 muestra por qué ambos nombres se necesitaban: uno conserva octetos extraídos de cada palabra; el otro conserva la secuencia íntegra de bits. Al llegar, el receptor todavía tiene que saber cómo reconstruir un archivo útil.

El protocolo hacía fácil pasar por alto el asunto. Los comandos constaban de cuatro letras ASCII y un byte nulo; Binary era el valor predeterminado. El servidor podía exigir usuario, cuenta y contraseña. También permitía listar, renombrar y borrar, además de leer y guardar archivos. Una sesión podía responder con éxito porque había enviado exactamente los bytes elegidos, mientras el contenido almacenado originalmente seguía una convención que el modo elegido no conservaba. El estado «terminado» habla de la operación; TYPE habla de la materia transportada.

La ficha del RFC Editor clasifica hoy la propuesta como histórica. Los tamaños de sus páginas son ejemplos calculados, no expedientes de pérdida real. La aritmética basta para enseñar la trampa: un mismo origen puede convertirse en 2560, 2048 o 2304 bytes sin que cambie la fiabilidad de TCP. Quien tomó la decisión fue la representación. En el trayecto entre máquinas, cuatro bits podían quedarse en el andén con un billete perfectamente válido para los demás.