Интегрированные сети ISDN


Поле заголовка Content-Description - часть 31


Любой формат, не являющийся стандартным, должен иметь имя, начинающееся с префикса "X-", а утвержденные стандартные имена никогда не начинаются с "X-".

Вообще, использование "X-" для типов верхнего уровня категорически не рекомендуется. Разработчики должны придумывать субтипы существующих типов. Во многих случаях субтип "application" будет более уместен, чем новый тип верхнего уровня.

Приложение A -- обзор грамматики

Данное приложение содержит все синтаксические конструкции, описанные в разделе MIME. Сама по себе данная грамматика не может считаться полной. Она базируется на нескольких правилах, определенных в документе RFC 822. Если какой-то термин не определен, его значение предполагается заданным в RFC 822. Сами правила RFC 822 здесь не представлены.

boundary := 0*69 bcharsnospace

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

body-part :=

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].




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



Книжный магазин