Кратко

  • RFC 3043 предложила urn:pin как постоянное пространство имен для идентификации людей и организаций в разных приложениях.
  • Вне внутреннего резолвера Network Solutions структура идентификаторов оставалась непрозрачной, а резолверы компании считались авторитетными. Глобальная синтаксическая форма не делала столь же переносимым право на разрешение имени.

Вопрос состоял не просто в том, как присвоить человеку долговечную метку. Требовалось, чтобы ссылка сохранялась при смене электронной почты, фамилии, работодателя, интернет-провайдера и даже системы, впервые выдавшей имя. В опубликованной в январе 2001 года RFC 3043 Network Solutions описала эту задачу для каталогов и электронной коммерции: различать записи, даже если их описания похожи, и через годы ссылаться на того же человека или ту же организацию.

Предложением стал Personal Internet Name (PIN), выраженный в виде Uniform Resource Name в пространстве pin. В RFC приведены компактные примеры вроде urn:pin:bs4321234, а не строки с фамилией или названием компании. Специфическая для имени часть (NSS) объявлялась плоским алфавитно-цифровым пространством. Важнее другое: документ утверждал, что вне внутреннего резолвера Network Solutions структуру этой части узнать нельзя и что внешним системам не следует выводить или предполагать ее смысл. Непрозрачность задавала границу дизайна, а не предлагала расшифровывать строку.

У такого разделения было практическое преимущество. Приложение могло переносить стабильную ссылку, не встраивая изменяемый адрес электронной почты и не привязываясь к локальному ключу конкретного каталога. Согласно модели RFC, идентификаторы не должны были выдаваться повторно, а связь имени с человеком или организацией объявлялась постоянной даже после смены имени, реструктуризации компании, смерти или ликвидации. RFC 3043 также представляла стандартный механизм разрешения URN как способ для других приложений ссылаться на PIN и разрешать их открыто, без привязки к одному проприетарному приложению.

Однако регистрационная форма проводила еще одну границу: кто вправе определять значение PIN. Network Solutions присваивала идентификаторы через собственную проприетарную систему регистрации и заявляла, что та гарантирует уникальность. На тот момент алгоритм продолжал нумерацию с последнего выданного значения, прибавляя положительное целое число; документ допускал будущую смену алгоритма. Для разрешения имен он указывал URN-резолверы самой Network Solutions. Попытка обратиться к другому поставщику, предупреждала RFC, может привести к ошибкам и в любом случае не считается авторитетной.

Так возникает парадокс переносимости. Токен можно было скопировать в приложение вне исходного каталога, но внешнее приложение не могло самостоятельно вывести его структуру или заявить об авторитетной привязке лишь на основании разбора строки. Переносимость ссылки и переносимость полномочий — разные свойства. Формат легче пересекал границы организаций, чем право удостоверить человека или организацию за ним.

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

Статус документа тоже важно описывать точно. Сегодня IETF Datatracker относит RFC 3043 к информационным документам Legacy и указывает, что у него нет формального статуса в процессе стандартизации IETF. При этом действующий реестр пространств имен URN IANA по-прежнему включает pin в таблицу формальных пространств, ссылаясь на RFC 3043. Эти записи отвечают на разные вопросы: статус RFC в процессе стандартов не равен наличию пространства в реестре IANA. Ни та ни другая запись сама по себе не доказывает, что сервис работает сейчас или что имя используется сегодня.

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

Поэтому система, обещающая и долговечность, и открытость, должна определить не только формат имен, но и то, кто проверяет привязку, как полномочия переходят дальше и что сохраняется после ухода первоначального резолвера.