Каноническая модель кодирования

Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и реализуются для каждого "внутреннего" уровня тела сообщения.

(1)	Создание локальной формы.

Тело, которое подлежит пересылке, формируется в локальном системном формате. При этом используется местный символьный набор и, где возможно, локальное кодирование завершения строки. Тело сообщения может быть текстовым файлом системы UNIX, или растровым изображением, или индексным файлом VMS, или аудио данными в системно зависимом формате, хранящимися в оперативной памяти, или что-то еще, что соответствует локальной модели представления информации.

(2)	Преобразование в каноническую форму.

Все тело, включая вспомогательную информацию, такую как длины записи или атрибуты файлов, преобразуется в универсальную каноническую форму. Специфический тип среды тела также как и его атрибуты определяют природу используемой канонической формы. Преобразование в соответствующую каноническую форму может включать в себя преобразование символьного набора, трансформацию аудио данных, компрессию или различные прочие операции, специфические для данного типа среды. Если реализуется преобразование символьного набора, следует побеспокоиться об адаптации к семантике типа среды, что может оказать существенное влияние на преобразование очень многих символьных наборов.

Например, в случае чистого текста, данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.

(3)	Применение транспортного кодирования.

Применяется подходящее для данного тела транспортное кодирование. Заметим, что не существует жесткой связи между типом среды и транспортным кодированием. В частности, может оказаться вполне приемлемым выбор base64 или закавыченных строк печатных символов.

(4)	Вставление в объект.

Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется.

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

(1)

Во многих вариантах преобразование к канонической форме предваряется некоторой трансляцией в самой кодирующей программе, которая непосредственно работает с локальным форматом. Например, локальное соглашение о разрывах строк для текста тел может реализоваться с помощью самого кодировщика, который владеет информацией о характере локального формата. (2)Выходные данные кодировщика могут проходить через один или более дополнительных ступеней прежде чем будут переданы в виде сообщения. Выход кодировщика как таковой может не согласовываться с форматами, специфицированными в RFC-822. В частности, если это окажется удобно преобразователю, разрыв линии может обозначаться каким то иным способом, а не CRLF, как этого требует стандарт RFC-822.

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

Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64

должно быть сначала представлено в форме text/foo, затем, если необходимо, представлено в символьном наборе и, наконец, трансформировано с использованием алгоритма base64 в формат, безопасный для пересылки через любые шлюзы.

Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF.

Приложение A. Сложный пример составного сообщения

Данное сообщение содержит пять частей, которые должны быть отображены последовательно: - два вводных объекта чистого текста, встроенное составное сообщение, объект типа text/enriched и завершающее инкапсулированное текстовое сообщение с символьным набором не ASCII типа. Встроенное составное сообщение в свою очередь содержит два объекта, которые должны отображаться в параллель, изображение и звуковой фрагмент.

MIME-Version: 1.0
From: Nathaniel Borenstein
To: Ned Freed
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example(составной пример)
Content-Type: multipart/mixed;boundary=unique-boundary-1

Это область преамбулы составного сообщения. Программы чтения почты, приспособленные для чтения составных сообщений, должны игнорировать эту преамбулу.

--unique-boundary-1
... Здесь размещается некоторый текст ...

[Заметим, что пробел между границей и началом текста в этой части означает, что не было никаких заголовков и данный текст представлен в символьном наборе US-ASCII.]

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

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

--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic

Content-Transfer-Encoding: base64
... здесь размещаются одноканальные аудио данные, полученные при частоте стробирования 8 кГц, представленные с использованием m-преобразования, и закодированные с привлечением base64 ...

--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... здесь размещается изображение, закодированное с привлечением base64 ...
--unique-boundary-2--
--unique-boundary-1
Content-type: text/enriched

This is enriched.
как определено в RFC-1896
Isn't it
cool?
-unique-boundary-1
Content-Type: message/RFC-822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--

Ссылки

[ATK]

Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, PrenticeHall, 1990. [ISO-2022]International Standard -- Information Processing -- Character Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th ed. [ISO-8859]International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets
- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
- Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
- Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
- Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
- Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st ed.
- Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
- Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
- Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
- Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st ed. International Standard -- Information Technology -- 8-bit Single-Byte Coded Graphic Character Sets
>- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1st ed. [ISO-646]International Standard -- Information Technology - ISO 7-bit Coded Character Set for Information Interchange, ISO 646:1991, 3rd ed.. [JPEG]JPEG Draft Standard ISO 10918-1 CD. [MPEG]Video Coding Draft Standard ISO 11172 CD, ISO IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 1991. [PCM]CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies", Geneva, 1972. [POSTSCRIPT]Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985. [POSTSCRIPT2]Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990. [RFC-783]Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, June 1981. [RFC-821]Postel, J.B., "Simple Mail Transfer Protocol", STD-10, RFC-821, USC/Information Sciences Institute, August 1982. [RFC-822]Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC-822, UDEL, August 1982. [RFC-934]Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC-934, Delaware and NMA, January 1985. [RFC-959]Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC-959, USC/Information Sciences Institute, October 1985. [RFC-1049]Sirbu, M., "Content-Type Header Field for Internet Messages", RFC-1049, CMU, March 1988. [RFC-1154]Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC-1154, Prime Computer, Inc., April 1990. [RFC-1341]Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC-1341, Bellcore, Innosoft, June 1992. [RFC-1342]Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC-1342, University of Tennessee, June 1992. [RFC-1344]Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC-1344, Bellcore, June 1992. [RFC-1345]Simonsen, K., "Character Mnemonics & Character Sets", RFC-1345, Rationel Almen Planlaegning, June 1992. [RFC-1421]Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures", RFC-1421, IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1422]Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC-1422, IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1423]Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1424]Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV -- Key Certification and Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1521]Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC-1521, Bellcore, Innosoft, September, 1993. [RFC-1522]Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC-1522, University of Tennessee, September 1993. [RFC-1524]Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC-1524, Bellcore, September 1993. [RFC-1543]Postel, J., "Instructions to RFC Authors", RFC-1543, USC/Information Sciences Institute, October 1993. [RFC-1556]Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC-1556, Israeli Inter-University Computer Center, December 1993. [RFC-1590]Postel, J., "Media Type Registration Procedure", RFC-1590, USC/Information Sciences Institute, March 1994. [RFC-1602]Internet Architecture Board, Internet Engineering Steering Group, Huitema, C., Gross, P., "The Internet Standards Process -- Revision 2", March 1994. [RFC-1652]Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service Extension for 8bit-MIME transport", RFC-1652, United Nations University, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, March 1994. [RFC-1700]Reynolds, J. and J. Postel, "Assigned Numbers", STD-2, RFC-1700, USC/Information Sciences Institute, October 1994. [RFC-1741]Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December 1994. [RFC-1896]Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC-1896, February, 1996. [RFC-2045]Freed, N., and and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, Innosoft, First Virtual Holdings, November 1996. [RFC-2046]Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, Innosoft, First Virtual Holdings, November 1996. [RFC-2047]Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC-2047, University of Tennessee, November 1996. [RFC-2048]Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC-2048, Innosoft, MCI, ISI, November 1996. [RFC-2049]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC-2049 (this document), Innosoft, First Virtual Holdings, November 1996. [US-ASCII]Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. [X400]Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.

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