Экспериментальные значения типа среды
Значение типа среды, начинающееся с символов "X-" представляет собой частное значение, предназначенное для применения системами, которые согласились между собой работать в таком режиме. Любой формат, не являющийся стандартным, должен иметь имя, начинающееся с префикса "X-", а утвержденные стандартные имена никогда не начинаются с "X-".
Вообще, использование "X-" для типов верхнего уровня категорически не рекомендуется. Разработчики должны придумывать субтипы существующих типов. Во многих случаях субтип "application" будет более уместен, чем новый тип верхнего уровня.
Приложение A -- обзор грамматики
Данное приложение содержит все синтаксические конструкции, описанные в разделе MIME. Сама по себе данная грамматика не может считаться полной. Она базируется на нескольких правилах, определенных в документе RFC 822. Если какой-то термин не определен, его значение предполагается заданным в RFC 822. Сами правила RFC 822 здесь не представлены.
boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
body-part := <"сообщение" как это определено в RFC-822, со всеми опционными полями заголовка, не начинающимися со специфицированных дефис-границ, и без разделителей в пределах тела сообщения. Заметим, что семантика секции отличается от семантики сообщения, как это описано в тексте.>
close-delimiter := delimiter "--"
dash-boundary := "--" boundary
| boundary берется из значения пограничного параметра из поля Content-Type. |
delimiter := CRLF dash-boundary
discard-text := *(*text CRLF); Может игнорироваться или отбрасываться.
encapsulation := delimiter transport-padding CRLF body-part
epilogue := discard-text
multipart-body := [preamble CRLF]
| Dash-boundary transport-padding CRLF | |
| body-part *encapsulation | |
| close-delimiter transport-padding | |
| [CRLF epilogue] |
preamble := discard-text
transport-padding := *LWSP-char
; Отправители не должны генерировать транспортных заполнителей не нулевой
; длины, но получатели должны уметь обрабатывать заполнители, добавленные в
; сообщение при транспортировке.
III. Расширения для заголовков сообщений с не-ASCII текстом
В этом разделе описывается техника кодирования не-ASCII-текста в различных частях заголовка сообщения RFC-822 [2].
Подобно тому, как это рассказано в первом разделе описания MIME, методика сконструирована так, чтобы допустить использование не-ASCII символов в заголовках сообщения так, чтобы даже специфические) удаляют некоторые поля заголовков, сохраняя другие, (b) меняет содержимое адресов в полях To или Cc, (c) меняют вертикальный порядок размещения полей заголовка. Кроме того, некоторые почтовые программы не всегда способны корректно интерпретировать заголовки сообщений, в которых встречаются некоторые редко используемые рекомендации документа RFC 822, например, символы обратной косой черты для выделения специальных символов типа "<", "," или ":".
Расширения, описанные здесь, не базируются на редко используемых возможностях RFC-822. Вместо этого, определенные последовательности "обычных" печатных ASCII символов (известных как "encoded-words" - кодировочные слова) зарезервированы для использования в качестве кодированных данных. Синтаксис кодированных слов таков, что они вряд ли могут появиться в нормальном тексте заголовков сообщений. Более того, символы, используемые в кодировочных словах, не могут иметь специального назначения в контексте, где появляются эти слова.
Вообще, "encoded-word>" представляет собой последовательность печатных ASCII-символов, которая начинается с "=?", завершается "?=" и имеет два "?" между ними. Оно специфицирует символьный набор и метод кодирования, а также включает в себя оригинальный текст в виде графических ASCII-символов, созданный согласно правилам данного метода кодирования.
Отправители почты, которые используют данную спецификацию, предоставят средства для помещения не-ASCII текста в поля заголовка, но транслируют эти поля (или соответствующие части полей) в кодировочные слова, прежде чем помещать их в заголовок сообщения.
Система чтения почты, которая реализует данную спецификацию, распознает кодировочные слова, когда они встречаются в определенной части заголовка сообщения. Вместо того чтобы отображать кодировочное слово, программа осуществляет декодирование исходного текста с использованием соответствующего символьного набора.
Данный документ в заметной мере базируется на нотации и терминах RFC-822 и RFC-2045. В частности, синтаксис для ABNF, используемый здесь, определен в RFC-822. Среди терминов, определенных в RFC-822 и использованных в данном документе: 'addr-spec' (спецификация адреса), 'атом', 'CHAR', 'комментарий', 'CTL', 'ctext', 'linear-white-space' (HT| SP|CRLF), 'фраза', 'quoted-pair', 'закавыченная строка', 'пробел' и 'слово'. Успешная реализация расширения этого протокола требует тщательного внимания к определениям этих терминов в RFC-822.
Когда в данном документе встречается термин "ASCII", он относится к "7-битовому стандарту, ANSI X3.4-1986. Имя этого символьного набора в MIME "US-ASCII".
