Кратко

  • RFC 3017 помещал в XML не только номера POP, но и сценарий набора, тип линии, туннель, DNS, proxy, gateway и правила изменения имени пользователя — данные, способные управлять клиентом.
  • Растущие версии книги и записи были сигналами изменения в известной области. Они не удостоверяли издателя, правильную базу, атомарное применение, текущую доступность POP или итоговую связь пользователя.

У клиента было две книги: 41 и 73. При обычном сравнении вторая выглядела новее. Но одна могла быть полной книгой консорциума, другая — выпуском для особой группы, а третья линия могла возникнуть после локальной выборки только одной страны.

RFC 3017 прямо допускал разные версии для разных пользователей и создание подмножеств. Имя phoneBook было произвольной строкой. Поэтому число приобретало смысл только вместе с издателем, названием, аудиторией и базой.

Документ вышел в декабре 2000 года, когда роуминг часто означал местный dial-up через партнёра. Целью был компактный, расширяемый и переносимый формат, пригодный для автоматической обработки разными устройствами.

В книге находились телефон, media, скорость, свойства, tunnel, dialScript, цена, место, support, provider, DNS, почтовые серверы, proxy, gateway, prefix и suffix имени. Это был не пассивный каталог, а пакет конфигурации.

Общая книга оставалась собранием чужих утверждений

Провайдеры передавали сведения о POP консорциуму, тот собирал единый выпуск. RFC 2194 показывает предысторию: участники одной roaming-системы сообщали номера секретариату; тот вручную составлял книгу и публиковал обновления через FTP, web и клиент. В данных были proxy, dialer configuration и server settings.

Это не доказывает внедрение RFC 3017. Это показывает цепочку происхождения. Между оператором и путешественником стояли компиляция, фильтрация и распространение. Единая грамматика не делала все эти наблюдения одновременными.

Версия указывала на различие, но не описывала переход

phoneBook@version должен был расти при изменении. Сервер мог сравнить число клиента и, например, вернуть URL с различиями.

Формат различий и операция применения не определялись. Не было транспортного протокола, привязки к base, atomic commit, rollback, подтверждения или tombstone. RFC заранее исключил update/transfer protocol из своего scope.

RFC 2477 отдельно потребовал от такого протокола аутентифицировать сервер, обновлять с любой старой версии, проверять integrity до применения и после формирования новой книги, оставаться лёгким и учитывать язык и charset.

Значит, 73 могло быть заявлением сервера, но не доказательством active state клиента. Получение файла не означало успешную валидацию; валидация не означала commit; commit не означал соединение.

pop@entryVersion тоже был лишь инструментом. У pop не было XML ID, тогда как setup, support и provider имели ID и ссылки. При смене номера внешняя логика должна была решить, это изменение того же POP, замена или добавление. Исчезновение могло означать удаление, фильтр аудитории, неполный transfer или ошибку.

Счётчик не создавал identity и conflict rules вокруг себя.

Валидная строка не была работающей линией

Большинство значений DTD оставались #PCDATA. Нотации FQDN и IPADR выражали предполагаемый тип, но не проверяли сеть. Отключённый номер мог быть синтаксически правильным, старый тариф — присутствовать, недоступный proxy — иметь корректное имя.

Client мог действовать по этим данным. Сценарий управлял набором, prefix и suffix меняли username, setup назначал DNS, mail, proxy и gateway. Ошибка одновременно затрагивала назначение звонка, представленную identity и последующий traffic path.

Расширения добавлялись через регистрацию, причём новые элементы должны были быть optional. Это сохраняло валидность старых документов, но не доказывало понимание новой семантики старым клиентом. Нужны были сведения о parser и implemented extension set.

Подпись не сохраняла POP во времени

RFC 3017 требовал authentication издателя и integrity распространения, оставляя security вне DTD. В качестве примера называлась PGP signature.

Правильная подпись могла связать bytes с key по заданной trust policy. Она не набирала номер, не проверяла актуальность цены, tunnel или аудитории и не показывала, что client применил правильную base.

После dial следовала authentication. RFC 2486 определял Network Access Identifier для PPP и маршрутизации запроса к home domain. Link мог подняться, а NAI быть отвергнут. Auth могла пройти, но address, tunnel, DNS или application — нет.

Нельзя было выдавать receipt одной стадии за receipt следующей.

Источники настройки могли расходиться

RFC 3017 замечал, что часть setup-значений может приходить через DHCP. Если книга и DHCP давали разные DNS, DTD не выбирал победителя. Это делали client policy и network context; telemetry должна была показать фактически используемое значение.

Для разбора требовались издатель, book name, audience, digest, book version, POP, address, entryVersion, signature, parser/DTD revision, extensions, base, commit result и active digest. Затем отдельно сохранялись dial, carrier/link, PPP, NAI, authentication, address, tunnel, DNS, proxy и application.

Только такая цепочка различала stale book, bad merge, line failure, identity rejection и service failure.

Узкая спецификация защищала границы ответственности

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

Running-Code Primacy Лу Хэна предлагает сверять опубликованную конфигурацию с работающими системами. Reality Layers разделяет документ, издателя, installed state и outcome. Minimum Initial Specification объясняет пользу тонкого общего слоя и необходимость явно определить transition, compatibility и local validation в другом месте.

Это аналитические рамки, а не утверждение об участии Лу Хэна в RFC 3017.

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

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

Источники