Кратко

  • RFC 3458 определил необязательное поле Message-Context для ожидаемого взаимодействия с сообщением целиком, а не для обязательного перечисления присутствующих MIME-частей.
  • Ошибочный, неизвестный или устаревший контекст мог помогать локальной обработке, но не должен был срывать передачу или ухудшать представление по сравнению с сообщением без поля.

Тип носителя не объяснял способ использования

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

RFC 3458 ввёл верхнеуровневое поле, допускаемое не более одного раза. Среди исходных значений были voice-message, fax-message, pager-message, multimedia-message, text-message и none; регистр букв не имел значения, а отсутствие поля приравнивалось к none. Текст RFC, карточка RFC Editor, досье Datatracker, история, ссылки, последующие цитирования и поиск исправлений очерчивают проверяемую нормативную запись.

Получатель мог выбирать просмотрщик или значок, группировать и сортировать записи, ограничивать загрузку по узкому каналу или предлагать форму ответа. Ни одно удобство не доказывало, что в теле действительно осталось аудио, факсимильное изображение или программа.

Шлюз мог отделить происхождение от оставшегося тела

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

RFC 2822 задавал синтаксис сообщения, а RFC 2183 — disposition отдельной части. RFC 2387 и RFC 2557 описывали составные структуры; RFC 2423 давал контекст VPIM. Message-Context не отменял эти уровни.

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

Подсказка оставалась ниже границы доверия

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

RFC 3459 отдельно определял критическое содержимое MIME-частей. RFC 3938 позднее изменил политику регистрации, а RFC 3864 дал общий реестр полей. Нынешний реестр IANA подтверждает выделение имени, но не поведение конкретного клиента.

Позднейшая рамка Heng Lu о слоях реальности помогает разделить заявленный контекст и полученное тело. Приоритет работающего кода направляет внимание на MIME-дерево, преобразование и резервный показ. Минимальная начальная спецификация объясняет пользу малого необязательного поля, не поглощающего MIME и политику безопасности. Это более поздние редакционные линзы, а не свидетельство личных намерений авторов RFC.

RFC 3458 сделал контекст полезным именно потому, что не превратил его в приказ. Заголовок мог подготовить интерфейс; оставшееся тело решало, что действительно можно прочитать.

Источники