Network Working Group J. Postel Request for Comments: 854 J
Anuncio
Network Working Group Request for Comments: 854 Obsoletes: NIC 18639 Traducción al castellano: Gonzalo Paniagua Javier ISI J. Postel J. Reynolds Mayo 1983 Agosto 2001 <[email protected]> ESPECIFICACIÓN DEL PROTOCOLO TELNET Este RFC especifica un estándar para la comunidad ARPA Internet. Los ordenadores conectados a la red ARPA Internet deberían adoptar e implementar este estándar. INTRODUCCIÓN El propósito del protocolo TELNET es proporcionar un servicio de comunicaciones orientado a bytes de 8 bit general y bidireccional. El principal objetivo es permitir un método estándar de comunicar entre sí terminales y procesos orientados a terminal. Está previsto que el protocolo se pueda usar también para comunicaciones terminalterminal ("enlace") y comunicaciones proceso-proceso (computación distribuída). CONSIDERACIONES GENERALES Una conexión TELNET es una conexión TCP usada para transmitir datos con información de control TELNET intercalada. El protocolo TELNET se basa en tres ideas principales: primera, el concepto de un "Terminal Virtual de Red" (NVT, Network Virtual Terminal); segunda, el principio de opciones negociadas; y tercera, una visión simétrica de terminales y procesos. 1. Cuando se inicia una conexión TELNET, se supone que se inicia y finaliza en un "Terminal Virtual de Red" o NVT. Un NVT es un dispositivo imaginario que proporciona una representación intermedia de un terminal. Esto elimina la necesidad para los ordenadores "servidor" y "usuario" de guardar información de las características del terminal del otro y de las convenciones para manejarlo. Ambos mapean las características del dispositivo local para que a través de la red parezca un NVT y ambos pueden asumir un mapeado similar en el otro extremo. Se pretende que el NVT sea algo intermedio entre ser muy restringido (que no proporciona a los ordenadores lo suficiente como para mapear sus códigos de caracteres locales), y ser demasiado exigente (penalizando a los usuarios con terminales modestos). NOTA: El ordenador "usuario" es aquel al que el terminal físico está normalmente conectado y el ordenador "servidor" es el que Postel & Reynolds [Página 1] RFC 854 Mayo 1983 normalmente proporciona algún servicio. Desde otro punto de vista, aplicable incluso en comunicaciones terminal-terminal o procesoproceso, el ordenador "usuario" es aquel que inicia la comunicación. 2. El principio de opciones negociadas tiene en cuenta el hecho de que muchos ordenadores querrán proporcionar servicios adicionales a los disponibles en un NVT y muchos usuarios tendrán terminales sofisticados y querrán disponer de servicios sofisticados en lugar de los mínimos. Hay "opciones" independientes del Protocolo TELNET pero estructuradas dentro de él que se votarán y que se podrán usar con la estructura "DO, DON'T, WILL, WON'T" (tratada posteriormente) que permiten a un usuario y a un servidor ponerse de acuerdo para usar convenciones más elaboradas (o tal vez sólo diferentes) para sus conexiones TELNET. Entre esas opciones se podrían incluir el cambio del juego de caracteres, el modo de eco, etc. La estrategia básica para el uso de opciones es hacer que una parte (o ambas) inicien la petición de activar alguna opción. El otro lado puede entonces aceptar o rechazar la petición. Si la petición se acepta, tiene efecto inmediato; si se rechaza, el aspecto asociado de la conexión queda tal y como se especifica para un NVT. Claramente, una parte siempre puede rehusar activar una opción y nunca debe rehusar desactivar alguna opción ya que ambos lados deben estar preparados para soportar un NVT. Se ha diseñado la sintaxis de la negociación de opciones para que si ambas partes solicitan una opción simultáneamente, cada una de ellas vea la petición de la otra como el reconocimiento positivo de la suya. 3. La simetría de la sintaxis de negociación puede potencialmente llevar a bucles infinitos de reconocimiento -- cada parte viendo las órdenes que llegan no como reconocimientos sino como nuevas peticiones para reconocer. Para evitar esto, prevalecen las siguientes normas: a. Las partes sólo pueden solicitar un cambio del estado de una opción; i.e., una parte no puede enviar una "petición" simplemente para anunciar en qué modo está. b. Si una parte recibe lo que parece una petición para entrar en algún modo en el que ya está, la petición no debería reconocerse. No responder esto es esencial para evitar bucles infinitos en la negociación. Es necesario enviar una respuesta para las peticiones de cambio de modo incluso si no se ha cambiado el modo. c. Siempre que una parte envíe una orden de opción a la otra, ya RFC 854 Mayo 1983 sea una petición o un reconocimiento, y el uso de la opción va a tener algún efecto en el procesado de los datos enviados de la primera parte a la segunda, dicha orden se debe enviar en el punto donde se desee que comience a tener efecto. (Hay que tener en cuenta que pasará algún tiempo entre la transmisión de una petición y la recepción de un reconocimiento, que puede ser negativo. Por tanto, un ordenador puede ir almacenando los datos a enviar después de solicitar una opción, hasta que la petición se acepte o deniegue, para ocultar al usuario el "periodo de incertidumbre"). Es probable que las solicitudes de opción vayan de un lado a otro cuando se inicia la conexión TELNET, ya que cada parte intenta obtener el mejor servicio posible de la otra. Además de esto, se pueden usar las opciones para modificar dinámicamente las características de la conexión para ajustarse a cambios en las condiciones locales. Por ejemplo, el NVT, como se explica después, usa una disciplina de transmisión que se ajusta bien a muchas aplicaciones, como el BASIC, que envían una "línea cada vez", pero se ajusta mal a aplicaciones que, como el NLS, envían un "carácter cada vez". Un servidor puede optar por la carga extra de procesador que requiere una disciplina de "carácter cada vez" cuando se ajusta mejor al proceso local y negociaría la opción apropiada. Sin embargo, en lugar de estar permanentemente cargado con el trabajo extra que esto requiere, podría volver (es decir, negociar la vuelta) al NVT cuando no sea necesario el control detallado. Es posible que las peticiones iniciadas por procesos provoquen un bucle de petición infinito si el proceso responde a un rechazo volviendo a solicitar la opción. Para evitar que esto suceda, las peticiones rechazadas no se deben repetir hasta que algo cambie. Operacionalmente, esto puede significar que el proceso está ejecutando un programa diferente o el usuario a enviado otra orden o cualquier otra cosa que tenga sentido en el contexto para un proceso dado y una opción dados. Una buena regla a seguir es sólo se debe repetir una petición como resultado de información adicional procedente del otro extremo de la conexión o cuando se solicite por intervención del usuario a nivel local. Los diseñadores de opciones no se deberían sentir restringidos por la, en cierto modo, limitada sintaxis para negociar opciones. El objetivo de la sintaxis simple es hacer fácil tener opciones -- ya que es fácil ignorarlas. Si alguna opción en particular requiere una estructura de negociación más compleja que la posible mediante "DO, DON'T, WILL, WON'T", lo apropiado es usar "DO, DON'T, WILL, WON'T" para aclarar que ambas partes entienden la opción y, una vez conseguido esto, se puede usar una sintaxis más exótica. Por ejemplo, una parte puede enviar una solicitud para alterar RFC 854 Mayo 1983 (establecer) la longitud de línea. Si se acepta, se puede usar una sintaxis diferente para negociar la longitud de la línea -- esa "subnegociación" puede incluir campos para los valores mínimo, máximo y deseado de longitud de línea. El concepto importante es que esas negociaciones expandidas nunca deberían iniciarse hasta que una negociación previa (estándar) haya establecido que ambas partes son capaces de interpretar la sintaxis expandida. En resumen, se envía WILL XXX por cualquier parte para indicar que esa parte desea (ofrece) iniciar la opción XXX, siendo DO XXX y DON'T XXX los reconocimientos positivo y negativo respectivamente; de la misma forma, se envía DO XXX para indicar un deseo (petición) de que la otra parte (es decir, quien recibe el DO) inicie la opción XXX, siendo WILL XXX y WON'T XXX los reconocimientos positivo y negativo respectivamente. Como el NVT es lo que queda cuando no se activa ninguna opción, las respuestas DON'T y WON'T garantizan que la conexión se quede en un estado que ambas partes entienden. De esta manera, todos los procesos TELNET se pueden implementar de tal forma que ignoren completamente todas las opciones no soportadas, simplemente devolviendo un rechazo a cualquier solicitud de opción que no entienda. En la medida de lo posible, el protocolo TELNET se ha hecho simétrico entre el servidor y el usuario para que de forma natural se adapte a conexiones usuario-usuario y servidor-servidor. Se espera, pero no se requiere en absoluto, que las opciones fomenten la simetría. En cualquier caso, se acepta explícitamente que la simetría es un principio operativo más que una regla inamovible. Se debe consultar otro documento, "Especificaciones de Opción TELNET", para obtener información del procedimiento que establece nuevas opciones. EL TERMINAL VIRTUAL DE RED El Terminal Virtual de Red (NVT, Network Virtual Terminal) es un dispositivo bidireccional de caracteres. El NVT tiene una impresora y un teclado. La impresora responde a los datos que llegan y el teclado produce los datos de salida que se envían a través de la conexión TELNET y, si se desea, también a la impresora del NVT. Los "ecos" no deberían recorrer la red (aunque existen opciones para activar el modo de operación de eco "remoto", no es obligatorio implementar esta opción). El código usado es USASCII de siete bits en un campo de ocho bits. Cualquier conversión de códigos u otras consideraciones que surjan son problemas locales y no afectan al NVT. TRANSMISIÓN DE DATOS RFC 854 Mayo 1983 Aunque una conexión TELNET a través de la red es intrínsecamente bidireccional (full-dúplex), se debe ver al NVT como un dispositivo unidireccional (half-dúplex) operando en modo línea. A no ser que se negocien opciones indicando lo contrario, se aplican las siguientes condiciones por defecto a la transmisión de datos por la conexión TELNET: 1) Los datos se deben acumular en el ordenador donde se generan hasta tener una línea completa de datos o hasta que alguna señal definida localmente indique que debemos transmitir los datos. Esta señal se puede generar por un proceso o por un usuario. Todo ello mientras que el espacio de almacenamiento local lo permita. La motivación de esta regla es el elevado coste, para algunos ordenadores, de procesar una interrupción de entrada de datos por red unido a la especificación por defecto del NVT que dice que los "ecos" no circulan por la red. Por eso es razonable almacenar una cantidad de datos a medida que se obtienen. Muchos sistemas realizan alguna acción al final de cada línea de entrada (incluso las impresoras de línea o las tarjetas perforadas tienden a funcionar de esta manera), por eso la transmisión se debería ocurrir al final de cada línea. Por otra parte, un usuario o proceso puede necesitar o desear enviar datos que no necesariamente terminan en una nueva línea; por tanto, se advierte a los programadores de que proporcionen métodos para indicar localmente que todos los datos almacenados deben transmitirse inmediatamente. 2) Cuando un proceso ha terminado de enviar datos a una impresora NVT y no tiene más datos que procesar (es decir, cuando un proceso en un extremo de una conexión TELNET no puede continuar sin datos del otro extremo), el proceso debe transmitir la orden TELNET Go Ahead (Continuar). Esta regla no pretende requerir que se envíe la orden TELNET GA desde cada terminal en el extremo de una línea, ya que los servidores no requieren normalmente ninguna señal en especial (además de fin-de-línea u otros caracteres definidos localmente) para iniciar el proceso. En cambio, la orden TELNET GA está diseñada para ayudar a que el ordenador local de un usuario interaccione a nivel físico con terminales unidireccionales que disponen de un teclado que se puede bloquear, como el IBM 2741. Una descripción de este tipo de terminal puede ayudar a explicar el uso correcto de la orden GA. La conexión terminal-ordenador está siempre bajo control del RFC 854 Mayo 1983 usuario o el ordenador. Ninguno puede unilateralmente apoderarse del control cuando lo tiene el otro; en lugar de eso, quien tenga el control debe liberarlo explícitamente. En la parte del terminal, el hardware está diseñado para que libere el control cada vez que se termina una línea (es decir, cuando el usuario pulsa la tecla de nueva línea). Cuando esto ocurre, el ordenador (local) al que está conectado procesa los datos de entrada, decide si se genera salida y si no devuelve el control al terminal. Si se genera salida, el ordenador mantiene el control hasta que ha transmitido todos los datos. Las dificultades de usar este tipo de terminal a través de la red deberían ser obvias. El ordenador local no es capaz de decidir si mantener el control después de ver la señal fin-delínea o no; esta decisión sólo puede tomarla el ordenador remoto que procesa los datos. Por tanto, la orden TELNET GA proporciona un mecanismo por el cual el ordenador remoto (servidor) puede indicar al ordenador local (usuario) que es el momento de transferir el control al usuario del terminal. Debería transmitirse en esos momentos y sólo en esos momentos es en los que se debe dar al usuario el control del terminal. Téngase en cuenta que un envío prematuro de la orden GA puede provocar que se bloquee la salida, ya que el usuario probablemente pensará que la transmisión de datos está parada y, por tanto, no marcará el final de línea manualmente. Lo precedente, por supuesto, no se aplica a la dirección usuarioa-servidor de la comunicación. En esta dirección, se pueden enviar GAs en cualquier momento, pero no son necesarios. También, si la conexión TELNET se usa para comunicación proceso-a-proceso, no se necesita el envío de GAs en ninguna dirección. Finalmente, para comunicaciones terminal-a-terminal, se pueden necesitar GAs en ninguna, una o ambas direcciones. Si un ordenador espera soportar comunicación terminal-a-terminal se sugiere que el ordenador provea al usuario con algún medio para indicar manualmente que es el momento de enviar un GA; no obstante, esto no es un requisito para un proceso que implemente el protocolo TELNET. Nótese que la simetría del modelo TELNET requiere que haya un NVT en cada extremo de la conexión TELNET, al menos conceptualmente. REPRESENTACIÓN ESTÁNDAR DE FUNCIONES DE CONTROL Como se indica en la introducción de este documento, el objetivo principal del protocolo TELNET es proporcionar un interfaz estándar entre dispositivos terminales y procesos orientados a terminal a través de la red. Las primeras experiencias con este tipo de interconexión muestran que ciertas funciones son RFC 854 Mayo 1983 implementadas por la mayoría de los servidores, pero que los métodos de invocar esas funciones varían mucho. Para un usuario que interactúa con varios servidores, estas diferencias son muy frustrantes. TELNET, consecuentemente, define una representación estándar para cinco de estas funciones, descritas más abajo. Estas representaciones estándar tienen significados estándar, pero no requeridos (con la excepción de la función Interrumpir Proceso (IP) que puede ser usada por otros protocolos que usan TELNET); esto es, un sistema que no proporciona la función a los usuarios locales no necesita proporcionarla a los usuarios remotos y puede tratar la representación estándar ignorándola. Por otra parte, un sistema que proporciona la función a usuarios locales está obligado a dar la misma función a un usuario remoto que transmite la representación estándar de la función. Interrumpir proceso (IP, Interrupt Process) Muchos sistemas proporcionan una función que suspende, interrumpe, aborta o finaliza la operación de un proceso de usuario. Esta función se usa frecuentemente cuando un usuario cree que su proceso está en un bucle infinito o cuando se ha activado sin querer un proceso no deseado. IP es la representación estándar para invocar esta función. Los desarrolladores deberían tener en cuenta que otros protocolos que usan TELNET pueden requerir esta opción y, por tanto, debería implementarse si se quiere soportar esos otros protocolos. Abortar Salida (AO, Abort Output) Muchos sistemas proporcionan una función que permite a un proceso que está generando salida que se ejecute hasta terminar (o que alcance el mismo punto que alcanzaría si se ejecutara hasta el final) pero sin enviar la salida al terminal del usuario, Además, esta función elimina cualquier salida que ya se haya generado pero que no se haya imprimido (o mostrado) aún en el terminal del usuario. AO es la representación estándar para invocar esta función. Por ejemplo, algún subsistema podría aceptar normalmente una orden introducida por el usuario, enviar una larga cadena de texto al terminal del usuario como respuesta y, finalmente, indicar que está preparado para la siguiente orden enviando el carácter de "prompt" (precedido por <CR><LF>) al terminal de usuario. Si se recibe el AO durante la transmisión de la cadena de texto, una implementación razonable debería suprimir el resto de la cadena de texto pero transmitir el carácter de "prompt" precedido de <CR><LF>. (Esto es posiblemente para distinguir de la acción a tomar si se recibe IP; IP podría provocar la supresión de la cadena de texto y la RFC 854 Mayo 1983 salida del subsistema). Se debe tener en cuenta por los servidores que ofrezcan esta función que puede haber espacios de almacenamiento intermedios externos al sistema (en la red y en el ordenador local del usuario) que deberían borrarse; la forma apropiada de hacer esto es mediante la transmisión de la señal "Synch" (descrita más adelante) al sistema del usuario. Estás ahí (AYT, Are You There) Muchos sistemas proporcionan una función que ofrece al usuario alguna evidencia visible (p.e., imprimible) de que el sistema está encendido y en funcionamiento. EL usuario puede invocar esta función cuando el sistema está inesperadamente "silencioso" durante un periodo largo de tiempo a causa de la imprevista (por el usuario) duración de una operación, una inusual elevada carga del sistema, etc. AYT es la representación estándar para invocar esta función. Carácter de Borrado (EC, Erase Character) Muchos sistemas ofrecen una función que borra el último carácter o "posición de impresión"* del flujo de datos introducido por el usuario. Esta función se usa típicamente para editar la entrada desde el teclado cuando se cometen errores. EC es la representación estándar para invocar esta función. *NOTA: Una "Posición de impresión" puede contener varios caracteres que son el resultados de sobreposiciones o de secuencias como <char1> BS <char2>... Borrar Línea (EL, Erase Line) Muchos sistemas proporcionan una función que borra todos los datos de la línea actual de entrada. Esta función se suele usar para editar la entrada por teclado. EL es la representación estándar para invocar esta función. LA SEÑAL TELNET "SYNCH" Muchos sistemas de tiempo compartido ofrecen mecanismos para permitir a un terminal recuperar el control de un proceso en ejecución; las funciones IP y AO descritas previamente son ejemplos de estos mecanismos. En sistemas como esos, usados localmente, se tiene acceso a todas las señales generadas por el usuario, ya sean estas caracteres normales o señales "fuera de RFC 854 Mayo 1983 banda" especiales como las generadas por la tecla "BREAK" o la tecla "ATTN" en el IBM 2741. Esto no siempre se cumple cuando el terminal se conecta al sistema a través de la red; los mecanismos de control de flujo de la red pueden provocar que una señal de este tipo se almacene en cualquier otra parte, por ejemplo en el ordenador del usuario. Para evitar este problema, se ha creado el mecanismo "Synch" de TELNET. Una señal Synch esta formada por una notificación urgente de TCP junto con la orden TELNET de MARCA DE DATOS. La notificación urgente, que no está sujeta al control de flujo relativo a la conexión TELNET, se usa para que se trate de manera especial el flujo de datos por los procesos que lo reciban. De esta forma, el flujo de datos se explora inmediatamente en busca de señales "interesantes" tal y como se definen más abajo, descartando otros datos. La orden TELNET de MARCA DE DATOS (DM, DATA MARK) es la indicación de sincronismo en el flujo de datos que indica que cualquier señal especial ha sido generada y que el receptor puede volver a procesar el flujo de datos. El Synch se envía mediante la operación de envío TCP con el indicador de Urgente activado y DM como el último (o único) octeto de datos. Cuando se envían varios Synch rápidamente, se pueden mezclar varias notificaciones de urgente. No es posible contar dichas notificaciones ya que el número recibido será menor o igual que el de enviados. Normalmente, un DM no tiene ningún efecto; si se está en modo urgente, indica el final del procesamiento urgente. Si TCP señala el final de los datos urgentes antes de que se encuentre el DM, TELNET debería continuar el tratamiento especial del flujo de datos hasta que se encuentre un DM. Si TCP indica que hay más datos urgentes después de encontrar el DM, sólo puede ser por un Synch posterior. TELNET debería continuar el tratamiento especial del flujo de datos hasta encontrar otro DM. Señales "interesantes" son: las representaciones TELNET estándar de IP, AO y AYT (pero no EC no EL); los análogos locales de estas operaciones (si los hay); otras señales definidas por el servidor cuya acción se puede llevar a cabo sin retrasar la búsqueda en el flujo de datos. Como uno de los efectos del mecanismo SYNCH es el descarte de prácticamente todos los caracteres (excepto órdenes TELNET) entre el que lo envía y el que lo recibe, se especifica este mecanismo RFC 854 Mayo 1983 como la forma estándar de borrar los datos cuando se desee. Por ejemplo, si un usuario provoca que se transmita un AO, el servidor que lo recibe (si proporciona esa función) debería devolver un Synch al usuario. Por último, al igual que TELNET necesita la notificación urgente de TCP como una señal indicando datos fuera-de-banda, otros protocolos que usan TELNET pueden requerir órdenes TELNET que pueden ser vistas en otro nivel como señales de datos fuera-debanda. Por convenio la secuencia [IP, Synch] se usa como señal para indicar esto. Por ejemplo, supongamos que ese otro protocolo, que usa TELNET, define el carácter FINAL de cadena igual que la orden TELNET AO. Imaginemos que un usuario de este protocolo desea que un servidor procese el FINAL de cadena, pero la conexión está bloqueada porque el servidor está procesando otros datos. El usuario debería hacer que su sistema: 1. Envíe el carácter TELNET IP; 2. Envíe la secuencia TELNET SYNCH, esto es: Envíe la MARCA DE DATOS (DM) como el único carácter en una operación de envío TCP urgente. 3. Envíe el carácter FINAL de cadena; y 4. Envíe el análogo en el otro protocolo del TELNET DM, si lo hay. El usuario (o proceso actuando en su lugar) debe transmitir la secuencia TELNET SYNCH del paso 2 anterior para asegurarse de que el TELNET IP llega al intérprete TELNET del servidor. El envío urgente debería despertar al proceso TELNET; el IP debería despertar el siguiente proceso de más alto nivel. LA IMPRESORA Y EL TECLADO NVT La impresora NVT tiene un ancho de carro y una longitud de página sin especificar y puede producir representaciones de los 95 caracteres USASCII imprimibles (códigos 32 a 126). De los 33 códigos de control de USASCII (de 0 a 31 y el 127), y los otros 128 códigos que no están cubiertos (128 a 255), los siguientes tienen un significado específico para la impresora NVT: RFC 854 Mayo 1983 NOMBRE CÓDIGO SIGNIFICADO NULO (NUL) 0 Ninguna operación. Avance de 10 Mueve la impresora a la siguiente línea (LF) línea conservando la misma posición horizontal. Retorno de 13 Mueve la impresora al margen carro (CR) izquierdo de la línea actual. Además, los siguientes códigos deberán tener efectos definidos, pero no requeridos, sobre la impresora NVT. Ningún extremo de una conexión TELNET puede asumir que el otro lado hará o ha hecho, ninguna acción particular al recibir o transmitir estos: Campana (BEL) 7 Produce una indicación audible o visible que NO desplaza el cabezal de la impresora. Retroceso (BS) 8 Mueve el cabezal una posición hacia el margen izquierdo. Tabulador hor 9 Mueve la impresora al siguiente izontal (HT) punto de parada horizontal. No se especifica cómo cada parte deter mina o establece dónde están esos puntos de parada. Tabulador ver 11 Mueve la impresora al siguiente tical (VT) punto de parada vertical. No se especifica cómo cada parte deter mina o establece dónde están esos puntos de parada. Avance de 12 Mueve la impresora al principio de página (FF) la siguiente página manteniendo la misma posición horizontal. El resto de los códigos no hacen que la impresora NVT realice acción alguna. La secuencia "CR LF", según la definición, hará que el NVT se posicione en el margen izquierdo de la siguiente línea (tal y como lo haría, por ejemplo, la secuencia "LF CR"). Sin embargo, muchos sistemas y terminales no tratan el CR y el LF de forma independi ente y esto hará realizar un esfuerzo extra para simular su efecto. (Por ejemplo, algunos terminales no tienen un CR separado del LF, pero en ellos se puede simular el CR con retrocesos.) Por tanto, la secuencia "CR LF" se debe tratar como si fuera un carácter de nueva línea y usado cuando se pretende obtener el RFC 854 Mayo 1983 resultado de su acción combinada; la secuencia "CR NUL" se usará cuando lo único que se quiere es un retorno de carro; y se debe evitar el carácter CR en otros contextos. Esta regla asegura a los sistemas que deben decidir si realizar un función de "nueva línea" o múltiples retrocesos que el flujo TELNET contiene un carácter después del CR que permitirá tomar una decisión acertada. Nótese que se requiere "CR LF" o "CR NUL" en ambas direcciones (en el modo ASCII por defecto), para preservar la simetría del modelo NVT. Aunque se puede saber en determinadas situaciones (p.e., con las opciones de eco remoto y continuar en efecto) que no estamos enviando los caracteres a una impresora real, sin embargo, en aras de la consistencia, el protocolo requiere que se inserte un NUL después de cada CR que no vaya seguido de un LF en el flujo de datos. La conversión de esto es que un NUL recibido en el flujo de datos después de un CR (en ausencia de opciones que explícitamente indiquen lo contrario) debería ser eliminado antes de aplicar el conjunto de caracteres usado localmente por el NVT. El teclado NVT tiene teclas o combinaciones de teclas o secuencias de teclas para generar los 128 códigos USASCII. Nótese que aunque muchos de ellos no tienen efecto sobre la impresora NVT, el teclado NVT es capaz de generarlos todos. Además de estos códigos, el teclado NVT deberá poder generar los siguientes códigos adicionales que, excepto en los que se diga lo contrario, tiene significados definidos pero no requeridos. La asignación de códigos para estos "caracteres" está en la sección de Órdenes TELNET, porque son, en cierto sentido, genéricos y debería estar disponibles incluso cuando el flujo de datos se interpreta como si fuera otro código de caracteres. Synch Esta tecla permite al usuario borrar los datos que están en camino hacia el otro extremo. La activación de esta tecla causa el envío de un DM (ver sección sobre órdenes) por el flujo de datos y una notificación TCP de urgente se asocia con él. El par DM-urgente tendrá el significado requerido según se ha definido anteriormente. Break (BRK, interrumpir) Se proporciona este código porque es una señal fuera del con junto USASCII al que se le da un significado local en muchos sistemas. Su propósito es indicar la pulsación de la tecla de interrupción o de atención. Nótese, sin embargo, que la RFC 854 Mayo 1983 intención es proporcionar un código 129 para sistemas que lo requieren, no como un sinónimo de la representación estándar IP. Interrumpir proceso (IP, Interrupt Process) Suspende, interrumpe, aborta o termina el proceso al que está conectado el NVT. También es parte de la señal fuera-de-banda para otros protocolos que usan TELNET. Abortar salida (AO, Abort Output) Permite al proceso ejecutarse (o aparentarlo) hasta finalizar, pero no envía su salida al usuario. También envía un Synch al usuario. Estás ahí (AYT, Are You There) Devuelve al NVT alguna evidencia visible (p.e., imprimible) de que se ha recibido el AYT. Borrar carácter (EC, Erase Character) El receptor debería borrar el carácter o "posición de impresión" inmediatamente anterior en el flujo de datos. Borrar línea (EL, Erase Line) El receptor debería borrar caracteres del flujo de datos hacia atrás hasta, pero sin incluir, el último "CR LF" enviado por la conexión TELNET. El espíritu de estas teclas "extra", y también de las que afectan al formato de impresión, es que deberían representar una extensión natural del mapeado que ya se debe hacer entre "NVT" y "local". Igual que el octeto 68 (104 en octal) se debería mapear al código local para la D mayúscula, el carácter EC se debería mapear a cualquiera que sea la función de borrar carácter en local. Además, igual que el mapeado para 124 (174 en octal) es de alguna forma arbitrario en un entorno que no tiene ningún carácter de barra vertical, el carácter EL también puede tener un mapeado arbitrario (o ninguno en absoluto) si no se dispone en local de ninguna función para borrar una línea. Igualmente para los caracteres que afectan al formato: si el terminal tiene tabulador vertical, entonces el mapeado para el VT es obvio y sólo cuando el terminal no lo tiene el efecto es impredecible. ESTRUCTURA DE ORDENES TELNET RFC 854 Mayo 1983 Todas las órdenes TELNET consisten, al menos, en una secuencia de dos bytes: el carácter de escape "Interpretar como Orden" (IAC) seguido por el código de orden. Las órdenes que negocian opciones consisten en secuencias de tres bytes, siendo el tercero el código para la opción referenciada. Se ha elegido este formato para hacer que si se usa racionalmente el espacio de datos -- mediante negociaciones a partir del NVT básico, por supuesto -- las colisiones de bytes de datos con órdenes se minimicen, requiriendo esas colisiones la incon veniencia e ineficiencia de "escapar" los bytes de datos. De la forma indicada, sólo se necesita duplicar el IAC para enviarlo como un dato y los otros 255 códigos se pueden pasar transparentemente. Estas son las órdenes TELNET definidas. Tenga en cuenta que estos códigos o secuencias de códigos sólo tienen el significado que se indica si van inmediatamente precedidos por un IAC. NOMBRE CÓDIGO SIGNIFICADO SE 240 Fin de los parámetros de subnegociación. NOP 241 No operación. Marca de datos (DM) 242 La parte del flujo de datos de un Synch. Siempre se debe acompañar de una notifi cación urgente de TCP. Break 243 Carácter BRK del NVT. Interrumpir proceso 244 La función IP. Interrumpir salida 245 La función AO. Estás Ahí 246 La función AYT. Borrar Carácter 247 La función EC. Borrar Línea 248 La función EL. Continuar 249 La señal GA. SB 250 Indica que lo que sigue es una subnego ciación de la opción indicada. WILL (código de 251 Indica el deseo de iniciar el uso de una opción) opción o la confirmación de que ya se está usando. WON'T (código de 252 Denota la negativa a usar o continuar opción) usando la opción indicada. DO (código de 253 Es una solicitud para que el otro lado opción) use una opción o la confirmación de que se espera que el otro lado la use. DON'T (código de 254 Pide a la otra parte que deje de usar opción) una opción o indica que ya no esperamos que la use más. IAC 255 Byte de datos 255. ESTABLECIMIENTO DE LA CONEXIÓN RFC 854 Mayo 1983 La conexión TCP del TELNET se establece entre el puerto U del usuario y el puerto L del servidor. El servidor espera esas conexiones en un puerto L conocido. Como una conexión TCP es bidireccional y se iden tifica por el par de puertos, el servidor puede atender muchas conex iones simultáneas entre su puerto L y diferentes puertos U de usuario. Asignación de puertos Cuando se usa para acceso remoto de usuarios a un ordenador (i.e., acceso desde un terminal remoto) a este protocolo se le asigna el puerto servidor 23 (27 en octal). Esto es: L=23.
