Кратко

  • RFC 3367 определил общий механизм запросов к службам общих имён, описания возможностей, результатов и направлений, а также происхождения от службы и набора данных.
  • Обнаружение и выбор поставщика, регистрация, владение и уникальность намеренно остались вне области. Единая форма вопроса не определяла учреждение, уполномоченное отвечать.

В конце 1990-х в адресную строку вводили не только URL. Пользователи писали названия компаний, имена людей, книг и мест, а браузеры и порталы превращали их в навигацию или поиск. Для подключения специализированных каталогов требовались разные интерфейсы.

Common Name Resolution Protocol предложил общую точку интеграции. RFC 3367 вышел в 2002 году как Proposed Standard и описал XML-сообщения для запроса заранее созданных связей между человеческой фразой и интернет-ресурсом. Это был не второй DNS и не всемирный каталог.

Общее имя не имело обязательного синтаксиса. В отличие от URI, оно не несло структуры идентификатора; в отличие от URN, его связь не обязана была быть уникальной или постоянной. Одна фраза могла присутствовать у разных служб и вести к разным записям.

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

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

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

RFC 2972 ясно провёл институциональную границу. Обнаружение и выбор поставщиков, администрирование, регистрация, владение и обеспечение уникальных имён не входили в первоначальную область. Протокол умел говорить с уже выбранной стороной, но не выбирал её.

Именно там появлялся авторитет. Браузер с коммерческим каталогом и браузер с региональной службой могли отправить одну фразу и получить разные допустимые связи. CNRP сохранял происхождение, но не объявлял одну связь глобальной истиной.

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

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

Запуск транспорта был определён точнее. Универсальные клиенты и серверы должны были поддерживать HTTP на порту 1096 для первого контакта, после чего служба могла объявить другие варианты. Это объясняло соединение с известной целью, но не её обнаружение и доверие.

Направления удлиняли граф зависимости. Служба могла вернуть часть результатов и указать другой источник. Клиенту требовалось помнить пары службы и набора данных для обнаружения циклов. Недоступная цель означала возможный частичный, а не полный успех.

Безопасность возвращалась к той же границе. RFC 3367 перечислил посредника, подделку объекта Service и отказ в обслуживании из-за нового уровня косвенности. Подпись помогала, но для проверки нужен авторитетный открытый ключ. Его получение оставалось вне области, поскольку зависело от обнаружения службы.

Криптография защищает утверждение после выбора корня доверия, но не выбирает корень. Криптографическая действительность и институциональный авторитет — разные свидетельства.

Сегодня IANA указывает go как Permanent со ссылкой на RFC 3368, а RFC 3367 остаётся Proposed Standard. Это подтверждает нормативное хранение, но не число браузеров, серверов, объём трафика или пользователей. Ожидания рынка в RFC 2972 также не являются измерением внедрения.

RFC 2396 и RFC 3986 дают общий контекст URI. RFC 2276 и RFC 2483 обсуждают разрешение вокруг URN, RFC 3401 — другую семью делегированного обнаружения. Они показывают пространство проектов, но не доказывают эксплуатационную замену одного другим.

Два эссе Lu Heng задают раскрытую аналитическую рамку. “Minimum Initial Specification” объясняет малое общее ядро и последующие локальные решения: CNRP стандартизировал обмен, а не авторитет. “On Reality Layers” разделяет соответствие, личность службы, происхождение данных, связь, доступ и намерение пользователя.

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

Историческая граница RFC 3367 проста. Интернет мог согласовать способ задать вопрос. Решение о том, кто вправе ответить, требовало другого управления, которое протокол сознательно не брал на себя.

Источники