Resumen

  • RFC 3017 dio una gramática XML común a números, medios, túneles, scripts de marcación, DNS, proxies, pasarelas y reglas de usuario, aunque dejó expresamente fuera el protocolo que distribuía y actualizaba el listín.
  • phoneBook@version y pop@entryVersion eran pistas de cambio dentro de una identidad conocida; no eran sellos de tiempo globales, firmas, confirmaciones de instalación ni pruebas de que el POP siguiera prestando servicio.

El portátil conservaba una copia que había funcionado el mes anterior. El servidor ofrecía otra con un número mayor. Actualizar parecía la decisión prudente hasta que el nuevo archivo hizo que el marcador eligiera un número que ya no respondía.

No bastaba con decir que el servidor tenía la versión más alta. Un consorcio podía producir ediciones distintas para grupos distintos, y un usuario podía extraer sólo un país o un tipo de acceso. El atributo name del listín era una cadena arbitraria. Sin identificar editor, audiencia y línea de base, dos números no necesariamente pertenecían a la misma secuencia.

RFC 3017 apareció en diciembre de 2000 para normalizar la sintaxis y la semántica de ese archivo. El problema histórico era concreto: quienes viajaban necesitaban puntos locales de acceso pertenecientes a múltiples proveedores, y el software debía configurar el equipo sin obligar al usuario a comprender cada red.

Por eso el listín no terminaba en un teléfono. Podía incluir velocidades, medios, túneles, propiedades, precio, script, ubicación, DNS, correo, proxies, gateway, asistencia y prefijos o sufijos que el marcador añadía al nombre de usuario.

La comodidad convertía el fichero en superficie de control.

La vista unificada seguía teniendo autores y recortes

Cada operador aportaba información sobre sus POP. El consorcio la reunía y entregaba una versión unificada a los clientes. La propia RFC preveía versiones adaptadas y subconjuntos locales.

Ese recorrido separaba varias preguntas. El operador podía conocer el estado de su acceso; el consorcio conocía la edición que había compilado; el cliente conocía el archivo que había descargado; sólo la máquina podía mostrar qué valores estaban activos. Ninguna observación contenía automáticamente a las demás.

RFC 2194 había descrito un antecedente: en GRIC, los miembros remitían sus datos al secretariado, éste concatenaba manualmente los números y publicaba actualizaciones por FTP, web y cliente. Además de números había ubicaciones, proxies, configuración del marcador y servidores. No es evidencia de que usaran RFC 3017, sino del trabajo multilateral que una DTD común intentaba ordenar.

Incrementar no era lo mismo que aplicar

El contador global debía crecer al modificarse el listín. El texto decía que un servidor podía usar la comparación para decidir una acción y, como ejemplo, enviar una URL con diferencias.

Sin embargo, el documento no definía el archivo de diferencias ni la operación que lo aplicaba. Tampoco especificaba transporte, autenticación, commit, rollback o borrado. Lo excluía de su alcance.

RFC 2477 había enumerado lo que un protocolo de actualización debía resolver: autenticar al servidor, saltar desde cualquier versión anterior hasta la última, verificar la integridad antes de aplicar el cambio, comprobar el resultado producido, ser ligero y atender idioma y juego de caracteres.

Por tanto, un valor mayor sólo indicaba que la fuente afirmaba haber cambiado un objeto dentro de su espacio. No demostraba que el cliente recibiera el artefacto correcto, que la base fuera compatible, que el resultado pasara la verificación o que el archivo activo hubiese sido sustituido.

El contador por POP tampoco cerraba la operación. entryVersion podía ayudar a combinar, pero pop no tenía un ID XML equivalente al de setup, support y provider. Al cambiar el teléfono, otra capa debía decidir si seguía siendo el mismo POP. Al desaparecer una entrada, debía distinguir borrado, filtrado de audiencia, transferencia parcial y error de compilación.

La DTD ofrecía material para un algoritmo de actualización. No era el algoritmo.

El documento podía ser válido y la llamada imposible

La mayoría de los contenidos eran #PCDATA. Las notaciones de FQDN o dirección IP expresaban una intención de tipo, no una comprobación del mundo. El XML podía validar con un número retirado, un proxy inaccesible o un precio vencido.

La diferencia entre texto y acción era especialmente importante en dialScript. El cliente podía utilizar ese guion al conectar. También podía aplicar automáticamente prefijos y sufijos al usuario, o instalar DNS, correo, proxy y gateway desde setup.

Un error de datos podía cambiar tres cosas a la vez: a quién se llamaba, qué identidad se presentaba y por dónde salía el tráfico posterior.

Las extensiones registradas permitían que el formato evolucionara. La exigencia de que nuevos elementos fueran opcionales protegía la validez de documentos antiguos. No garantizaba que una implementación antigua entendiera el efecto de un valor nuevo. Para saberlo había que observar versión de parser, conjunto de extensiones y política ante lo desconocido.

Firmar el listín no llamaba a los POP

RFC 3017 situó la autenticación del emisor y la integridad fuera de la DTD, y mencionó una firma PGP como ejemplo. Era una separación necesaria: validar XML no autentica un editor.

Pero una firma válida tampoco prueba actualidad operativa. Puede vincular los bytes a una clave según cierta política. No verifica que el número siga asignado, que el POP mantenga el túnel, que el precio permanezca vigente o que el fichero se destine a esa audiencia.

Después de marcar aún quedaba la autenticación. RFC 2486 definió el Network Access Identifier usado en PPP y para orientar solicitudes hacia el dominio de origen. Un enlace podía levantarse y la identidad ser rechazada. La identidad podía ser aceptada y fallar la dirección, el túnel o el DNS. El usuario podía conseguir red y no llegar a la aplicación.

Una sola etiqueta de “actualización correcta” borraría esas fronteras.

El mismo parámetro podía proceder de otro lugar

RFC 3017 advertía que ciertos valores de configuración también podían obtenerse por DHCP. Si el listín decía un DNS y DHCP entregaba otro, la gramática no establecía la precedencia. Esa decisión pertenecía al cliente y a la política de la red.

La prueba útil tenía que llegar hasta el estado efectivo. Debía conservar editor, nombre, variante, digest, versión global, POP, dirección, entryVersion, firma, parser, extensiones, base y resultado del commit. Después debía registrar por separado llamada, enlace, PPP, NAI, autenticación, dirección, túnel, DNS, proxy y aplicación.

Así se podía diferenciar un listín obsoleto de una mala fusión, un teléfono caído, una identidad rechazada o una red posterior averiada.

La modestia del estándar era una protección

RFC 3017 no afirmó que una DTD gobernara todo el ciclo. Fijó la forma común y dejó la transición a otra especificación. El error no estaba en mantener estrecho el documento, sino en permitir que una implementación atribuyera a su contador una autoridad que el RFC nunca le dio.

Running-Code Primacy, de Lu Heng, sugiere comprobar la afirmación del fichero en sistemas que realmente operan. Reality Layers separa sintaxis, firma, estado instalado y resultado. Minimum Initial Specification ayuda a entender por qué el formato común debía ser limitado y por qué las reglas de cambio, compatibilidad y adopción debían hacerse explícitas fuera de él.

Son lentes analíticas, no una atribución sobre la autoría de RFC 3017.

El listín moderno de aquel momento resolvía una carga real. Pero el número más alto nunca fue una prueba completa de frescura.

El servidor podía afirmar que el libro era nuevo. El viaje sólo empezaba cuando la red contestaba.

Fuentes