Especificación Del Protocolo Telnet

Page 1 of 15
Network Working Group J. Postel

Request for Comments: 854 J. Reynolds
ISI
Obsoletes: NIC 18639 Mayo 1983
Traducción al castellano: Agosto 2001
Gonzalo Paniagua Javier <gpanjav@jazzfree.com>
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 terminal-
terminal ("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
http://rfc-es.org/rfc/rfc0854-es.txt 30-04-2011
Page 2 of 15
normalmente proporciona algún servicio. Desde otro punto de vista,

aplicable incluso en comunicaciones terminal-terminal o proceso-
proceso, 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
Page 3 of 15
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.
Page 4 of 15
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
Page 5 of 15
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-de-
línea o no; esta decisión sólo puede tomarla el ordenador
remoto que procesa los datos. Por tanto, la orden TELNET GA
Page 6 of 15
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 usuario-

a-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
Page 7 of 15
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
Page 8 of 15
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á
Page 9 of 15
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-de-
banda.
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
Page 10 of 15
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.
Page 11 of 15
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
Page 12 of 15
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,
Page 13 of 15
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
Page 14 of 15
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.
Page 15 of 15

Especificación Del Protocolo Telnet

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Especificación Del Protocolo Telnet

Transféré par

Droits d'auteur :

Formats disponibles

Page 1 of 15

Network Working Group J. Postel

ESPECIFICACIÓN DEL PROTOCOLO TELNET

Este RFC especifica un estándar para la comunidad ARPA Internet. Los

El propósito del protocolo TELNET es proporcionar un servicio de

El protocolo TELNET se basa en tres ideas principales: primera, el

1. Cuando se inicia una conexión TELNET, se supone que se inicia y

NOTA: El ordenador "usuario" es aquel al que el terminal físico

Postel & Reynolds [Página 1]

RFC 854 Mayo 1983

normalmente proporciona algún servicio. Desde otro punto de vista,

2. El principio de opciones negociadas tiene en cuenta el hecho de

La estrategia básica para el uso de opciones es hacer que una parte

Se ha diseñado la sintaxis de la negociación de opciones para que si

3. La simetría de la sintaxis de negociación puede potencialmente

a. Las partes sólo pueden solicitar un cambio del estado de una

b. Si una parte recibe lo que parece una petición para entrar en

c. Siempre que una parte envíe una orden de opción a la otra, ya

Postel & Reynolds [Página 2]

RFC 854 Mayo 1983

sea una petición o un reconocimiento, y el uso de la opción va a

cuenta que pasará algún tiempo entre la transmisión de una

Es probable que las solicitudes de opción vayan de un lado a otro

Es posible que las peticiones iniciadas por procesos provoquen un

Los diseñadores de opciones no se deberían sentir restringidos por

Postel & Reynolds [Página 3]

RFC 854 Mayo 1983

(establecer) la longitud de línea. Si se acepta, se puede usar una

En la medida de lo posible, el protocolo TELNET se ha hecho simétrico

Se debe consultar otro documento, "Especificaciones de Opción

EL TERMINAL VIRTUAL DE RED

El Terminal Virtual de Red (NVT, Network Virtual Terminal) es un

Postel & Reynolds [Página 4]

RFC 854 Mayo 1983

Aunque una conexión TELNET a través de la red es intrínsecamente

1) Los datos se deben acumular en el ordenador donde se generan

La motivación de esta regla es el elevado coste, para algunos

2) Cuando un proceso ha terminado de enviar datos a una

Esta regla no pretende requerir que se envíe la orden TELNET GA

La conexión terminal-ordenador está siempre bajo control del

Postel & Reynolds [Página 5]

RFC 854 Mayo 1983

usuario o el ordenador. Ninguno puede unilateralmente

Las dificultades de usar este tipo de terminal a través de la

proporciona un mecanismo por el cual el ordenador remoto

Lo precedente, por supuesto, no se aplica a la dirección usuario-

REPRESENTACIÓN ESTÁNDAR DE FUNCIONES DE CONTROL

Como se indica en la introducción de este documento, el objetivo

Postel & Reynolds [Página 6]

RFC 854 Mayo 1983

implementadas por la mayoría de los servidores, pero que los

Interrumpir proceso (IP, Interrupt Process)

Muchos sistemas proporcionan una función que suspende,

cree que su proceso está en un bucle infinito o cuando se ha

Abortar Salida (AO, Abort Output)

Muchos sistemas proporcionan una función que permite a un

Postel & Reynolds [Página 7]

RFC 854 Mayo 1983

salida del subsistema).

Se debe tener en cuenta por los servidores que ofrezcan esta

Estás ahí (AYT, Are You There)

Muchos sistemas proporcionan una función que ofrece al usuario

Carácter de Borrado (EC, Erase Character)