Кратко

  • Устаревающий вариант представлял собой Extended Body Part без параметров, с OCTET STRING и OID mime-postscript-body; рекомендуемый FTAM-вариант задавался через id-mime-ftbp-postscript в application-reference.
  • Для обоих отображений в application/postscript RFC указывал отсутствие преобразования. Это относилось к потоку октетов, а не к совместимости носителя, внедрению рекомендации, политике интерпретатора или видимому результату.

В архив поступили два контейнера с одинаковым содержимым. Контрольные суммы совпали, но замки различались. Такой архив не может объявить оба контейнера взаимозаменяемыми, пока не проверит инструменты получателя.

Эта простая граница лежит в основе RFC 2160, опубликованного в январе 1998 года. Документ связывал PostScript в X.400 и MIME, сохраняя старое представление и одновременно указывая предпочтительное направление миграции.

Где находилась идентичность

Старый путь пришёл из RFC 1494. Extended Body Part не имела параметров; данные задавались как OCTET STRING, а mime-postscript-body имел OID под { mixer-bp-data 2 }. Переход к application/postscript назывался Byte Copy.

FTAM Body Part распознавалась иначе: поле FileTransferParameters.environment.application-reference содержало id-mime-ftbp-postscript с OID { mixer-bp-data 6 }.

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

RFC 2157 рассматривает Extended Body Part и FTAM как отдельные типы. RFC 2156 задаёт более широкий контекст MIXER: согласованность шлюзов, недопущение потери информации и обратимость, где она возможна. Это проектные ориентиры, а не доказательства работы конкретного маршрута.

Узкий смысл отсутствия преобразования

В обеих таблицах RFC 2160 указано Conversion Type: No conversion. Причина: каждая сторона содержит один поток октетов, который можно скопировать напрямую.

Совпавшие хэши до и после шлюза надёжно показывают, что payload не переписан. Но представление всё же изменено: объект X.400 стал MIME media type, а исходный объект X.400 имел одну из двух различных форм.

Если архив сохраняет только извлечённый PostScript, он теряет свидетельство о носителе. Позднее нельзя будет установить, пришёл ли документ как FTAM, как EBP или после незаметного fallback.

Правильный тип не обещает правильную страницу

RFC 2160 ссылался на RFC 1521. В RFC 2046 application/postscript означает программу PostScript, а соглашения DSC настоятельно рекомендуются для совместимости. Без структуры система не всегда может определить, сработает ли документ, и вправе отказаться от обработки.

Исполнение несёт отдельные риски: операции с файлами, постоянное состояние интерпретатора, системные параметры, нестандартные расширения и неограниченное потребление ресурсов. Безопасный клиент может заблокировать операторы или весь документ. Целостность байтов и отсутствие вывода в таком случае одинаково верны.

Карточка RFC Editor и карточка Datatracker подтверждают статус документа. Текущий поиск errata не показывает совпадений. Эти сведения ничего не говорят о поддержке конкретного продукта.

Пять независимых квитанций

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

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

RFC 2160 аккуратно решил задачу копирования содержимого. Инженерная ошибка начинается там, где это решение превращают в универсальную отметку совместимости. Неизменные байты — точное, но ограниченное доказательство.

Источники