Resumen

  • El RFC 2066 exigió ACCEPTED incluso si el receptor ya empleaba un juego solicitado: el silencio dejó de ser una aceptación posible.
  • Dos CHARSET REQUEST simultáneos se resolvían por rol: el servidor rechazaba la petición del cliente y el cliente contestaba a la del servidor.
  • La respuesta acreditaba recepción y fijaba la codificación del texto posterior, pero no probaba bytes correctos, traducción fiel, consumo por la aplicación, autenticación ni seguridad.

Un extremo Telnet propone dos juegos de caracteres y no recibe nada. Quizá el otro ya usa uno de ellos y cree que la regla antigua le manda callar. Quizá el mensaje se perdió. Quizá la subnegociación está mal implementada. Para quien espera, las tres historias producen la misma evidencia: silencio.

El RFC 2066, publicado como Experimental en enero de 1997, se negó a convertir esa ambigüedad en estado compartido. Definió la opción 42, CHARSET, para que cliente y servidor nombraran la codificación del texto y, opcionalmente, intercambiaran tablas de traducción. Su decisión más interesante no fue ampliar el catálogo de alfabetos, sino exigir que la transición acabara con una respuesta observable.

La regla antibucles no bastaba en esta capa

El RFC 854 organizaba las opciones de Telnet con DO, DON'T, WILL y WON'T. Su sintaxis simétrica permitía que dos peticiones simultáneas sirvieran de confirmación positiva mutua. Pero la misma simetría podía crear una cadena infinita de respuestas. Por eso una aparente petición de un modo ya vigente no debía confirmarse, mientras que una petición real de cambio sí exigía respuesta.

El RFC 855 colocó los parámetros detrás de ese acuerdo. Primero las partes aceptaban discutir la opción mediante DO/WILL; después intercambiaban valores entre IAC SB e IAC SE. Autorizar CHARSET y seleccionar el juego eran dos actos. Los primeros mensajes no decidían todavía cómo interpretar el siguiente octeto de texto.

RFC 2066 prohibió trasladar el silencio a la petición de charset. Si el receptor ya enviaba y esperaba texto en uno de los juegos enumerados, tenía que emitir ACCEPTED y no podía ignorar el mensaje. El propio documento lo justificó por determinación: el solicitante no debía esperar a un timeout e inferir. Como nadie contestaba a la confirmación positiva, la respuesta explícita tampoco reabría el bucle.

Una lista preferida seguía siendo una propuesta

Solo podía enviar CHARSET REQUEST quien hubiera recibido DO CHARSET y enviado WILL CHARSET, en cualquier orden. La petición contenía uno o varios nombres, normalmente ordenados por preferencia. Los nombres sin el prefijo privado X- debían estar registrados en IANA. El receptor conservaba la facultad de escoger según capacidad y criterio propios.

Había cuatro salidas: confirmar el juego ya utilizado; elegir otro soportado de la lista; devolver una tabla si esa opción estaba ofrecida; o responder REJECTED cuando ninguno resultaba posible. La confirmación positiva nombraba un elemento de la propuesta. La negativa acreditaba que el mensaje había llegado, pero rechazaba todos sus elementos en esa ronda.

ACCEPTED y REJECTED terminaban la subnegociación en curso. El primero obligaba a codificar el texto siguiente con el juego indicado. El segundo mantenía fuera de vigor las alternativas propuestas. Ninguno diagnosticaba la implementación entera ni impedía otra oferta posterior.

Dos peticiones necesitaban un actor que cediera primero

Si los dos extremos autorizados enviaban CHARSET REQUEST antes de ver el mensaje contrario, la simetría producía bloqueo. Una nueva petición no era una respuesta válida a la que estaba pendiente. Ambos podían quedarse esperando el cierre de su propuesta mientras sostenían la del otro.

RFC 2066 desempató mediante los roles estables. El servidor debía rechazar la petición del cliente; el cliente debía contestar a la del servidor. Una propuesta quedaba cerrada y la otra avanzaba hacia ACCEPTED, REJECTED o una tabla. No era un privilegio sustantivo para la preferencia del servidor. Era una regla que permitía a ambos programas calcular la misma transición.

Después de un rechazo podían abrirse nuevas rondas. Un servidor que prefiriera el juego de su aplicación podía rechazar la lista inicial y enviar la suya. Si el cliente tampoco podía aceptarla, el servidor podía volver a una opción ofrecida antes. Cada intercambio mantenía su propio final. Las preferencias cambiaban; el límite del recibo no.

La respuesta dividía el flujo de bytes

Después de ACCEPTED, el texto posterior debía usar el juego escogido. Mientras la subnegociación seguía abierta, los datos debían ponerse en cola y liberarse tras su conclusión. La respuesta era también un punto de secuencia entre bytes regidos por el acuerdo antiguo y bytes regidos por el nuevo.

El alcance no era total. La traducción afectaba al texto, no a los comandos Telnet, y solo se producía en modo BINARY. Sin BINARY, seguía rigiendo NVT ASCII. Para terminales en bloques, el RFC recomendaba End of Record para conservar límites claros. Seleccionar charset no sustituía el resto del contrato.

Las tablas tenían su propia terminación: TTABLE-ACK confirmaba recepción, TTABLE-NAK pedía otro envío, y los fallos repetidos debían desembocar en TTABLE-REJECTED o CHARSET REJECTED, no en reintentos infinitos.

El recibo era fuerte porque decía poco

Un ACCEPTED capturado acredita que el par recibió una petición concreta y eligió un nombre de esa lista para el texto siguiente. No acredita que los bytes posteriores respetaran la codificación, que la tabla fuera correcta, que la aplicación entendiera o que el usuario lograra su objetivo. REJECTED demuestra recepción y negativa de esa ronda, no incapacidad permanente.

Tampoco era seguridad. La sección Security Considerations del RFC dice que no se discuten cuestiones de seguridad. Negociar codificación no autentica extremos, no autoriza aplicaciones, no cifra el flujo ni protege su integridad. La transición puede ser determinista en un canal inseguro.

El registro actual de IANA mantiene el número 42 para CHARSET, y RFC 2066 conserva su condición Experimental. Son pruebas de publicación y asignación, no de despliegue. A la luz del marco posterior de Lu Heng sobre especificación inicial mínima, el diseño puede leerse como una capa común estrecha: condiciones de petición, respuestas terminales, frontera de bytes y regla de conflicto aplicables localmente. Es una interpretación editorial posterior, no intención demostrada del autor. La conclusión histórica segura es más concreta: si el silencio admite varias explicaciones, el recibo ausente debe convertirse en protocolo.

Fuentes