Network Working Group J. Postel Request for Comments: 857 J. Reynolds ISI Obsoletes: NIC 15390 May 1983 Traducción al castellano: Enero 2002 Gonzalo Paniagua Javier OPCIÓN ECO 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 ECHO 1 2. Significados de la orden IAC WILL ECHO El que envía esta orden SOLICITA comenzar a hacer eco o confirma que empezará a hacerlo para los caracteres que reciba por la conexión TELNET reenviando esos caracteres al que los proporciona. IAC WON'T ECHO El que envía esta orden EXIGE dejar de hacer eco o rehúsa iniciar el eco de los caracteres que recibe por la conexión TELNET reenviando esos caracteres al que los proporciona. IAC DO ECHO El que envía esta orden SOLICITA que el receptor de la misma comience a hacer eco o confirma que se espera que el receptor de esta orden comience el eco de los caracteres que recibe por la conexión TELNET reenviando esos caracteres al que los proporciona. IAC DON'T ECHO EL que envía esta orden EXIGE que el receptor de la misma deje de hacer eco o no comience a hacerlo con los caracteres que recibe por la conexión TELNET. 3. Predeterminado WON'T ECHO Postel & Reynolds [Página 1] RFC 857 Mayo 1983 DON'T ECHO No se realiza eco en la conexión TELNET. 4. Motivación para la Opción EL NVT tiene una impresora y un teclado que están normalmente interconectados de tal forma que los "ecos" no necesitan ir a través de la red; es decir, el NVT opera nominalmente en un modo en que los caracteres introducidos por teclado son (de alguna manera) localmente devueltos y se muestran por la impresora. En situaciones altamente interactivas es apropiado para el proceso remoto (intérprete de lenguaje de órdenes, etc.) al que se envían los caracteres controlar la forma en que estos aparecen en la impresora. Para soportar esas situaciones interactivas, es necesario que haya una opción TELNET que permita a las partes en los dos extremos de la conexión TELNET ponerse de acuerdo en que los caracteres introducidos por el teclado NVT los va a mostrar la parte que se encuentra al otro lado de la conexión TELNET. 5. Descripción de la Opción Cuando la opción de eco está en funcionamiento, se espera que la parte del extremo de la conexión que hace eco transmita los caracteres que recibe de vuelta al que los envía. La opción no requiere que los caracteres devueltos sean exactamente los recibidos (por ejemplo, algunos sistemas muestran el carácter ASCII ESC con algo que no es el carácter ESC). Cuando la opción no está activa, el receptor de los datos no debe devolverlos al que los envía; esto, por supuesto, no implica que el receptor no pueda responder a los datos recibidos. La conexión TELNET normal es bidireccional. Esto es, que los datos fluyen por cada dirección de la conexión independientemente; y ninguna, alguna o ambas direcciones pueden estar operando simultáneamente en modo eco. Hay cinco modos de operación razonables para hacer eco en una conexión: Postel & Reynolds [Página 2] RFC 857 Mayo 1983 <---------------- Proceso 1 Proceso 2 ----------------> Ningún extremo hace eco <---------------- \ Proceso 1 / Proceso 2 ----------------> Un extremo hace eco a sí mismo <---------------- \ Proceso 1 / Proceso 2 ----------------> Un extremo hace eco para el otro <---------------- \ / Proceso 1 / \ Proceso 2 ----------------> Ambos extremos hacen eco entre sí <---------------- \ / Proceso 1 / \ Proceso 2 ----------------> Un extremo hace eco para los dos Esta opción permite decidir si un extremo hará o no eco para el otro. Sin embargo, no propociona ningún control sobre si un extremo hace o no eco para sí mismo; esta decisión se debe dejar a la decisión del sistema que haya en cada extremo (aunque pueden usar información sobre el estado del las negociaciones de eco "remoto" para decidir qué hacer). Se debe destacar que si AMBOS extremos entran en el modo de hacer eco de los caracteres transmitidos por el otro, encontces cualquier carácter transmitido en cualquier dirección circulará de un lado a otro indefinidamente. Por tanto, se debe tener cuidado en cada implementación de que si un sitio está haciendo eco, no se debe permtir activar el eco en el otro. Postel & Reynolds [Página 3] RFC 857 Mayo 1983 Según lo tratado en la Especificación del Protocolo TELNET, las dos partes de una conexión TELNET bidireccional asumen inicialmente que cada sentido de la conexión está funcionando en el modo predeterminado, que es no hacer eco (que es no usar esta opción, y lo mismo que DON'T ECHO, WON'T ECHO). Si alguna parte quiere hacer eco de los caracteres a la otra o viceversa, esa parte emite la orden apropiada (WILL ECHO o DO ECHO) y espera la aceptación de la opción. Si se rehúsa la petición de operar en modo eco, entonces la conexión continúa funcionando en modo no- eco. Si se acepta la petición de operar en modo eco, la conexión funcionará en modo eco. Depués de que se ha cambiado una conexión a modo eco, cualquier parte puede solicitar volver al modo no-eco dando la orden DON'T ECHO o WON'T ECHO apropiada (que la otra parte debe confirmar para permitir que la conexión funcione en modo no-eco). Igual que cada dirección de la conexión TELNET se puede poner en modo eco remoto independientemente, cada dirección ha de salirse del modo eco remoto separadamente. Las implementaciones de la opción eco, como las implementaciones de todas las demás opciones TELNET, deben seguir las normas para evitar bucles infinitos dadas en la sección Consideraciones Generales de la Especificación del Protocolo Telnet. Además, como cambiar del modo eco a no-eco se puede hacer con una confusión mínima (doble eco momentáneo, etc.), los cambios de modo de operación se deberían hacer em momentos coordinados de forma precisa con la recepción y la transmisión de solicitudes y respuestas. Por ejemplo si una parte responde a un DO ECHO con un WILL ECHO, se debería hacer eco de todos los caracteres de datos recibidos después del DO ECHO y un WILL ECHO debería preceder al primero de los caracteres de los que se hace eco. La opción de eco por sí sola no será suficiente normalmente para producir lo que normalmente se entiende como eco remoto de los caracteres tecleados en el teclado de un terminal -- la opción SUPRESS-GO AHEAD se deberá activar además del eco para producir el eco remoto de un carácter cada vez. 6. Un Ejemplo de Implementación de la Opción Lo siguiente es una descripción de una posible implementación para un sistema sencillo llamado "UHOST". Una implementación posible podría ser que por cada terminal de usuario, UHOST guardase tres bits de estado: si el terminal hace eco para sí mismo (UHOST siempre eco) o no (posible modo eco), si el usuario prefiere operar en modo eco o sin eco, y si la conexión de Postel & Reynolds [Página 4] RFC 857 Mayo 1983 ester teminal al servidor está o no en modo eco. Llamaremos a estos tres bits F(ísico), D(eseado) y R(eal). Cuando un terminal se conecta con UHOST, al bit F se le asigna el valor apropiado, el bit D se pone igual que el anterior y el R se pone como no-eco. Los bits F y D pueden volver al valor inicial por ordenes directas si el usuario lo desea. Por ejemplo, un usuario en Hawaii en un terminal bidireccional podría elegir no operar en modo eco, sin tener en cuenta la preferencia de un servidor en el continente. Debería ordenar a UHOST que cambie su bit D de eco a no- eco. Cuando se abre una conexión de un terminal UHOST a un servidor, el UHOST debería enviar al servdor una orden DO ECHO si el MIN (siendo no-eco menor que eco) de F y D es diferente de R. Si llega una orden WON'T ECHO o WILL ECHO del servidor, el UHOST pondrá el bit R al MIN de las peticiones recibidas (los bits F y D). Si esto cambia el estado del bit R, el UHOST enviará el reconocimiento apropiado; si no, el UHOST enviará el rehuse apropiado si no cambiar significa que tiene que denegar la solicitud (i.e., el MIN de F y D es menor que la solicitud recibida para A). Si mientras una conexión está abierta, el usuario del terminal UHOST cambia F o D, el UHOST repetirá las pruebas anteriores y enviará un DO ECHO o un DON'T ECHO, si es necesario. Cuando la conexión se cierra, el UHOSt debería resetear el bit A para indicar el modo eco de UHOST. Mientras la implementación del UHOST no implicaría que se envíen órdenes DO ECHO o DON'T ECHO al servidor excepto cuando se abre la conexión o el usuario cambia explícitamente el modo de eco, otros sistemas más grandes pueden invocar esos cambios de modo más frecuentemente. Por ejemplo, mientras un sistema que envíe una línea cada vez esté ejecutándose, el servidor puede intentar poner al usuario en modo eco local enviando la orden WON'T ECHO al usuario; pero mientras un sistema que envía un carácter cada vez esté en ejecución, el servidor podría intentar invocar el eco remoto para el usuario enviando la orden WILL ECHO al usuario. Es más, mientras que el UHOST nunca enviará una orden WILL ECHO y sólo enviará WON'T ECHO para rehusar una orden DO ECHO de un servidor, un servidor podría enviar a menudo las órdenes WILL y WON'T ECHO. Postel & Reynolds [Página 5]