Подтип 'message/partial'
Этот подтип определен с целью обеспечения возможности пересылки очень больших объектов в виде нескольких раздельных частей, автоматичски "склеиваемых" почтовой программой получателя. Этот механизм может пригодиться, когда промежуточные почтовые шлюзы ограничивают индивидуальный размер пересылаемых писем. Т.о., этот подтип говорит о том, что письмо содержит лишь часть большого послания.
Для этого подтипа необходимо указание трех параметров:
- "id" - уникальный идентификатор, позволяющий обнаружить остальные части послания.
- "number" - целое число, означающее номер части послания.
- "total" - целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.
- Все поля заголовка части 1, кроме начинающихся с "Content-" и специальных "Message-ID", "Encrypted" и "MIME-Version" должны быть скопированы в заголовок нового (общего) письма.
- Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с "Content-", а также поля "Message-ID", "Encrypted" и "MIME-Version", должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.
- Заголовки второй и последующих частей целиком игнорируются.
Пример: часть 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-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем "внутреннее" письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.
При "сборке" таких посланий в пункте назначения должны учитываться следующие правила:
Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: <id1@host.com> 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: <anotherid@foo.com> 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: <id2@host.com> 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: <anotherid@foo.com> 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.
