Resumen

  • RFC 3406 afirmó que tanto la asignación de cada URN como el espacio de nombres que lo contenía debían ser procesos administrados.
  • La permanencia era una obligación de gobierno: no reasignar, declarar quién podía cambiar las reglas y preparar la continuidad cuando el custodio desapareciera.

La prueba más incómoda de un nombre persistente no ocurre mientras su organización funciona. Llega cuando esa organización se vende, se disuelve o deja de contestar. RFC 3406 llevó esa posibilidad al diseño. No encontró una métrica capaz de predecir la vida institucional, pero exigió competencia de asignación, estabilidad y una explicación sobre cómo el espacio seguiría siendo útil sin su promotor original.

El documento empezó con dos negaciones. No toda cadena con sintaxis de URN era un URN asignado. No todo NID gramaticalmente posible era un espacio reconocido. Entre el texto y la validez aparecían reglas, autoridades y un registro. Esa distancia impedía que una cadena bien formada se apropiara de una legitimidad inexistente.

La política de 2002 ofrecía tres categorías. X-<NID> servía para experimentos internos sin registro ni prevención de colisiones. Los espacios informales sí eran plenos, aunque IANA les daba un identificador numérico urn-<número>. Los formales podían solicitar una palabra concreta mediante consenso IETF y un RFC. La diferencia estaba en el procedimiento y la publicidad del compromiso, no en una licencia para rebajar la unicidad.

La plantilla obligaba a describir mucho más que una gramática. Identificaba al registrante, la versión, las autoridades de asignación, las garantías de unicidad, la persistencia, las equivalencias, la validación, la resolución y el alcance. Era un mapa de control. Permitía preguntar quién emitía nombres, quién podía interpretar componentes y quién estaba autorizado a actualizar la declaración.

La regla de no reasignación protegía el pasado. Si una persona dejaba de ser cliente o el objeto desaparecía, su URN no quedaba libre para otra cosa. La falta de resolución podía ser un resultado sincero. Reutilizar el nombre para producir una respuesta exitosa era peor: convertía referencias antiguas en afirmaciones falsas sobre un objeto nuevo.

Por eso resolución y validación no eran sinónimos. Crear un espacio no lo registraba automáticamente en el directorio global de resolución. Llegar a un servicio tampoco demostraba que el identificador consultado hubiese sido asignado correctamente. La validación podía usar otro mecanismo. El registro de IANA demostraba que existía una definición reconocida; no demostraba todos los hechos que ocurrían dentro de ella.

Para un NID formal, el proponente debía explicar la necesidad y el beneficio comunitario. RFC 3406 aceptaba que dos espacios cumplieran una función parecida. El examen era un registro de diligencia, no un monopolio. También pedía que el público de Internet pudiera usar el espacio aunque la asignación dependiera de una organización privada o de pago.

Las actualizaciones estaban limitadas por la deuda histórica. Se podían aclarar reglas o ampliar la lista de asignadores, pero cambiar la equivalencia de identificadores ya emitidos podía alterar su significado. Cada versión debía dejar rastro. La sucesión no autorizaba al nuevo custodio a reescribir el pasado.

RFC 8141 sustituyó este régimen con cambios reveladores. Pasó el registro formal ordinario de IETF Review a Expert Review, reconoció una vía para organismos científicos y de normalización externos y simplificó la plantilla. Eliminó los espacios experimentales X-: como nunca estuvieron administrados, sus cadenas no eran URN válidos. Para experimentar quedaba el espacio registrado example.

Así, la persistencia no residía en una cadena inmóvil. Era una secuencia de recibos: definición reconocida, asignación no reciclada, custodia vigente, posible validación, resolución independiente y resultado observable. RFC 3406 convirtió la sucesión en parte de la ingeniería de nombres.

Fuentes