Resumen

  • El espacio global de RFC 3650 era federado: una autoridad única y un nombre local único producían un Handle único dentro del sistema, mientras los espacios locales podían conservar sus nombres y asociaciones de valores.
  • El Global Handle Registry (GHR) ofrecía principalmente la información de servicio necesaria para localizar al servicio Handle responsable; los Local Handle Services (LHS) resolvían normalmente los Handles de sus autoridades.

Un nombre global no exigía una base de datos global

La pregunta de RFC 3650 no era solo cómo escribir un identificador persistente. Era cómo permitir que distintos dominios de nombres y administración compartieran un espacio sin entregar a un operador el control de todos los registros de recursos. La propuesta separó nombre, autoridad y descubrimiento del servicio.

Un Handle combina una autoridad de nombres —el prefijo— con un nombre local o sufijo. La autoridad es única dentro del sistema Handle y el nombre local debe ser único bajo ella. Juntos hacen que el Handle sea único en ese sistema. Un espacio de nombres existente podía incorporarse obteniendo una autoridad propia y conservar sus nombres locales y asociaciones de valores. «Global» describía el contexto común de unicidad, no una base de datos sometida a una sola administración. RFC 3650

La arquitectura de servicios reflejaba esa separación. RFC 3650 colocó el Global Handle Registry (GHR) en la raíz y los Local Handle Services (LHS) por debajo. El Handle de una autoridad incluía información de servicio —sitios e interfaces de servidor— para que el cliente encontrara el servicio «de origen» de esa autoridad. Primero consultaba el GHR por esos datos y después contactaba con el servicio responsable del Handle solicitado. El registro funcionaba como mapa de responsabilidad del servicio; no tenía por qué ser el almacén de todos los valores locales. RFC 3650 · RFC 3651

«Local» se refería a la responsabilidad sobre un espacio de nombres y su administración, no a la proximidad física. Un LHS podía operar desde varios sitios distribuidos por Internet, cada uno con distintos servidores. La replicación entre sitios era una posibilidad arquitectónica, no una medición de disponibilidad de un despliegue concreto.

El árbol de registro no era una cadena de mando

Las autoridades podían organizarse jerárquicamente. El padre debía registrarse antes de crear un hijo, pero RFC 3650 deja claro que ese orden no establece por sí mismo una relación administrativa: los espacios padre e hijo podían servirse desde sistemas distintos y no compartir privilegios. El árbol no determina quién puede modificar los Handles del hijo, resolver una disputa ni garantizar que continúe el servicio. RFC 3650

El GHR tampoco era un directorio incapaz de tratar Handles individuales. RFC 3650 dice que podía administrar cualquier espacio Handle, y RFC 3651 permite que gestione, resuelva o administre Handles que no sean autoridades de nombres. La afirmación precisa es otra: el papel distintivo del GHR era gestionar Handles de autoridades y sus datos de servicio; los servicios locales solían responder por los espacios que se les asignaban. RFC 3651

El valor asociado a un Handle podía cambiar sin cambiar el identificador, lo que permitía actualizar una ubicación u otra información del recurso. Sin embargo, la sintaxis no garantizaba la permanencia: RFC 3650 la hacía depender del cuidado administrativo. Una cadena estable no obliga a una institución a mantener sus registros, conservar un resolvedor o mantener accesible el destino. RFC 3650

Relacionado con otros identificadores, pero no equivalente

La RFC situó Handle junto a sistemas conocidos sin confundirlos. DNS organiza nombres y resolución mediante su propia delegación por zonas. El trabajo sobre URN define nombres concebidos para identificar recursos al margen de su ubicación, mientras que los mecanismos para descubrir y resolver esos nombres son otra cuestión. Handle podía servir a aplicaciones que necesitaban nombres persistentes o resolución, pero no era automáticamente una URN; una respuesta Handle tampoco probaba que el recurso se pudiera alcanzar. RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

También importa el estado de publicación. RFC 3650 es informativa, no un estándar de Internet. La nota del IESG dice que los grupos de IETF e IRTF habían debatido el sistema, pero que no se alcanzó consenso del IETF sobre la arquitectura descrita ni sobre su lugar en la arquitectura de identificadores del IETF. No es un respaldo ni un rechazo: marca la diferencia entre una propuesta publicada y un consenso institucional. RFC 3650

La aportación histórica fue repartir funciones: el registro raíz indicaba qué servicio atendía cada autoridad y servicios administrados por separado podían alojar y resolver espacios locales. La promesa dependía de que los registros, operadores y rutas de servicio que componían ese mapa siguieran funcionando. La RFC explica cómo encajan esos límites; no demuestra resolución universal, permanencia, adopción a gran escala ni acceso efectivo a un recurso concreto.

Fuentes: RFC 3650; RFC 3651; RFC 3652; RFC 1737; RFC 2276; RFC 3406; RFC 8141; RFC 3986; RFC 1034.