Кратко

  • iMIP определил упаковку объекта календаря iTIP в MIME-сообщение, не приписывая полям обычного почтового заголовка смысл календарной роли.
  • Читаемый текст помогал человеку понять приглашение, но не становился второй, альтернативной версией встречи.

Письмо было транспортом, а не календарём

Поле «От» сообщает почтовой системе, кто отправил сообщение. Оно не обязано говорить, кто управляет событием. В 1998 году RFC 2447, или iMIP, задал правила передачи сообщений iTIP через электронную почту. iCalendar описывает объект календаря, iTIP — операции обмена, MIME — структуру частей сообщения, а SMTP переносит его дальше. Это четыре связанные, но разные функции.

Внутри MIME для календарного объекта использовался тип text/calendar. Внешний параметр method должен был совпадать с внутренним свойством METHOD. Внешний слой помогает распознать вид содержимого; внутренний объект остаётся источником календарных данных. Если в письме передавались несколько объектов с разными методами, каждый из них следовало помещать в отдельную часть text/calendar, а части объединять как multipart/mixed. Иначе разные операции могли оказаться спрессованы в одно неразличимое тело.

Два представления для разных программ

Не всякий почтовый клиент умел обрабатывать объект iCalendar. MIME позволял вложить рядом с ним обычный текст: программа без календарной поддержки могла показать дату, место и краткое описание, а календарный клиент — разобрать структурированную часть. multipart/alternative предназначался для двух способов показать одно и то же приглашение.

Это не означает, что в одной такой структуре можно предлагать две разные встречи. Если две части содержат VEVENT с разным временем начала, читатель не знает, нужно ли выбрать вариант или перед ним ошибка. Изменение времени относится к операции iTIP; MIME отвечает лишь за представление и упаковку. Граница важна, потому что именно текстовая часть может быть видна человеку первой, хотя календарная обработка должна опираться на структурированный объект.

Транспортные ограничения влияют и на символы. Если календарь содержит знаки за пределами US-ASCII, требуется указать набор символов; для передачи данных, которые конкретный почтовый путь не переносит напрямую, применяются кодировки MIME. RFC 6047 в 2010 году заменил RFC 2447 и обновил привязку для более позднего формата сообщений и S/MIME. Эти требования помогают сохранить читаемость байтов, но не подтверждают фактическую доставку или сохранение события в приложении.

Календарный объект также может ссылаться на вложение через Content-ID или Message-ID. RFC 2447 рекомендовал включать связанные части MIME в тот же пакет, если это возможно: у получателя может не быть доступа или разрешения на внешнее хранилище. Идентификатор не является самим документом и не предоставляет право его открыть.

Отправитель письма может отличаться от Organizer: участник способен переслать объект, а почтовая программа не обязана переносить календарную роль в Reply-To. Поэтому RFC 2447 указывает проверять ORGANIZER и ATTENDEE в text/calendar, а не угадывать их по заголовку. Для аутентификации и конфиденциальности RFC 2447 описывал MIME security multiparts; RFC 6047 позже потребовал аутентификацию S/MIME. Действительная подпись относится к защищённому содержимому. Она не доказывает, что сообщение дошло, что клиент его обработал или что человек согласился прийти.

RFC 2447 вышел в ноябре 1998 года как документ Standards Track и был заменён RFC 6047 в 2010 году. Эта последовательность показывает, как обновлялась почтовая привязка, но не говорит о распространённости календарных продуктов. Исторический смысл стандарта — в разделении: объект хранит смысл расписания, MIME задаёт его упаковку, почта передаёт сообщение. Доставленный пакет — ещё не сохранённый термин.

Источники