Протоколы Internet


Многоцелевое расширение почты Интернет (MIME) - часть 40


5.2.1. Субтип RFC822

Тип среды "message/rfc822" указывает, что тело содержит инкапсулированное сообщение. Однако в отличие от сообщений верхнего уровня RFC-822, ограничение, связанное с обязательным присутствием в теле "message/rfc822" заголовков "From", "Date", и, по крайней мере, одного адреса места назначения, здесь удалено. Необходимо лишь присутствие одного из заголовков "From", "Subject" или "Date". Следует заметить, что, несмотря на использование чисел "822", объект "message/rfc822" не должен абсолютно следовать регламентациям RFC-822. Более того, сообщение "message/rfc822" может быть статьей новостей или сообщением MIME.

В теле объекта "message/rfc822" не разрешены никакие кодировки помимо "7bit", "8bit" или "binary". Поля заголовка сообщения содержат только US-ASCII в любом регистре, а информация в теле может быть закодирована. Не-US-ASCII-текст в заголовках инкапсулированного сообщения может быть специфицирован с использованием механизма, описанного в документе RFC-2047.

5.2.2. Субтип Partial

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

Так как данные типа "message" могут не быть закодированны в виде base64 или закавыченной строки печатных символов, может возникнуть проблема, если объекты "message/partial" созданы в среде, которая поддерживает двоичный или 8-битовый обмен. Проблема возникает из-за того, что двоичные данные надо будет разбить на несколько сообщений "message/partial", каждое из которых требует двоичного транспорта. Если такие сообщения встретят по пути шлюз с 7-битовой передачей, не будет никакой возможности перекодировать эти фрагменты для 7-битовой среды. Можно конечно дождаться прихода всех составных частей, собрать исходный объект, закодировать его с помощью, например, base64, после чего начать все с начала. Но даже такой сложный сценарий может оказаться неосуществимым из-за того, что фрагменты могут транспортироваться разными путями. По этой причине, было специфицировано, что объекты типа "message/partial" должны всегда иметь транспортное кодирование “7bit” (по умолчанию). В частности, даже для сред, которые поддерживают двоичный или 8-битовый обмен, использование транспортного кодирования "8bit" или "binary" для MIME-объектов типа "message/partial" запрещено. Это в свою очередь предполагает, что внутреннее сообщение не должно использовать кодирование "8bit" или "binary". Так как некоторые агенты пересылки сообщений могут выбрать автоматическую фрагментацию длинных сообщений, а также из-за того, что эти агенты могут использовать разные пороги фрагментации, может так получиться, что фрагменты после сборки в свою очередь окажутся частями сообщения. Это вполне допустимо.




Начало  Назад  Вперед