RFC: 1521
Оригинал: MIME - Multipurpose Internet Mail Extensions
Другие версии: RFC 1341, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
Категория: Проект стандарта
Дата публикации:
Авторы: ,
Перевод: Антон Воронин

7.3.2. Подтип 'message/partial'

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

Для этого подтипа необходимо указание трех параметров:

  1. "id" — уникальный идентификатор, позволяющий обнаружить остальные части послания.
  2. "number" — целое число, означающее номер части послания.
  3. "total" — целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.

Пример: часть 2 3-х частного послания имеет следующие варианты заголовка:

Content-Type: Message/Partial;
     number=2; total=3;
     id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Content-Type: Message/Partial;
     id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
     number=2

Но часть 3 обязательно должна содержать параметр "total":

Content-Type: Message/Partial;
     number=3; total=3;
     id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Необходимо заметить, что нумирация частей начинается с 1, а не с 0.

Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.

Семантика partial-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем "внутреннее" письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.

При "сборке" таких посланий в пункте назначения должны учитываться следующие правила:

  1. Все поля заголовка части 1, кроме начинающихся с "Content-" и специальных "Message-ID", "Encrypted" и "MIME-Version" должны быть скопированы в заголовок нового (общего) письма.
  2. Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с "Content-", а также поля "Message-ID", "Encrypted" и "MIME-Version", должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.
  3. Заголовки второй и последующих частей целиком игнорируются.

Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом:

   X-Weird-Header-1: Foo
   From: Bill@host.com
   To: joe@otherhost.com
   Subject: Audio mail
   Message-ID:
   MIME-Version: 1.0
   Content-type: message/partial;
        id="ABC@host.com";
        number=1; total=2

   X-Weird-Header-1: Bar
   X-Weird-Header-2: Hello
   Message-ID:
   MIME-Version: 1.0
   Content-type: audio/basic
   Content-transfer-encoding: base64

... здесь имеет место быть первая часть закодированных аудио-данных ...

А вторая может выглядеть так:

From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... здесь имеет место быть вторая часть закодированных аудио-данных ...

После того, как расколотое послание воссоздано заново для отображения получателю, оно должно выглядеть следующим образом:

   X-Weird-Header-1: Foo
   From: Bill@host.com
   To: joe@otherhost.com
   Subject: Audio mail
   Message-ID:
   MIME-Version: 1.0
   Content-type: audio/basic
   Content-transfer-encoding: base64

... первая часть закодированных аудио-данных ...
... вторая часть закодированных аудио-данных ...

Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа "message" никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде. Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим "8-бит" и "binary", запрещается их использование для данных message/partial.

Многие почтовые агенты могут автоматически фрагментировать большие письма.

Включение поля "References" в заголовки второй и последующих частей, ссылающегося на идентификатор предыдущей части, может оказаться полезным для почтовых программ, понимающих и обрабатывающих ссылки. Однако, наличие этого поля не обязательно.

Поле заголовка "Encrypted" вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.