La dirección OSI tenía que transportar más que una ruta: RFC 1277

Resumen

• RFC 1277 codificó los datos necesarios para intentar una conexión OSI sobre TCP/IP o ciertas redes X.25 cuando no había un servicio de red OSI.
• Su formato globalmente único podía identificar una red y llevar parámetros de transporte; la asignación no demostraba por sí sola que la dirección fuera enrutable ni que respondiera un servicio.

El directorio OSI podía devolver una dirección de presentación, pero el modelo suponía que las direcciones de red procedían de un servicio OSI. Esa premisa no encajaba con todos los pilotos. Ya se ejecutaban aplicaciones OSI sobre Internet, redes X.25 públicas o privadas y redes aisladas. Exigir que cada experimento esperara a un servicio de red OSI mundial habría vuelto inútil el directorio precisamente en los entornos donde se intentaba usar.

RFC 1277 resolvió un paso acotado de la cadena de conexión. Una aplicación consultaba una dirección de presentación; después, el cliente debía extraer cada dirección de red, decidir si podía usarla y cómo, ordenarlas por preferencia e intentar una conexión. El memorando se centró en esa extracción. Definió codificaciones de las que un cliente podía deducir la información de capa inferior que el directorio no suministraba por separado. No definió todo el procedimiento de conexión, el descubrimiento de rutas ni el éxito de un intercambio de aplicación.

La distinción importaba porque una dirección cumplía varias funciones. En X.25 internacional, una dirección de forma X.121 podía identificar un DTE y, en el caso adecuado, permitir una ruta por la red pública X.25. Pero un identificador de asignación no era necesariamente topológico: un sistema final no podía suponer que toda parte asignada globalmente describiera un camino. RFC 1277 dice que el IDP era ante todo un mecanismo de asignación y que, en principio, los usuarios no podían inferir el enrutamiento a partir de él.

La recomendación de interpretar ciertas formas X.121 como rutas dependía del servicio y formato empleados; los medios privados podían descubrir alternativas preferibles.

Para las redes TCP/IP que transportaban el servicio de transporte OSI definido por RFC 1006, RFC 1277 usó otra codificación. La parte específica de la red colocaba primero una dirección IPv4 de 12 dígitos, seguida opcionalmente por un puerto de cinco dígitos y un conjunto de transporte también de cinco dígitos. Este último era una palabra de indicadores de 16 bits: los valores representaban TCP y UDP; si faltaba o era cero, el valor predeterminado era TCP. El ejemplo del RFC codificó 10.0.0.6, el puerto 9 y UDP. Es una regla para interpretar e intentar una conexión, no una prueba de que la dirección estuviera vigente, fuera alcanzable, escuchara o tuviera autorización.

El nuevo formato también debía distinguirse de una dirección utilizada por un servicio de red OSI auténtico. RFC 1277 eligió el AFI Telex porque dejaba una parte específica de dominio más amplia y era menos probable que se confundiera con esos otros usos. Un prefijo breve separaba subredes y el resto transportaba datos propios de cada red. El diseño intercambiaba una estructura compacta y autoexplicativa por una representación decimal larga; el memorando señala que una forma binaria ASN.1 habría resultado atractiva, pero no cabía en el espacio de direcciones disponible.

Ese compromiso pertenecía a un entorno de ingeniería transitorio, no a una ley universal sobre direcciones. La nota histórica del memorando dice que el método se implementó y que se demostró su viabilidad en los proyectos THORN e ISODE/QUIPU. Es evidencia de una propuesta funcional en esos proyectos, no de adopción amplia. RFC 1278 describió después una cadena legible para direcciones de presentación, expresamente para mostrarla y no para almacenarla internamente; era otra capa frente a la asignación y codificación inferior de RFC 1277.

Las pautas NSAP de RFC 1237, por su parte, tratan el servicio de red OSI sin conexión, no el caso no-OSI que RFC 1277 intentaba resolver.

La enseñanza duradera de RFC 1277 es más limitada que «una dirección indica cómo conectarse». Un registro del directorio puede incluir suficiente estructura para que el cliente elija una interpretación de capa inferior. Aun así necesita una ruta activa, un receptor compatible, un intercambio de transporte satisfactorio y una respuesta de aplicación. Tratar el valor codificado como prueba de esos cuatro elementos confundiría asignación, interpretación, alcanzabilidad y servicio: el memorando nunca afirmó tal cosa.

Fuentes: RFC 1277; RFC 1006; RFC 1278; RFC 1237.