Кратко

  • Глобальное пространство RFC 3650 было федеративным: уникальное полномочие именования вместе с уникальным локальным именем давало уникальный Handle в пределах системы, а локальные пространства могли сохранить свои имена и привязки значений.
  • Global Handle Registry (GHR) в первую очередь хранил сведения о полномочиях и службах, необходимые для поиска ответственной службы Handle; Local Handle Services (LHS) обычно разрешали Handles в пределах закреплённых за ними полномочий.

Глобальное имя не требовало единого глобального хранилища

Исторический вопрос RFC 3650 касался не только формата постоянного идентификатора. Как разным пространствам имён и административным доменам пользоваться общим пространством, не передавая одному оператору все записи ресурсов? Предложенная схема разделяла имя, полномочие и поиск службы.

Handle состоит из полномочия именования — префикса — и локального имени, или суффикса. Полномочие уникально в Handle System, а локальное имя должно быть уникальным в его пределах. Вместе они делают Handle уникальным в рамках этой системы. Существующее локальное пространство имён могло присоединиться, получив уникальное полномочие и сохранив свои локальные имена и привязки значений. Значит, «глобальный» описывал общую область уникальности, а не базу данных с единым администратором. RFC 3650

Архитектура служб следовала тому же разделению. RFC 3650 помещал Global Handle Registry (GHR) на верхний уровень, а ниже располагались Local Handle Services (LHS). Handle полномочия содержал сведения о службе — её площадках и интерфейсах серверов, — чтобы клиент мог найти «домашнюю» службу. Сначала клиент запрашивал эти сведения у GHR, затем обращался к службе, отвечающей за нужный Handle. Реестр был картой ответственности служб, но не обязательно хранилищем всех локальных значений. RFC 3650 · RFC 3651

«Локальный» здесь относилось к пространству имён и административной ответственности, а не к географической близости. У LHS могли быть разные площадки по всему Интернету и несколько серверов на каждой. Репликация и распределённые площадки предусмотрены архитектурой, но это не замеренная доступность какой-либо конкретной установки.

Иерархия регистрации не была цепочкой подчинения

Полномочия именования могли образовывать дерево. Родительское полномочие требовалось зарегистрировать до дочернего, но RFC 3650 не приравнивал порядок регистрации к административному контролю: родительское и дочернее пространства могли обслуживаться разными службами и не иметь общих привилегий. Само дерево не показывает, кто вправе менять Handles дочернего пространства, разрешать споры или гарантировать непрерывную работу службы. RFC 3650

При этом GHR не был чистым указателем, который никогда не работал с отдельными Handles. RFC 3650 допускает управление GHR любым пространством Handle; RFC 3651 также разрешает ему управлять некоторыми Handles вне полномочий именования, разрешать их и администрировать. Точнее сказать, что особая роль GHR состояла в управлении Handles полномочий и сведениями об их службах, тогда как локальные службы обычно отвечали за закреплённые за ними пространства. RFC 3651

Значение, связанное с Handle, можно изменить, сохранив сам идентификатор. Это позволяет обновить местоположение ресурса или другие связанные сведения. Но формат не гарантирует постоянство: RFC 3650 связывает его с административной заботой. Стабильная строка не заставляет организацию поддерживать записи, службу разрешения или доступность цели. RFC 3650

Соседство с другими идентификаторами не означает тождества

RFC рассматривает Handle рядом с существующими системами именования, не смешивая их. DNS организует имена и разрешение посредством собственной делегации зон. Спецификации URN описывают имена, призванные идентифицировать ресурсы независимо от местоположения; поиск службы разрешения — отдельная задача. Handle может использоваться там, где нужны устойчивые имена или разрешение, но он не становится URN автоматически, а ответ Handle не доказывает доступность ресурса. RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

Важен и статус публикации. RFC 3650 имеет категорию Informational и не является интернет-стандартом. В примечании IESG сказано, что группы IETF и IRTF обсуждали систему, однако консенсуса IETF о её описанной архитектуре или месте в архитектуре идентификаторов IETF достигнуто не было. Это не одобрение и не отказ, а граница между опубликованным архитектурным предложением и институциональным консенсусом. RFC 3650

Исторический смысл проекта — в распределении функций: корневой реестр указывал, какая служба отвечает за каждое полномочие именования, а независимо администрируемые службы могли хранить и разрешать собственные локальные пространства. Но работоспособность этой схемы зависела от записей, операторов и сетевых путей, поддерживавших карту в актуальном состоянии. RFC описывает соединение этих границ, но не доказывает всеобщую разрешимость, вечное сохранение, широкое внедрение или успешный доступ к какому-либо ресурсу.

Источники: RFC 3650; RFC 3651; RFC 3652; RFC 1737; RFC 2276; RFC 3406; RFC 8141; RFC 3986; RFC 1034.