Resumen

  • RFC 2056 definió dos esquemas con intenciones distintas: z39.50s para iniciar o reutilizar una sesión Z39.50 y z39.50r para recuperar un registro mediante una búsqueda rigurosamente construida.
  • La URL no fundía todas las capas en una identidad única: servidor, base de datos, docid, elementos lógicos, sintaxis de representación y entrega seguían siendo decisiones separadas.
  • Su situación documental actual y su inscripción registral describen documentos y asignaciones; por sí solas no demuestran despliegue, tráfico, soporte operativo ni vigencia de un objeto concreto.

RFC 2056 apareció en noviembre de 1996 como Proposed Standard dentro de Standards Track. En los metadatos públicos consultados figura hoy en el flujo Legacy, sin una relación explícita de actualización u obsolescencia recogida en esos datos. Esa información permite situar el documento; no permite convertir su estado documental en una afirmación sobre uso presente. La distinción importa especialmente aquí porque el RFC trataba de representar mediante URL operaciones de Z39.50, un protocolo cuya interacción general podía conservar estado, desarrollarse en varios pasos y detenerse a la espera de parámetros.

La participación visible del usuario dependía además del cliente.

Dos esquemas para dos intenciones

La decisión central de RFC 2056 fue disponer de dos esquemas antes de la parte opaca de la URL. Así, la interfaz podía conocer la intención general sin tener que deducirla de campos posteriores.

En z39.50s, el servidor es obligatorio y el puerto es opcional, con 210 como valor predeterminado; el resto puede omitirse. La acción consiste en iniciar una sesión con ese servidor y puerto, o reutilizar una ya existente con el mismo par. Si aparece docid, también debe existir una base de datos y el cliente realiza una búsqueda orientada a recuperación. Si docid no aparece, otros parámetros pueden funcionar, según el cliente, como requisitos, preferencias o indicaciones que este ignore. Después de la operación, la sesión queda abierta para que el usuario pueda continuar.

z39.50r expresa una intención más estrecha. Requiere servidor y base de datos, mantiene 210 como puerto predeterminado y deja sin definir el significado de una URL que no contenga docid. Ese identificador es opaco y lo define el servidor. El cliente lo convierte en un único término dentro de una consulta Type-1 de formato general, con etiqueta 45 y los atributos Bib-1 Use=docid y Structure=URx. La operación Search debe producir un recuento exactamente igual a uno. Si no es así, la búsqueda se considera fallida y el comportamiento posterior de la aplicación queda sin definir.

Si el registro único viene incluido en Search Response, puede entregarse desde ahí; de lo contrario se obtiene mediante Present. Una vez recibido, el cliente puede cerrar la sesión o conservarla. El RFC no autoriza una selección aproximada entre varios resultados ni una elección arbitraria. La unicidad forma parte del mecanismo, no es una preferencia estética de la interfaz.

Lo que ocurre entre el localizador y los bytes entregados

Ese recorrido revela una propiedad importante de Z39.50: Search crea en el servidor punteros hacia registros de la base de datos. Por eso una URL de recuperación no equivale simplemente a una dirección física de un objeto. El servidor interpreta una consulta, localiza un registro y luego intervienen otras elecciones antes de que exista una representación entregable.

RFC 2056 mantiene separados al menos tres conceptos que sería fácil confundir: el registro local de una base de datos, el registro abstracto compartido entre sistemas y el registro exportado para su recuperación. elementset selecciona los elementos lógicos que interesan; recordsyntax determina cómo se empaquetan esos elementos para el intercambio. Elegir campos y elegir una sintaxis de representación son, por tanto, operaciones distintas.

La misma separación aparece en los parámetros. Si esn no se suministra, el cliente elige. Si se suministra, puede emplearse en Search, mediante los nombres de conjuntos de elementos para resultados pequeños o medianos, o posteriormente en Present. Si rs falta, también decide el cliente. Cuando hay una lista, la preferencia es usar como PreferredRecordSyntax la primera sintaxis de la lista que el cliente admita.

La gramática formal conserva estas distinciones. Las bases de datos se separan con +; puede seguir un ?docid; después aparecen los parámetros opcionales ;esn= y un único parámetro ;rs=, dentro del cual varias sintaxis de registro se separan también mediante +. No se trata de repetir ;rs= para cada sintaxis. RFC 2056 se apoya además en la gramática común de URL de RFC 1738.

Esta arquitectura tenía un trasfondo de interoperabilidad más amplio. RFC 1729 había documentado problemas de interoperabilidad en la representación de información entre implementaciones Z39.50. En ese contexto, distinguir el contenido lógico solicitado de la sintaxis con la que se transporta no era una sutileza terminológica: era una frontera entre capas que podían evolucionar o fallar de manera diferente.

Una comparación que aclara lo que RFC 2056 no era

RFC 1625 ofrece un contraste útil a través de WAIS. Allí se utilizaba una consulta de texto Type-3 y se eliminaban resultados para lograr un tratamiento sin conservación de estado y prescindir de Present. Esa estrategia no debe trasladarse retrospectivamente a RFC 2056. Los dos documentos describen mecanismos diferentes para relacionar búsqueda, resultados y recuperación.

La comparación ayuda a ver por qué la continuidad de sesión de z39.50s era significativa. Una consulta Z39.50 general podía ser una conversación: el cliente podía necesitar parámetros adicionales, el servidor mantenía resultados y la persona podía seguir interactuando. En z39.50r, en cambio, la construcción prescrita de la consulta y la exigencia de un único resultado reducían el espacio de decisión para expresar una recuperación concreta. Reducir ese espacio no convertía, sin embargo, el identificador en una prueba universal de identidad.

Qué puede afirmar realmente una URL

Una URL de estos esquemas permite observar componentes distintos: esquema, punto de conexión, base de datos, token opaco, construcción de consulta, recuento único cuando corresponde, selección de campos y sintaxis, y finalmente entrega. Ninguna de esas observaciones, aislada o combinada mecánicamente, demuestra por sí sola que dos representaciones sean el mismo objeto en sentido permanente, que una autorización continúe vigente, que el objeto no haya sido sustituido, que sus datos bibliográficos sean correctos o completos, que cualquier analizador sea seguro, que una sesión siga viva o que el usuario haya obtenido el resultado esperado.

Esto no es una deficiencia accidental de la URL. Es consecuencia de que el localizador atraviesa sistemas con estado, decisiones locales y representaciones negociadas. El docid de z39.50r, por ejemplo, es definido por el servidor. Su opacidad impide tratar su forma textual como una semántica independiente de ese servidor y esa base de datos.

Seguridad y permanencia documental

RFC 2056 incluye además dos advertencias que rompen una lectura ingenua de la recuperación. Un localizador puede dejar de señalar el elemento que se pretendía localizar. Y una operación que desde fuera parezca una recuperación inocua e idempotente puede desencadenar una operación remota dañina. La sintaxis de un localizador no certifica, por tanto, ni la permanencia del referente ni la inocuidad de toda ejecución que provoque.

El registro de esquemas URI de IANA mantiene actualmente z39.50s y z39.50r con estado Permanent, mientras que z39.50 figura como Historical. Es una observación registral. No cuantifica tráfico, no acredita soporte en clientes o servidores actuales y no constituye un aval operativo. Del mismo modo, la ficha del RFC, Datatracker y la consulta de erratas sirven para reconstruir su situación documental, no para inferir despliegue contemporáneo.

Fuentes