Общение

         

Подтип 'message/partial'


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

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

  • "id" - уникальный идентификатор, позволяющий обнаружить остальные части послания.
  • "number" - целое число, означающее номер части послания.
  • "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: <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.


    Содержание раздела