Кратко

  • RFC 3404 определил разрешение как типизированный запрос: I2L, I2R, I2C и I2N запрашивали местоположение, экземпляр ресурса, описание и постоянное имя; формы единственного и множественного числа сохраняли также кардинальность.
  • S, A и U задавали представление для следующего шага. P выводил обработку из DDDS в прикладную систему. Обнаружение разрешателя не удостоверяло ни его, ни возвращённое содержимое.

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

RFC 3404 вышел на стандартизационном треке в октябре 2002 года и определил приложения DDDS для разрешения URI и URN. Архитектура была разделена между пятью документами: RFC 3401 представлял семейство, RFC 3402 — алгоритм, RFC 3403 — базу правил NAPTR в DNS, RFC 3404 — приложения, а RFC 3405 — администрирование uri.arpa. и urn.arpa..

Процесс начинался со строки, уникальной для приложения. При общем разрешении абсолютный URI канонизировался и кодировался; его схема становилась первым общеизвестным ключом и дополнялась uri.arpa. для запроса DNS. В URN использовался идентификатор пространства имён и urn.arpa.. Правила NAPTR переписывали или делегировали вход до терминального результата либо передачи иной системе.

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

Тип ответа нёс Services. I2L возвращал один URI местоположения, I2Ls — один или несколько. I2R и I2Rs возвращали экземпляры ресурса. I2C выдавал описание, I2N — URN. Для последнего стандарт предупреждал, что равенство двух URN может зависеть от правил пространства имён и не сводиться к сравнению строк.

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

Кардинальность тоже входила в контракт. Строчная s в I2Ls и I2Rs разрешала множество. Сохранив лишь первый элемент, клиент добавлял собственную политику выбора. Квитанция должна фиксировать требуемую службу, единственное или множественное число, весь набор и окончательный выбор потребителя.

Перед службами мог стоять необязательный протокол. Одного названия было недостаточно. RFC 3404 требовал отдельно определить кодирование запроса и семантику ответа. Метка HTTP не говорит, как запросить описание вместо ресурса, что означает тип содержимого и как представить несколько значений.

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

Flags описывал другую ось. S, A и U были терминальными флагами DDDS. S направлял доменное имя к запросу SRV, A — к запросу адреса, U производил URI. Терминальность означала конец цикла DDDS, но не конец сетевой работы, аутентификации или проверки содержимого.

P принципиально отличался. Он объявлял дальнейшую обработку прикладной и находящейся вне понятий DDDS. Это не четвёртый терминальный формат, а граница управления. Запись P как внутреннего окончания скрыла бы переход полномочий к другой системе правил.

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

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

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

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

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

Безопасность делилась по тем же границам. Нахождение разрешателя не определяло защищённое общение с ним; это обязанность каждого протокола. uri.arpa. и urn.arpa. несли риски доступности, подмены и делегирования. Даже проверенный DNS не удостоверял автоматически прикладной ответ, ресурс или актуальность описания.

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

RFC Editor перечисляет три редакционные ошибки. Подтверждённые 282 и 787 исправляют ссылки на обработку Additional Information: они должны вести к RFC 3403, а не RFC 3404. Ошибка 2923, отложенная до обновления документа, исправляет номера ссылок в разделе 4. Ни одна не меняет флаги, типы служб или кардинальность.

Рабочая квитанция должна сохранять канонический вход, схему или пространство имён, первый ключ, DNS-запрос, полный набор NAPTR, решение по флагу, протокол, службу и кардинальность, выбор в одном ORDER, правило, переход S/A/U/P, следующий запрос или URI, кодирование запроса, удостоверенного партнёра, тип содержимого, класс объекта и потреблённый результат.

Принцип минимальной начальной спецификации Lu Heng объясняет конструкцию: точно нормировать общие границы и оставить частным протоколам локальную эволюцию. Приоритет работающего кода предлагает испытание: запросить для одной идентификации место, ресурс и описание; удалить Additional; добавить неизвестный флаг; изменить способности внутри одного ORDER. Меняться должно только разрешённое контрактом.

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

Источники