Кратко

  • В SDXF у каждого блока есть идентификатор, флаги, трёхбайтовая длина и содержимое. Пример чтения в RFC 3072 игнорирует неизвестные идентификаторы и переходит к следующему блоку.
  • Это сохраняет ход разбора, но не понимание: приложению по-прежнему нужны общий смысл, преобразования, реализованные методы и право использовать значение.

В марте 2001 года Max Wildgrube описал в RFC 3072 формат Structured Data Exchange Format (SDXF) для обмена иерархическими данными между платформами. Его обещание стоит понимать точно. Документ говорит, что программа может распаковать данные SDXF, не зная значения каждого элемента. Однако пример чтения обрабатывает известные идентификаторы в switch, не задаёт ветвь по умолчанию и затем вызывает операцию перехода к следующему блоку. Неизвестное поле пропускается, разбор продолжается.

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

RFC 3072 предлагает игнорировать неизвестные ID и не полагаться на порядок блоков в прикладных протоколах на основе SDXF. Это помогает старому читателю переносить расширения. Но документ не определяет, необязательно ли расширение для транзакции отправителя, меняет ли оно трактовку приложения и повлияет ли его удаление на значимое действие. Продолжение разбора — ограниченное правило совместимости, а не всеобщее утверждение о неважности поля.

Сам формат показывает, какие договорённости остаются за границей блока. RFC 3072 нормализует двоичные значения в big-endian, предлагает ISO 8859-1 как внутреннее представление символов, допускает таблицы преобразования и отдельно определяет тип UTF-8. Сжатие и шифрование зависят от флагов, номеров методов и функций. Если используются оба, сжатие выполняется первым; для шифрования нужен ключ. Поэтому структурная граница может быть доступна, даже если у получателя нет таблицы символов, метода, его реализации или ключа для понимания содержимого.

В актуальных реестрах SDXF IANA указаны RUN-LENGTH и DEFLATE для сжатия, а AES — как метод шифрования 01. Запись подтверждает присвоение номера, но не наличие реализации у получателя и не корректное преобразование конкретного сообщения. RFC 3072 имеет статус Informational и не является стандартом Интернета; приведённые источники не доказывают внедрение или принятие. Предложение формата — не отчёт о промышленной совместимости.

Практический вывод — разделять доказательства. Длина определяет границу байтов по правилам формата; идентификатор отсылает к смыслу, заданному приложением; таблица преобразует символы; номер метода выбирает операцию, выполнение которой требует кода и ключа. Отдельная политика решает, вправе ли извлечённое значение вызвать эффект. Running-Code Primacy здесь выступает более поздней аналитической оптикой: смотреть на исполняемое поведение, а не выводить его из названия документа. Reality Layers помогает отличать символическое значение от проверяемого воздействия. Ни одна из этих идей не приписывается Wildgrube.

Источники