Network Working Group J. Postel Request for Comments: 856 J. Reynolds ISI Obsoletes: NIC 15389 May 1983 Traducción al castellano: Agosto 2001 Gonzalo Paniagua Javier TRANSMISIÓN BINARIA EN TELNET Este RFC especifica un estándar para la comunidad ARPA Internet. Se espera que los ordenadores conectados a ARPA Internet adopten e implementen este estándar. 1. Nombre de la orden y código TRANSMIT-BINARY 0 2. Significados de la orden IAC WILL TRANSMIT-BINARY El que envía esta orden SOLICITA permiso para iniciar la transmisión o confirma que empezará a transmitir a partir de ahora caracteres que se el receptor debe interpretar como datos binarios de 8 bits. IAC WON'T TRANSMIT-BINARY Si la conexión está en modo binario, el que envía esta orden EXIGE que se empiecen a transmitir caracteres de datos que el receptor deberá interpretar como caracteres estándar ASCII del NVT. Si la conexión no está en modo binario, el que envía esta orden REHÚSA iniciar la transmisión de caracteres que deban ser interpretados como caracteres binarios por el receptor (i.e., el que envía la orden exige continuar transmitiendo caracteres en el modo actual). Una conexión está en modo binario sólo cuando una parte lo ha solicitado y la otra ha estado de acuerdo. IAC DO TRANSMIT-BINARY El que envía esta orden SOLICITA que el que envía los datos comience a transmitir o confirma que se espera que el que envía los datos transmita caracteres que se deben interpretar como datos binarios de 8 bits (i.e., por la parte que envía esta orden). IAC DON'T TRANSMIT-BINARY Postel & Reynolds [Página 1] RFC 856 Mayo 1983 Si la conexión está en modo binario, el que envía esta orden EXIGE que el que envía los datos comience a transmitir caracteres que el receptor deberá considerar como caracteres estándar ASCII del NVT (i.e., la parte que envía esta orden). Si la conexión no está en modo binario, el que envía esta orden EXIGE que el que envía los datos continúe transmitiendo caracteres en el modo actual. Una conexión está en modo binario sólo cuando una parte lo ha solicitado y la otra ha estado de acuerdo. 3. Predeterminado WON'T TRANSMIT-BINARY DON'T TRANSMIT-BINARY La conexión no está en modo binario. 4. Motivación para la Opción A veces es útil tener disponible una ruta de transmisión binario dentro del propio TELNET sin tener que utilizar uno de los mas eficientes protocolos de más alto nivel que disponen de transmisión binaria (como el Protocolo de Transferencia de Ficheros [ FTP, File Transfer Protocol ]. El uso del prefijo IAC dentro del protocolo TELNET básico proporciona la opción de transmisión binaria de una forma natural, requiriendo sólo el añadido de un mecanismo por el que las partes involucradas pueden acordar INTERPRETAR los caracteres transmitidos por una conexión TELNET como datos binarios. 5. Descripción de la Opción Con la opción de transmisión binaria en efecto, el receptor debería interpretar los caracteres recibidos desde el transmisor que no van precedidos de un IAC como datos binarios de 8 bits, con la excepción de un IAC seguido de otro IAC que representa el dato binario de 8 bits con el valor decimal 255. Un IAC seguido de una orden TELNET (más cualesquiera caracteres adicionales necesarios para completar la orden) es una orden incluso con la opción de modo binario en efecto. Un IAC seguido de un carácter que no está definido como una orden TELNET tiene el mismo significado que un IAC seguido de NOP. aunque no se debería enviar un IAC seguido de una orden no definida en este modo. 6. Sugerencias para la implementación Se prevee que las implementaciones de la opción de transmisión binaria decida rehusar alguna otra opción (como la opción de Postel & Reynolds [Página 2] RFC 856 Mayo 1983 transmisión EBCDIC) mientras que la opción de transmisión binaria está activa. Sin embargo, si un par de ordenadores pueden entender estar en modo binario a la vez que están en, por ejemplo, modo eco, entonces es correcto si ellos negocian esa combinación. Se debe mencionar que los significados de WON'T y DON'T son dependientes de si la conexión está actualmente en modo binario o no. Consideremos una conexión funcionando, digamos, en modo EBCDIC, que implica a un ordenador que ha decidido no implementar nada relacionado con la orden de modo binario. Si este sistema recibiese un DO TRANSMIT-BINARY, no reconocería la opción TRANSMIT-BINARY y, por tanto, devolvería un WON'T TRANSMIT-BINARY. Si el modo por defecto para WON'T TRANSMIT-BINARY fuese siempre el ASCII del NVT, el que envía la orden esperaría que el que la recibe hubiera cambiado a ASCII NVT, mientras que el receptor del DO TRANSMIT-BINARY no haría esta interpretación. Por tanto, tenemos como regla que cuando una conexión no está funcionando en modo binario, el modo por defecto (i.e., la interpretación de WON'T y DON'T) es continuar operando en el modo actual, ya sea el ASCII del NVT, EBCDIC o cualquier otro. Esta regla, si embargo, no se aplica una vez que la conexión está funcionando en modo binario (acordado pro ambos extremos); esto requeriría que cada parte de la conexión mantuviera una pila que contuviera todos las transiciones de métodos de codificación que han ocurrido previamente en la conexión para interpretar correctamente un WON'T o un DON'T. Por tanto, un WON'T o un DON'T recibidos después de que la conexión esté operando en modo binario provoca que el método de codificación vuelva a ASCII del NVT. Se debería recordar que una conexión TELNET es un canal de comunicación de dos vías. EL modo binario debe ser negociado separadamente para cada dirección del flujo de datos, si así se desea. Las implementaciones del modo de transmisión binario, como en todas las demás implementaciones de opciones TELNET, deben seguir las reglas para evitar bucles dadas en la sección de Consideraciones Generales de la Especificación del Protocolo TELNET. Consideremos ahora algunos aspectos particulares de la transmisión binaria desde y hacia un proceso y un terminal: a. Transmisión binaria desde un terminal. El implementador de la opción de transmisión binaria debería considerar cómo (o si) se permite a un terminal transmitiendo por una conexión TELNET con la transmisión binaria activada Postel & Reynolds [Página 3] RFC 856 Mayo 1983 generar todos los caracteres de ocho bits, ignorando consideraciones de paridad, etc., en la entrada desde el terminal. b. Transmisión binaria a un proceso. El implementador de la opción de transmisión binaria debería considerar cómo (o si) se pasan todos los caracteres a un proceso recibiendo datos de una conexión operando en modo binario. Como ejemplo del posible problema, el TOPS-20 intercepta ciertos caracteres (e.g., ETX, el control-C del terminal) a nivel del monitor y no los pasa al proceso. c. Transmisión binaria desde un proceso. El implementador de la opción de transmisión binaria debería considerar cómo (o si) se permite a un proceso transmitiendo por una conexión TELNET con la transmisión binaria activada enviar todos loca caracteres de ocho bits sin que el monitor los intercepte y los cambie por otros. Un ejemplo de este tipo de conversión se puede encontrar en el sistema TOPS-20 donde ciertos caracteres no imprimibles se convierten normalmente a un circunflejo (flecha para arriba) seguido de un carácter imprimible. d. Transmisión binaria a un terminal. El implementador de la opción de transmisión binaria debería considerar cómo (o si) se pasan todos los caracteres recibidos por una conexión con la transmisión binaria activada a un terminal local. Como ejemplo puede servir la adición de caracteres de temporización normalmente insertados localmente, cálculos de paridad y cualquier conversión de código normal. Postel & Reynolds [Página 4]