Resumen

  • FTP terminó fijando en ocho bits la unidad de transporte, pero TYPE L conservó una medida lógica independiente, obligatoria y capaz de cruzar los límites de esos octetos.
  • El sistema receptor podía elegir una representación local conveniente sólo si la transformación era reversible y podía devolver el archivo idéntico con los mismos parámetros.
  • Image preservaba una secuencia continua de bits; Local declaraba además sus unidades. Aceptar la orden no demostraba interpretación de la aplicación, reserva de disco ni soporte general del tamaño elegido.

Una frontera en medio del recipiente

La aritmética de RFC 765 y RFC 959 deja poco espacio para una lectura cómoda. Dos palabras de 36 bits suman 72. La conexión de datos madura de FTP transmite octetos de ocho bits, así que necesita nueve. El primer objeto acaba después de cuatro bits del quinto octeto; el segundo empieza en los cuatro que quedan.

Nada en TCP entrega al receptor una señal especial en ese punto. Un segmento puede terminar antes o después, y la división en paquetes no altera la unidad declarada. Es L 36, conservado como estado de representación, lo que permite volver a colocar la frontera.

Por eso una pasarela puede copiar los nueve octetos sin un solo error y aun así destruir el archivo: basta con que trate cada octeto como una unidad independiente, inserte relleno entre palabras o pierda el tamaño lógico antes de almacenar. Integridad de transporte e integridad de representación no son el mismo resultado.

Antes de Local, el catálogo intentó nombrarlo casi todo

El FTP de RFC 114, publicado en 1971, mostraba de frente la diversidad de sus máquinas. Su tabla incluía variantes de ASCII, EBCDIC, SIXBIT, números decimales, octales y hexadecimales, enteros con distintas convenciones de signo y formatos de coma flotante ligados a IBM 360 o PDP-10. Ciertos enteros llevaban un tamaño explícito de uno a 255 bits.

La información era interpretativa. Si un host aceptaba un tipo, podía convertirlo a una disposición interna apropiada. Una máquina con palabra de 36 bits podía empaquetar cinco caracteres ASCII de siete bits, cuatro de ocho o nueve, o seis caracteres SIXBIT de maneras distintas.

Esa tabla no es la sintaxis posterior de RFC 959. Su interés histórico está en la pregunta que planteaba: ¿cuánta diferencia entre máquinas debía describir el protocolo común? Una lista extensa ayudaba a algunos pares, pero convertía cada nuevo formato local en candidato a formar parte de la interfaz compartida.

En 1972 también variaba el byte del enlace

RFC 354 separó el tipo de representación, la estructura y el modo de transmisión. Para ASCII y ciertos formatos de impresión, el byte de la conexión era de ocho bits. Image y Local Byte podían usar otro tamaño seleccionado mediante los parámetros de transferencia.

Un servidor no estaba obligado a aceptar todos los tamaños posibles. Debía informar del rechazo y podía implementar sólo aquellos que tratase con eficiencia, aunque se recomendaba al menos el de ocho bits. La capacidad del vocabulario no equivalía, ya entonces, a una obligación universal de ejecución.

La transformación Local dependía del tamaño de transferencia y del host concreto. Tenía que ser invertible y el sitio debía publicar su método. El usuario era responsable de recordar el tipo y el tamaño con que había depositado el archivo. Cerrar la conexión no convertía esos datos de procedencia en prescindibles.

El cable se simplificó sin redefinir los archivos

RFC 765 trasladó parte de esa complejidad a los extremos: el byte de transferencia pasó a ser siempre de ocho bits. RFC 959 mantuvo la decisión y distinguió explícitamente tres superficies que suelen colapsarse en la palabra byte.

La primera es el byte lógico con que se interpreta el archivo. La segunda es el octeto de ocho bits usado en la conexión de datos. La tercera es la unidad física o conveniente que adopta el sistema receptor para guardar y procesar lo recibido. No existe una regla que las haga idénticas.

TYPE L requiere un segundo parámetro decimal y no tiene valor predeterminado. Si el cliente pide Local sin medida, el receptor no sabe dónde cortar la secuencia. La ausencia del número no puede rellenarse con la comodidad local del servidor sin cambiar la solicitud.

Los bytes lógicos se empaquetan uno tras otro, ignorando las fronteras de los octetos de transporte. La elección de ocho bits normalizó el vehículo y redujo la matriz de conexiones posibles. No prohibió palabras nativas de nueve, 18 o 36 bits.

El quinto octeto demuestra qué capa posee cada decisión

En TYPE L 36, el emisor posee la declaración: afirma que cada unidad significativa para esta representación ocupa 36 bits. FTP posee la gramática del trayecto: emite y recibe octetos. El destino posee la distribución local: puede usar palabras distintas para guardar cada unidad, siempre que la decisión sea reversible.

Ninguna de esas autoridades contiene a las demás. El emisor no decide el ancho físico del disco remoto. El receptor no puede reemplazar 36 por 32 sólo porque su procesador prefiera 32. El cable no puede elevar ocho a definición universal de todo byte del archivo.

La cifra 36 tampoco da semántica completa. Puede delimitar números, instrucciones u otro dato estructurado, pero no especifica por sí sola signo, exponente, orden interno ni reglas de la aplicación. Preservar la frontera es necesario para esas interpretaciones; no basta para elegir una.

El relleno sólo puede saldar el último resto

Si el total de bits lógicos no completa el último octeto de transmisión, FTP permite el relleno necesario al final. La regla no autoriza a redondear cada unidad lógica a ocho bits ni a insertar ceros después de cada palabra para facilitar un buffer.

