Кратко

  • RFC 2157 называла отображением преобразование в одном направлении, а эквивалентностью — два отображения, которые вместе обеспечивали преобразование без потерь.
  • Инкапсуляция могла сохранить исходный формат для последующего шлюза, не обещая, что промежуточная почтовая система поймёт или покажет тело.
  • Совпавшие байты, убедительное имя файла и успешный первый переход были частичными квитанциями; обратное правило, метаданные, пригодность и результат у получателя требовали отдельных доказательств.

Знак равенства появлялся только после двух стрелок

RFC 2157 была опубликована в январе 1998 года как спецификация тел сообщений для MIXER. RFC 2156 описывала общую стыковку X.400 с RFC 822/MIME, а документ-спутник разбирал текст, вложения, пересланные сообщения, multipart, подписанное и зашифрованное содержимое.

В глоссарии содержался способ проверки. Mapping — описание преобразования тела X.400 в тело MIME либо в обратную сторону. Equivalence — набор из двух отображений, которые вместе дают преобразование между представлениями без потерь.

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

Инкапсуляция сохраняла хранение, а не понимание

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

Контейнеры FTBP и BP15 могли сохранить MIME-тип, параметры, заголовки и канонические октеты. В обратном направлении application/x400-bp переносил расширенное тело X.400 через MIME. Это была цепочка хранения для будущего декапсулятора, а не обещание отображения, редактирования или безопасного запуска на промежуточном узле.

RFC описывала и BP14 content passing, стоявший на том же концептуальном уровне, но прямо называла его преобразованием с потерями. Заголовки удалялись, transport encoding снимался, оставался поток октетов. Обратной трансляции исходного MIME-типа не существовало; после возврата получался application/octet-stream. Материал сохранился, свидетельство типа — нет.

Имя помогало выбрать, но не становилось истиной

Поскольку оба почтовых мира продолжали меняться, спецификация разрешала шлюзу учитывать возможности получателя, просьбу отправителя, ограничения следующего участка и эвристику по содержимому или имени. Для BP14, общего FTAM-файла или application/octet-stream расширение могло подсказать преобразование.

Однако подсказка не получала полномочий. При переносе filename из Content-Disposition в FTBP pathname косые черты считались обычными символами передачи, а локальная система обязана была применять свои меры безопасности. Пример /etc/passwd показывал, что полученная строка не разрешает путь и не удостоверяет тип файла.

Особенно показательны два обязательных маршрута application/octet-stream. MIXER-совместимый продукт должен был поддерживать X.400 BilaterallyDefined, FTBP Unknown Attachment и настраиваемый выбор между ними. BP14 удалял MIME-параметры. FTBP сохранял больше файловых атрибутов и копировал байты тела в обе стороны.

Оба пути могли выдать допустимый объект, но защищали разные инварианты. Потеря padding могла изменить смысл последнего байта. Disposition игнорировался и при возврате становился attachment. Новое поле MIME могло не найти места в выбранном теле X.400. Корректность локального решения не создавала эквивалентности между разными маршрутами.

Реестр публиковал воспроизводимую пару правил

Для регистрации требовались MIME-тип, точное тело X.400, необходимые OID и ASN.1, алгоритмы и действие запретов на преобразование с потерями и без них. Описание должно было позволять независимую реализацию.

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

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

Доказательство должно сопровождать объект до возврата

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

Даже идеальный круг представления не доказывает использования. У получателя может не быть обработчика. Имя может нарушать локальные правила. Зашифрованное тело может намеренно оставаться непрозрачным. Доставка, безопасное открытие, показ и понимание человеком — последующие наблюдения.

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

RFC 2157 не обещала, что всякое тело будет понятно везде. Она сделала заявление проверяемым: одна стрелка — отображение, две замкнувшиеся без потерь — эквивалентность, а инкапсуляция честно разделяла сохранение и понимание.

Источники