Кратко

  • RFC 3937 зарегистрировал urn:iptc, передав IPTC централизованный контроль над именами стандартов, проектов стандартов и рабочих документов.
  • Реальное позднейшее употребление URN подтверждает, что схема применялась, но не доказывает непрерывность резолвера, полноту реестра или постоянную доступность каждого ресурса.

Один документ доказывает ровно одно употребление

В спецификации IPTC Core XMP Schema присутствует явный документный URN семейства urn:iptc:std:.... Это сильное первичное свидетельство: по крайней мере один конкретный материал позднее использовал конструкцию, описанную в RFC 3937. Но граница вывода проходит именно там. Один PDF не является выгрузкой всех назначений, журналом резолвера или доказательством того, что ресурс был доступен без перерыва с 2004 года.

Текущая страница IPTC для внешнего пространства имён также показывает доступное сегодня веб-представление. Проверка настоящего времени не восстанавливает прошлое автоматически. Сервер мог меняться, URL мог переноситься, перенаправления могли исчезать и возвращаться. История постоянного имени требует временного ряда, а не одной удачной загрузки.

Запись RFC Editor относит документ к Informational, а страница errata позволяет проверить опубликованные исправления. IANA сегодня связывает iptc с RFC 3937 в реестре URN Namespaces. Эти источники подтверждают формальную регистрацию корня и документ-основание. Они не подтверждают каждое дочернее назначение и не описывают поминутную эксплуатацию службы.

Архитектура заранее разделила доказательства

RFC 1737 сформулировал функциональные требования к постоянным именам. RFC 2141 задал синтаксис URN. RFC 2276 рассматривал разрешение имён как архитектурную задачу, а RFC 3401 описал Dynamic Delegation Discovery System для некоторых приложений разрешения. RFC 3406 дал процедуру определения формального пространства имён, которой следовал RFC 3937.

Поэтому правильная последовательность символов, глобально зарегистрированный NID и работающий сетевой сервис никогда не были одним фактом. IANA зарегистрировала iptc, но не утверждала каждый urn:iptc:.... За уникальность отвечал IPTC Managing Director, а назначать имена могли только владелец пространства и уполномоченные им стороны. Семантическая действительность зависела от институционального акта, сохранённого в учётных записях IPTC.

Структура имела три верхних ветви. std относилась к ресурсам, задающим или поясняющим утверждённый стандарт; std-draft — к аналогичным материалам до утверждения; workdoc — к рабочим документам IPTC, не связанным прямо с утверждённым стандартом. Имя сообщало о статусе, но доказательство статуса всё равно опиралось на процедуру учреждения.

RFC 3085 ранее создал URN-пространство для NewsML. RFC 3937 объяснял необходимость более широкого охвата стандартов IPTC, DTD, XML Schema, пространств XML, таблиц стилей, PDF и офисных файлов, в том числе доступных вне членства. Расширение не доказывало, что все прежние NewsML-имена мигрировали или что один реестр полностью заменил другой.

Примеры в RFC — NewsML DTD, проект XML Schema NITF, пространство XML SportsML, руководства и рабочий документ — были объявлены представительными и могли не ссылаться на реальные ресурсы. Напечатанный пример подтверждал синтаксическую идею, а не факт назначения.

Обязательство существовало, сервис был будущим

IPTC заявил, что будет поддерживать доступность и постоянство всех ресурсов, обозначенных его URN. Затем RFC сообщил, что организация разработает подходящий механизм, отображающий все назначенные URN в URL для веб-разрешения. Отдельного механизма валидации не было: будущий резолвер должен был также показывать, действителен ли URN.

Будущее время не позволяет перенести позднейшее употребление назад в октябрь 2004 года. Тогда были описаны власть назначения, иерархия и обязательство по сопровождению. Сам текст не доказывал наличие общедоступного резолвера. URN идентифицирует, резолвер строит отображение, URL указывает место, сервер отдаёт представление, а проверка отвечает, было ли имя действительно назначено. Каждый слой может отказать независимо.

В ветвях стандартов можно было указывать явную версию или current. Явная версия нужна для воспроизводимости; стабильная строка с current могла менять цель вслед за актуальной редакцией. Поэтому совпадение имени во времени не гарантирует совпадения байтов. И наоборот, изменение URL не обязательно означает потерю идентичности, если отображение корректно сохранило тот же версионный ресурс.

RFC 8141 позднее обновил общий синтаксис и семантику URN. Он помогает читать современную архитектуру, но не служит ретроспективным журналом IPTC. Подход Heng Lu — отделять минимальную исходную спецификацию от последующего добровольного принятия и считать работающий код первичным операционным свидетельством — требует раздельно доказывать публикацию, назначение, реализацию, развёртывание и применение.

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