Кратко

  • RFC 5328 регистрирует пространство dvb, но конкретные имена назначаются процессом стандартизации DVB и уполномоченными им сторонами. Синтаксический пример, зарегистрированный NID и реальное назначение — разные факты.
  • Членство в каталоге подтверждает действительность имени в этой системе. Оно не подтверждает доступность пути разрешения, подлинность возвращённого ресурса, поддержку формата или результат использования.

Документ породил ложный актив

Сканер извлёк строку из раздела Examples. Парсер подтвердил форму urn:dvb:<NSS>, IANA подтвердила NID, и платформа добавила запись в инвентарь. Затем монитор стал сообщать об «ошибке разрешения» объекта, которого никто не назначал.

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

До инвентаризации нужны доказательства назначающей власти и каталога. До мониторинга — ещё область ответственности, разрешающая authority и законный канал наблюдения.

Регистрация пространства не заполняет его

IANA хранит строку dvb в реестре URN Namespaces и указывает управляющие RFC. Это доказывает существование координаты пространства имён.

RFC 5328 отдаёт назначение индивидуальных URN процессу разработки стандартов DVB. DVB может делегировать части пространства другим сторонам под своим режимом. Следовательно, корректная строка не предъявляет собственное поручение на назначение.

RFC 8141 позднее формулирует это как общее правило: синтаксически правильного urn: недостаточно. NID должен быть зарегистрирован, а assigned-name — создан по правилам пространства.

Receipt должен содержать исходные октеты, нормализованную форму, версию NID registry, правила DVB, assigner, delegation, каталог, его версию и результат membership.

Каталог закрывает только вопрос назначения

RFC 5328 не задаёт встроенного механизма валидации. DVB должна поддерживать URN catalogues; присутствие имени в каталоге означает его действительность.

Это не слабое правило, а правило с ограниченной областью. Оно не сообщает, доступен ли resolver конкретному приёмнику, использует ли resolver ту же версию каталога, достижим ли locator и подлинен ли ресурс.

Новая версия каталога может уже существовать, а broadcast carousel всё ещё повторять старый Resolution Record. IP resolver может держать иной cache epoch. Оба признают имя действительным, но возвращают разные места.

Поэтому отдельно сохраняются publisher, authority, версия и время каталога, время проверки и membership. Путь разрешения начинается следующим receipt.

Постоянство не обещает непрерывный endpoint

DVB обязуется не переназначать выданную строку и поддерживать доступность и постоянство официально именованных ресурсов.

Это институциональная дисциплина идентификатора, а не непрерывный замер DNS, multicast, HTTP или broadcast. Location-independent имя должно переживать смену местоположения. Старый endpoint может исчезнуть, а имя продолжит действовать через новые resolution data.

Обратное тоже важно: действующее имя не означает, что каждый путь доступен сейчас. Отказ одного пути описывает путь, а не автоматически отменяет URN.

Статусы имени, каталога, resolver path и resource access имеют разные часы.

Приёмники видят разные сети

RFC 5328 не выбирает единственный resolution/delegation mechanism, потому что устройства имеют разные средства доступа.

Broadcast set-top box с односторонним приёмом должен получить resolution information из service discovery в потоке. Домашнее сетевое устройство может пользоваться IP через gateway. Успех второго ничего не говорит о первом.

Документ описывает циклические RAR и RR в цифровом вещании, циклические multicast RR через DVBSTP и unicast RR в ответ на GET /dvb/sdns.

Центральная HTTP-проверка не наблюдает broadcast carousel. Multicast capture не доказывает join другого сегмента. Полученный RR ещё не доказывает получение ресурса.

Нужны receiver class, channel, record version, first-seen time, cycle и cache age. Общий resolved стирает место отказа.

Bootstrap ещё не resolution

Сначала client ищет Service Discovery and Selection entry point. RFC описывает dvbservdsc, TCP или UDP, порт 3937, зарегистрированные multicast addresses и DNS SRV под services.dvb.org для нестандартных точек.

IANA assignment подтверждает значение имени или номера, но не listener. Зарегистрированный multicast address не подтверждает route, membership или packet reception. SRV answer указывает target, но не его доступность, authority или свежесть RR.

Bootstrap receipt заканчивается способом поиска, ответом, target и временем. Затем следуют соединение, выбор Resolution Authority, Resolution Record и locator.

RFC 8553 позже согласовал underscored DNS names, используемые RFC 5328 и другими документами, с единым IANA registry model. Зарегистрированное _dvbservdsc не создаёт SRV RR и не запускает службу.

Регистр букв не равен содержимому

RFC 5328 объявляет NSS case-insensitive. Два написания могут сравниваться как одно имя.

Из этого не следует равенство resolver response, каталожной проекции, locator или content. Для расследования сохраняют literal input и normalized form, а затем отдельно сравнивают authority epoch, cache age, locator set и content hash.

Если эквивалентные URN дали разные ресурсы, одинаковое имя — точка соединения расследования, а не доказательство одинакового результата.

Аутентификация вынесена за пределы строки

RFC 5328 говорит: при переводе URN в location и доступе к ресурсу может потребоваться authentication. Информацию об аутентификации имени или ресурса следует передавать отдельно вместе с URN, а не помещать внутрь URN.

Префикс dvb, catalogue hit, SRV target, правильный port, HTTP success и отображаемые bytes не образуют автоматически trust chain. Receipt называет проверяемый объект, mechanism, trust anchor, policy и время.

Последствия специальных значений, которые DVB может назначить символам NSS, также остаются вне RFC. Generic parser не вправе выводить authorization из визуальной структуры строки.

Authentic resource может быть несовместим или не разрешён приложению. Неаутентифицированный объект может успешно отрисоваться. Origin, compatibility и use — разные решения.

Обновление контакта не оживляет сервис

RFC 7354 заменил Registration Information и Declared Registrant, ввёл role-based email и оставил остальные поля RFC 5328 без изменений.

Это ограниченное административное доказательство. Оно не измеряет каталог, DNS, multicast, HTTP, broadcast или receiver. Использовать дату контакта как uptime — значит приписать реестру наблюдение, которого он не выполнял.

Свежий контакт и недоступный resolver могут существовать одновременно. Доступный resolver и устаревший контакт — тоже. Исправления и ответственные у этих состояний разные.

Даже реальный ресурс не заканчивает цепочку

Resolution может вернуть locator, metadata или representation. Далее идут retrieval, authentication, freshness, parsing, transformation, rendering, application authorization и outcome.

Разнообразие устройств делает промежуток существенным. Web representation может потребовать преобразования для другого терминала. Правильные metadata могут описывать недоступный content. Показанный экран не доказывает завершённое интерактивное действие.

Content hash, parser result, renderer result и application outcome не дают транспортному ответу стать доказательством услуги.

Минимальный receipt

Сохранить literal и normalized URN; NID registry; правила DVB; assigner и delegation; идентичность, версию и membership каталога; receiver class; channel; bootstrap; наблюдения RAR/RR/DVBSTP/HTTP/DNS; выбранную authority; locators; внешнюю authentication; content hash и freshness; parser, renderer, authorization и outcome.

URN связывает записи. Он не заменяет ни одну из них.

Источники