Кратко

  • RFC 2049 задал общее поведение при неизвестном типе, не требуя поддержки всех будущих subtype.
  • Неизвестные transfer encoding, charset и нетекстовые типы отступали к application/octet-stream; сырые нетекстовые байты нельзя было показывать как текст.
  • “Safe” касалось известных систем, соответствующих RFC 821/822, и защиты экрана от случайного вывода, но не удостоверяло файл, отправителя, целостность, показ или результат.

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

Новые форматы неизбежно опережают установленные клиенты. Требование знать всё устаревало бы при каждом расширении; отсутствие fallback позволило бы печатать, запускать или угадывать одни и те же байты по-разному.

RFC 2049 выбрал нижнюю границу. Агент создавал MIME-Version: 1.0, распознавал Content-Transfer-Encoding, декодировал quoted-printable и base64 и различал 7bit, 8bit и binary. Если нижний транспорт не нёс 8bit или binary, отправитель кодировал и маркировал данные. Метка описывала обратную операцию, но не доказывала её результат.

При неизвестном Content-Transfer-Encoding знакомый Content-Type не давал права интерпретировать. Вся MIME entity становилась application/octet-stream: сначала надо восстановить octet sequence, затем решать, понятен ли media type.

EID 5470 замечает, что исходная фраза грамматически приписывает Content-Type самому encoding, и предлагает добавить “MIME entity with”. Статус Held for Document Update означает зарегистрированное уточнение, а не уже заменённый текст.

Верхний тип давал лишь малую подсказку

Для text требовались показ US-ASCII и как минимум сообщение о другом charset. Неизвестный текстовый subtype можно было предложить в raw-виде только при известном charset и после canonical-to-local conversion. Неизвестный charset становился octet-stream.

Неизвестные image, audio и video subtype также отступали. Для application агент должен был снять base64 или quoted-printable и сохранить результат в файл пользователя. Хранение не было разрешением на запуск. RFC 2046 предупреждал, что общий viewer наследует опасность самого рискованного поддерживаемого формата.

Composite types имели свои пути: mixed, alternative и digest распознавались; неизвестный multipart считался mixed; message/rfc822 сохранял рекурсию; неизвестный message становился octet-stream. Полностью неизвестный Content-Type тоже превращался в octet-stream без параметров. Сохранение или выбор программы оставались локальными решениями.

“Safe” заканчивалось до действия

RFC называл правильно маркированные данные безопасными для отправки, потому что система хотя бы считала их неразличимым binary и не выплёскивала на экран пользователя, ожидавшего текст. Второй смысл: данные не ломали известные RFC-821/822-conformant systems и не ломались ими.

Непрозрачные байты всё ещё могут быть вредоносными. Handler может быть уязвим. Успешное декодирование не доказывает личность, целостность, согласие, правильный render или чтение человеком. Сообщить charset или позволить сохранить файл могло быть достаточно. Полезный отказ входил в совместимость.

Плохая MTA-практика не стала нормой

Документ признавал множество широко развёрнутых несоответствующих MTA, менявших сообщения ради локального хранения или просто ломавших их. NUL, TAB, trailing whitespace, длинные строки, неинвариантные символы, одинокая точка и начальное From могли измениться. Base64 удовлетворял наиболее переносимому алфавиту и длине строк; quoted-printable не гарантировал каждый gateway.

Но это не было рекомендацией. RFC 821 запрещал менять пробелы и переносить строки; RFC называл практики BAD и invalid. Устойчивость к реальности не превращала дефект в разрешение.

Текущая страница RFC Editor говорит Draft Standard; исторический документ — Standards Track, November 1996. Это статус текста, не перепись внедрений. Verified EID 3933 исправляет ссылку encoded-word на грамматику RFC 822 и правила RFC 2047, но не делает отображаемое слово идентичностью.

Наследием стало дисциплинированное незнание: декодировать известное, изолировать неизвестное и не называть хранение байтов пониманием.

Источники