Кратко

  • В RFC 3402 результат нетерминального правила служил ключом для получения следующего упорядоченного набора, однако новое правило снова применялось к точной Application Unique String, с которой начался процесс.
  • Инвариант разделял маршрут делегирования и идентичность предмета: каждая инстанция могла указать, где искать дальше, но не могла незаметно заменить то, что разрешалось.

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

RFC 3402 выбрал другой путь. Документ вышел в октябре 2002 года в потоке стандартов как вторая часть Dynamic Delegation Discovery System. Он описывал алгоритм позднего связывания. Приложение задавало Application Unique String, или AUS, после чего клиент по мере необходимости получал правила, переходил между объявленными базами и останавливался, когда терминальное правило выдавало ожидаемый тип результата.

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

Начальный переход задавала First Well Known Rule. Её определяло приложение, а не динамическая база. Правило строило из AUS первый допустимый ключ и тем самым привязывало начало маршрута к известному контракту. Способность произвольной базы принять удобный формат ещё не означала полномочия начинать делегирование именно там.

Запрос возвращал упорядоченный набор правил. Клиент последовательно проверял подстановки на исходной AUS до непустого результата, а затем оценивал Services, Flags и Priority. Совпадение строки, приемлемость услуги, терминальность и предпочтение были разными решениями.

Если правило совпало, но его Services не подходили клиенту, обработка продолжалась в том же наборе после отвергнутого правила. Клиент не начинал список заново и не перескакивал в постороннюю базу. Благодаря этому в доказательстве сохранялись само совпадение, причина отказа и точная позиция возобновления.

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

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

Явный переход в другой контекст был допустим. Flags могли приостановить текущее приложение DDDS и передать управление другому приложению или протокольной процедуре. Примером служил флаг p в RFC 3404. Но это было объявленное переключение системы, а не разрешение старым правилам продолжать работу с тайно подменённым субъектом.

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

Priority тоже имел узкое значение: предпочтение между в остальном эквивалентными правилами, например более быстрый или дешёвый вариант. Документ прямо исключал балансировку нагрузки. Распределение трафика относилось к другому механизму, например SRV там, где его предусматривало приложение.

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

Алгоритм поэтому зависел от двух дополнительных контрактов. Спецификация приложения определяла AUS, первое правило, допустимые базы, работу с символами и итоговый формат. Спецификация базы определяла хранение, поиск, форматы ключей и правил, вставку и предотвращение коллизий. RFC 3401 предупреждал, что чтение одного документа серии ведёт к неверному пониманию.

DDDS признавал границы знания. Время, платёж, права и состояние сделки были внешними фактами, которые нельзя вывести только из AUS и правила. Скрывать такую политику в непрозрачном результате означало приписывать алгоритму лишние полномочия. Конкретная безопасность также возникала лишь в паре приложения и базы.

RFC 3403 описывал DNS и NAPTR, RFC 3404 — URI Resolution, RFC 2916 — ранний ENUM. Это были применения общей схемы, а не доказательство универсальной поддержки. Реестр IANA ENUM Service Registrations координирует идентификаторы в более позднем применении; регистрация не доказывает исполнение, свежесть, полномочия или успех услуги.

Сейчас RFC Editor указывает одну проверенную редакционную ошибку для RFC 3402 — Errata 7049. Она исправляет ссылку на обсуждение флага p в RFC 3404 с раздела 4.4 на 4.3 и не меняет основной инвариант.

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

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

Исторический вклад RFC 3402 — сохранение идентичности при делегировании. Место поиска и ключ могли меняться многократно. Предмет, о котором отвечала каждая инстанция, оставался исходным.

Источники