El lugar protege la reversibilidad. Un cero insertado entre unidades puede confundirse con contenido original. Un resto al final del archivo o del registro puede identificarse usando la terminación y el tamaño declarado. Para quitarlo con seguridad hacen falta ambos datos.

La captura de una cola de ceros no es prueba suficiente de relleno. También puede ser contenido. Un análisis necesita el TYPE activo, la medida lógica, la estructura de archivo o registro y el final observado. Sin ellos sólo conoce octetos de transporte.

Guardar 36 dentro de 64 no cambia el archivo

RFC 959 imagina un receptor organizado en palabras de 32 bits. Para manejar unidades lógicas de 36, puede reservar un doble word de 64 bits por unidad. Los 28 bits libres pertenecen a la representación local, no a la secuencia que llegó por FTP.

La especificación exige que la transformación sea invertible y recomienda que el implementador la haga pública. Si el archivo se almacena y recupera con los mismos parámetros, debe salir idéntico. Ése es el contrato observable que limita la libertad del receptor.

La condición “con los mismos parámetros” no es decorativa. No hay promesa general de que un depósito TYPE L 36 recuperado después como TYPE L 8 conserve el mismo objeto. Una migración que guarda el blob pero descarta tipo, ancho lógico y versión de conversión puede perder la posibilidad de verificar una futura recuperación.

Image conserva continuidad; Local añade unidades

El tipo Image envía datos como bits contiguos empaquetados en octetos. El receptor debe conservar esa continuidad. Si su almacenamiento necesita completar una frontera de byte, palabra o bloque, el relleno de ceros sólo puede aparecer al final y debe poder identificarse y retirarse.

Local también usa una secuencia continua sobre el cable, pero declara una unidad para la transformación local. En algunos equipos ambos tipos producen el mismo resultado. RFC 1123 señala que TYPE L 8 equivale a Image en una máquina de bytes de ocho bits y que TYPE L m debería tener el mismo efecto que Image entre máquinas con palabras de m bits.

Esa equivalencia condicionada no borra el significado de la orden. Image no permite al receptor inventar una frontera de 36 bits. Local sí la comunica. Dos caminos pueden producir bytes idénticos y llevar distinta evidencia sobre por qué esa disposición es legítima.

El suelo obligatorio no era una escalera infinita

RFC 1123 exige soporte para TYPE I y TYPE L 8. Una máquina cuya memoria use palabras de m bits, cuando m no sea múltiplo de ocho, puede ofrecer también TYPE L m.

El requisito crea un suelo interoperable estrecho. No obliga a todos los servidores a reconocer cualquier entero. La sintaxis de L 36 puede estar definida y un servidor concreto puede rechazarla legítimamente. El registro de una orden no prueba el conjunto de argumentos implementados.

Tras un rechazo, el cliente conserva decisiones. Puede usar Image si su aplicación sabe conservar la estructura por otro medio, transformar previamente a un formato común o detenerse. Sustituir el tamaño en silencio borra la intención sin producir una negociación real.

Un marcador de reinicio tampoco era un número de byte lógico

El artículo histórico sobre FTP restart estudió otra clase de estado: el marcador lo definía el receptor porque éste conocía su transformación de almacenamiento y necesitaba poder retomarla. Allí se mencionaban las diferentes palabras de las máquinas como contexto.

TYPE L ocupa otra frontera. Define la unidad que la transformación recibe. Un marcador correcto no repara un ancho lógico perdido; un ancho correcto no indica por sí solo un punto seguro de reinicio. Ambos parámetros deben acompañar a la operación sin convertirse el uno en sustituto del otro.

ALLO usa la medida, no la crea

ALLO podía expresar una estimación de almacenamiento en bytes lógicos. La unidad procedía del tipo activo. La orden de reserva no convertía sus números en definición de representación y una respuesta positiva podía significar que el servidor no necesitaba hacer ninguna reserva previa.

El artículo de ALLO pregunta si una estimación produjo recursos. Éste pregunta qué unidad se estimaba y cómo cruzaba el cable. Una transferencia puede tener espacio suficiente y cortar mal las unidades, o preservar perfectamente L 36 sin que ALLO haya reservado un bloque. Mezclar ambas pruebas conduce a recuperaciones equivocadas.

IANA registra TYPE, no el armario del servidor

El registro IANA de comandos y extensiones FTP mantiene TYPE como comando de representación y enlaza su referencia. Eso fija una etiqueta común.

No informa qué tamaños acepta un servicio actual, cómo los mapea a su sistema de archivos ni si alguien los usa hoy. Para esa afirmación hacen falta observación de capacidad, respuesta de sesión, prueba de ida y vuelta e inspección de la aplicación. La referencia normativa es el inicio de esa cadena, no su conclusión.

La modestia del cable trasladó una obligación a los extremos

La historia va de un catálogo que pretendía nombrar muchos formatos, a conexiones de bytes variables y finalmente a octetos de transporte fijos con unidades lógicas opcionales. FTP redujo lo que todos tenían que compartir sin decretar que las máquinas se habían vuelto homogéneas.

Esa reducción funciona sólo si los extremos conservan lo que el cable decidió no interpretar. El tipo, la medida, la estructura y la regla local de conversión forman parte del expediente técnico. Nueve octetos pueden sobrevivir cuarenta años y seguir sin decir si eran nueve bytes, ocho caracteres de nueve bits o dos palabras de 36.

Fuentes y límites

Las fuentes son RFC 114, RFC 354, RFC 765, RFC 959, RFC 1123 y el registro IANA. Establecen diseños y requisitos, no cuota de uso actual, compatibilidad de un producto, interpretación numérica de 36 bits ni garantía de almacenamiento duradero.