Resumen

  • RFC 5165 creó el espacio urn:ogc y una autoridad de nombres, pero no definió la respuesta HTTP como veredicto sobre cada identificador.
  • La política posterior de OGC diferencia nombres de categoría A, registrados como recursos discretos, y nombres de categoría X, construidos por una regla registrada y quizá sin recurso individual accesible.

Dos URL de definiciones OGC devolvieron HTTP 200 durante esta investigación. Ese resultado prueba dos respuestas en un momento concreto. No prueba que todos los nombres OGC deban comportarse igual.

La tentación de medir un sistema de identificadores con una sola sonda es comprensible. Si la cadena parece una URL, se solicita; si devuelve bytes, se declara sana. Pero OGC conserva dos esquemas de nombres persistentes y dos modelos de registro que requieren pruebas distintas.

RFC 5165, publicado como documento Informational en 2008, registró el identificador de espacio ogc. La forma urn:ogc:{OGCresource}:{ResourceSpecificString} permitía citar especificaciones, tipos de servicio y definiciones geoespaciales sin fijar el nombre a una ubicación. ONA gestionaba las clases y podía delegar subárboles delimitados.

El documento no especificó un mecanismo independiente de validación. Tampoco vinculó el espacio a un sistema de descubrimiento de resolución. Informó de un resolver operativo en aquel momento, pero una observación de 2008 no es una garantía perpetua.

La migración a HTTP no unificó todas las promesas

OGC decidió más tarde que los nuevos identificadores públicos persistentes se emitieran como URI HTTP, salvo excepción. La infraestructura web hacía posible resolverlos con mecanismos ordinarios. Sin embargo, la política de OGC-NA mantiene equivalentes URN y HTTP y advierte que la estructura visible no es la fuente normativa.

El registro decide qué se ha nombrado. El servidor decide qué representación entrega. Un patrón de caracteres puede sugerir ambos, pero no autoriza ninguno.

La política divide los nombres en dos categorías. Un nombre A designa un recurso discreto disponible desde un servicio y se registra como elemento individual. Un nombre X se genera según una regla o algoritmo; puede no estar asociado a un recurso discreto accesible. Se registra la clase y la regla.

Para A, la disponibilidad es parte de la expectativa. Para X, una aplicación puede calcular un nombre legítimo sin que exista una página separada para esa instancia. Confundir ambos produce falsos positivos y falsos incidentes: se acepta un camino no registrado porque responde, o se declara roto un nombre calculado porque no devuelve una ficha individual.

El código HTTP no contiene la cadena de autoridad

Una respuesta 200 demuestra que un servidor entregó algo. No dice si OGC-NA registró el elemento o su clase, si el emisor controlaba el subárbol, si el estado era válido, si existe un sucesor, si la representación corresponde a la versión solicitada o si el cliente interpretó correctamente el sistema de referencia.

Una redirección añade otra etapa. Puede implementar una equivalencia autorizada entre URN y HTTP o simplemente enviar al usuario a la versión más reciente. Para un visor actual, ambas opciones parecen cómodas. Para reproducir una transformación antigua, son decisiones completamente distintas.

El registro de estado resuelve parte del problema. Los elementos pueden estar enviados, válidos, reemplazados, retirados, inválidos o experimentales. Un reemplazo conserva enlaces entre predecesor y sucesor. Un retiro indica que el elemento ya no se recomienda sin afirmar que nunca existió.

Las cadenas experimentales no son nombres baratos

RFC 5165 permitía tipos experimentales no registrados y reconocía que usuarios distintos podían reutilizar el mismo valor con significados diferentes. Era una zona de prueba, no una cola informal de reservas.

Si una organización importa esas cadenas en catálogos duraderos, debe registrar también el contexto que evitaba la colisión: proyecto, emisor, fecha, regla local y transición prevista. Sin ese contexto, la aparente persistencia de la cadena amplía la ambigüedad con cada copia.

La prueba operacional debe conservar por separado el NID de IANA, la clase OGC, la autoridad delegada, el estado, la equivalencia de esquemas, la respuesta y su fecha, el contenido recibido y el resultado de la aplicación. Resolver es una etapa, no la suma de todas.

Fuentes