Кратко

  • THTTP задавал простой способ кодировать запросы и ответы служб разрешения URN в HTTP 1.0 или 1.1.
  • Ответ может сообщить URL или выдать данные, но сам по себе не подтверждает назначение имени, мандат резолвера, целостность, право доступа или устойчивое получение.

Историческая ценность RFC 2169 — в ограничении роли протокола. Существующий HTTP-сервер мог получить URN и нужную службу через CGI или другое расширение. Это позволяло начать работу без развёртывания отдельного стека. N2L просил URL, N2R — названный ресурс; коды статуса, согласование представления и кэширование оставались обычными правилами HTTP.

Удобство транспорта не создаёт полномочий. RFC 2141 отделяет синтаксис и лексическое равенство URN от функционального равенства, которое определяется правилами конкретного пространства имён. RFC 2169 требовал одинакового результата для лексически равных URN, но не назначал всемирный резолвер и не превращал заголовок Location в свидетельство о праве на имя.

Поэтому HTTP-обмен нужно читать по частям. Код 200 показывает ответ выбранной точки в данный момент; перенаправление предлагает местоположение; N2R может вернуть байты. Ни один из этих фактов отдельно не доказывает, что пространство имён корректно выдало идентификатор, что делегирование ещё действует, что содержание не изменено, что клиенту разрешён доступ или что иной резолвер ответит так же.

RFC 3406 позже назвал выдачу URN управляемым процессом, а глобальное разрешение — отдельной регистрационной задачей. Реестр IANA URN Namespaces по процедурам RFC 8141 фиксирует признанные пространства имён, но не удостоверяет какой-либо HTTP-резолвер 1997 года.

RFC 2169 напоминает о полезной границе: привычный транспорт может нести вопрос о разрешении, не присваивая себе решения об управлении и хранении.

Источники и пределы доказательств

Использованы RFC 2169, 2141, 1737, 3401, 3406, 8141 и реестр IANA. Они не измеряют внедрение THTTP и не подтверждают текущие полномочия отдельной точки.