Network Working Group J. Postel Request for Comments: 859 J. Reynolds ISI Obsoletes: RFC 651 (NIC 31154) Mayo 1983 OPCIÓN ESTADO DE 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 STATUS 5 2. Significados de la orden Esta opción se aplica por separado a cada dirección del flujo de datos. IAC DON'T STATUS El que la envía rehúsa continuar negociando sobre el estado actual de las opciones. IAC WON'T STATUS El que la envía rehúsa continuar negociando sobre el estado actual de las opciones. IAC SB STATUS SEND IAC SE El que la envía pide al receptor que transmita su (la del receptor) percepción del estado actual de las opciones Telnet. El código para SEND es 1. (Vea más abajo). IAC SB STATUS IS ... IAC SE El que la envía comunica su percepción del estado actual de las opciones Telnet. El código para IS es 0. (Vea más abajo). 3. Predeterminado DON'T STATUS, WON'T STATUS No se negociará sobre el estado actual de las opciones. 4. Motivación para la Opción Postel & Reynolds [Página 1] RFC 859 Mayo 1983 Esta opción permite a un usuario/proceso verificar el estado de las opciones TELNET (por ejemplo, eco) tal y como lo ve la persona o proceso en el otro extremo de la conexión TELNET. La simple negociación de opciones puede llevar al bucle infinito de peticiones sobre el que se habló en la sección Consideraciones Generales de la Especificación de TELNET. Esta opción encaja en la estructura normal de las opciones TELNET posponiendo la transferencia efectiva de la información a la orden SB. 5. Descripción de la Opción WILL y DO se usan sólo para obtener y garantizar el permiso para futuras negociaciones. El cambio de información sobre el estado ocurre dentro de subórdenes de opción (IAC SB STATUS...). Una vez que ambos hosts han intercambiado un WILL y un DO, el que ha enviado WILL STATUS puede transmitir información de estado, espontáneamente o como respuesta a una petición del que envió el DO. En el peor de los casos, esto puede llevar a transmitir la información dos veces. Sólo el que envía el DO puede hacer peticiones (IAC SB STATUS SEND IAC SE) y sólo el que envía el WILL puede transmitir información de estado (dento de una orden IAC SB STATUS IS ... IAC SE). IS tiene las subórdenes WILL, DO y SB. Se usan EXACTAMENTE como se usan para la negociación de opciones TELNET, excepto que cada SB se termina con un SE en lugar de un IAC SE. La transmisión de SE como un octeto de datos se consigue enviándolo por duplicado (SE SE). Se asume que las opciones que no se describen explícitamente están en sus estados predeterminados. Un único IAC SB STATUS IS ... IAC SE describe el estado de TODAS las opciones. Lo que sigue es un ejemplo de uso de la opción: Host1: IAC DO STATUS Host2: IAC WILL STATUS (Host2 puede desde ahora enviar información de estado en cualquier momento. NO se necesita que Host1 lo solicite. Esto no debería producir ninguna condición de carrera [N. del T.: 'race condition', que los dos intenten hacer simultáneamente lo mismo] peligrosa. En el peor de los casos, se enviarán dos IS.) Host1 (quizás): IAC SB STATUS SEND IAC SE Host2 (se ha dividido el flujo de datos en varias líneas para que se lea mejor. No hay retornos de carro implícitos.): Postel & Reynolds [Página 2] RFC 859 Mayo 1983 IAC SB STATUS IS WILL ECHO DO SUPPRESS-GO-AHEAD WILL STATUS DO STATUS IAC SE Explicación de la percepción de Host2: es responsable de hacer echo de los datos que reciba por la conexión TELNET; no enviará señales de continuación ['Go-Ahead', GA]; podrá emitir y solicitar información de estado. Traducción al castellano: Gonzalo Paniagua Javier, marzo 2003. Postel & Reynolds [Página 3]