Network Working Group J. Postel Request for Comments: 855 J. Reynolds ISI Obsoletes: NIC 18640 Mayo 1983 Traducción al castellano: Febrero 2000 Gonzalo Paniagua Javier ESPECIFICACIONES DE OPCION 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. El objetivo de proporcionar opciones en el protocolo TELNET es permitir a los ordenadores obtener soluciones más elegantes al problema de la comunicación entre dispositivos dispares que la que es posible dentro del marco que ofrece el Terminal Virtual de Red ("Network Virtual Terminal", NVT). Debería ser posible paralos ordenadores inventar, probar o descartar opciones a voluntad. Sin embargo, se supone que las opciones que sean útiles de forma general podrán ser soportadas por muchos ordenadores; por tanto, es conveniente que las opciones se documenten cuidadosamente y se den bien a conocer. Además, es necesario asegurarse de que un código de opción determinado no se usa para varias opciones diferentes. Este documento especifica un método de asignación de códigos de opción y estándares para la documentación de opciones. El responsable de la asignación de códigos de opción podría renunciar al requisito de completa documentación en algunos casos en los que el código sea experimental, pero en general se requerirá la documentación antes de la asignación del código. Las opciones se harán públicas en documentos RFC; los inventores de opciones pueden, por supuesto, publicarlas también de otras formas. Los códigos de opción se asignarán por: Jonathan B. Postel University of Southern California Information Sciences Institute (USC-ISI) 4676 Admiralty Way Marina Del Rey, California 90291 (213) 822-1511 Mailbox = POSTEL@USC-ISIF La documentación de opciones debería contener, por lo menos, las siguientes secciones: Postel & Reynolds [Página 1] RFC 855 Especificaciones de opción Telnet Mayo 1983 Sección 1 - Nombre de la orden y código de opción Sección 2 - Significado de la orden Se debería describir el significado de cada posible orden TELNET relevante. Para opciones complejas, donde se requiere "subnegociación", puede haber un mayor número de órdenes posibles. El concepto de "subnegociación" se describe con más detalle posteriormente. Sección 3 - Especificación de valores por defecto Se debe describir lo que se asuma por defecto para ordenadores que no implementan o usan la opción . Sección 4 - Motivación Una detallada explicación de los motivos para inventar una opción en particular o para elegir una forma particular de la opción es muy útil para aquellos que no están afectados (o no se dan cuenta de que lo están) por el problema que esta opción va a resolver. Sección 5 - Descripción (o Reglas de implementación) La mera definición del significado de la orden y la motivación no son siempre suficientes para asegurar que dos implementaciones de una opción serán capaces de comunicarse. Por tanto, se deberá proporcionar una descripción más completa en la mayoría de los casos. Esta descripción puede consistir en texto, un ejemplo de implementación, trucos para los desarrolladores, etc. Sobre la "subnegociación" Algunas opciones requieren pasar información adicional además del código de opción. Por ejemplo, una opción que requiere un parámetro es uno de estos casos. La estrategia a usar consiste en dos pasos: primero, ambas partes acuerdan "discutir" el/los parámetro/s y, segundo, tiene lugar la "discusión". El primer paso, acordar la discusión de los parámetros, tiene lugar de la forma usual; una parte propone el uso de la opción enviando un DO (o WILL) seguido del código de opción y la otra parte acepta devolviendo WILL (o DO) seguido del código de opción. Una vez que ambas partes acuerdan usar la opción, tiene lugar la subnegociación mediante el uso de la orden SB seguida del código de opción, los parámetros y la orden SE. Se supone que ambas partes son capaces de procesar los parámetros, ya que ambos han indicado que implementan la opción (mediante el intercambio inicial de WILL y DO). Por otra Postel & Reynolds [Página 2] RFC 855 Especificaciones de opción Telnet Mayo 1983 parte, el receptor puede localizar el final de una cadena de parámetros buscando la orden SE (i.e., la cadena IAC SE), incluso si no es capaz de procesar los parámetros. Por supuesto, cualquier parte puede rehusar continuar con la negociación en cualquier momento enviando un WON'T o un DON'T a la otra parte. Por tanto, para la opción "ABC", que requiere subnegociación, los formatos de las órdenes TELNET son: IAC WILL ABC Ofrece usar la opción ABC (o envía un asentimiento positivo a la petición de la otra parte) IAC DO ABC Solicita a la otra parte el uso de la opción ABC (o asentimiento positivo al ofrecimiento de la otra parte) IAC SB ABC IAC SE Un paso de la subnegociación usado por cualquier parte. Los diseñadores de opciones que requieren "subnegociación" deben tener especial cuidado en evitar bucles infinitos en el proceso de subnegociación. Por ejemplo, si ambas partes pueden aceptar cualquier valor de un parámetro y ambas partes sugieren el uso de parámetros con diferentes valores, una de ellas posiblemente tenga una oscilación infinita de "asentimientos" (donde cada receptor cree que sólo está asintiendo la nueva propuesta el otro). Finalmente, si los parámetros en la "subnegociación" de una opción incluyen un byte con valor 255, esnecesario duplicar este byte de acuerdo con las reglas generales del protocolo TELNET. Postel & Reynolds [Página 3]