Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача
| Вид материала | Задача |
Содержание6. Поле заголовка Content-ID 7. Поле заголовка Content-Description 8. Дополнительные поля заголовка MIME Приложение A -- обзор грамматики II. Типы среды |
- Поурочне планування курсу "Основи Інтернет – технологій", 88.8kb.
- Работа nat введение, 150.17kb.
- 1. Сервіси Internet, 731.38kb.
- 1. Сервіси Internet, 347.99kb.
- Internet Information Services (iis). Понимание организации сетей, tcp/ip и Domain Name, 17.07kb.
- Что такое Internet? Ресурсы Internet*, 347.7kb.
- Лабораторна робота №19 ”Internet”, 103.46kb.
- Е. Е. Израилевич Практическая грамматика английского языка с упражнениями и ключами, 14711.83kb.
- Математическая логика сквозь школьные предметы, 133.29kb.
- Мифы и реальности Internet известные и скрытые возможности сети Что такое Internet, 306.75kb.
6. Поле заголовка Content-ID
При создании агента пользователя высокого уровня, может быть желательно, допустить одному телу ссылаться на другое. Тела могут быть помечены с помощью поля заголовка "Content-ID", которое синтаксически идентично полю "Message-ID":
id := "Content-ID" ":" msg-id
Подобно значениям Message-ID, значения Content-ID должны генерироваться уникальными.
Значение Content-ID может использоваться для идентификации MIME-объектов в нескольких контекстах, в частности для кэширования данных с доступом через механизм message/external-body. Хотя заголовок Content-ID является обычно опционным, его использование является обязательным в приложениях, которые генерируют данные опционного типа среды MIME "message/external-body". По этой причине каждый объект message/external-body должен иметь поле Content-ID, для того чтобы разрешить кэширование таких данных.
7. Поле заголовка Content-Description
Часто оказывается желательным установить соответствие между описательной информацией и данным телом. Например, может быть полезным пометить тело типа "image" как "изображение старта космического корабля". Такой текст может быть помещен в поле заголовка Content-Description. Это поле всегда является опционным.
description := "Content-Description" ":" *text
Предполагается, что описание дается с использованием символьного набора US-ASCII, хотя механизм, специфицированный в RFC 2047, может быть использован и для значений Content-Description, не соответствующих стандарту US-ASCII.
8. Дополнительные поля заголовка MIME
Будущие документы могут содержать дополнительные поля заголовков MIME для различных целей. Любое новое поле заголовка, которое описывает содержимое сообщения должно начинаться со строки "Content-", для того чтобы такие поля можно было с гарантией отличить от обычных полей заголовков сообщения, следующих стандарту RFC-822.
MIME-extension-field := <Любое поле заголовка RFC-822, которое начинается со строки "Content-">
Используя поля заголовка MIME-Version, Content-Type и Content-Transfer-Encoding, можно подключить стандартным образом произвольные типы данных и добиться совместимости с требованиями документа RFC-822. Никакие ограничения введенные документами RFC-821 или RFC-822 не нарушаются, были приняты меры, чтобы исключить проблемы, связанные с дополнительными ограничениями из-за свойств некоторых механизмов пересылки почты по Интернет (см. RFC-2049).
Приложение A -- обзор грамматики
Это приложение содержит грамматические описания всех конструкций, содержащихся в протоколе MIME.
| attribute | := | token | Распознавание атрибутов не зависит от регистра, в котором написаны их имена. |
| composite-type | := | "message" / "multipart" / extension-token | |
| Content | := | "Content-Type" ":" type "/" subtype *(";" parameter) | Распознавание типов среды и субтипов не зависит от регистра, в котором написаны их имена. |
| description | := | "Content-Description" ":" *text | |
| discrete-type | := | "text" / "image" / "audio" / "video" / "application" / extension-token | |
| encoding | := | "Content-Transfer-Encoding" ":" mechanism | |
| entity-headers | := | [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) | |
| extension-token | := | ietf-token / x-token | |
| hex-octet | := | "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") | Октет должен использоваться для символов > 127, =, пробелов или TAB в конце строк, и рекомендуется для любого символа вне списка "mail-safe" RFC 2049. |
| iana-token | := | <Общедоступная лексема. Лексемы этого формата должны регистрироваться IANA, как это определено в RFC 2048.> | |
| ietf-token | := | <Лексема расширения, определенная согласно RFC и зарегистрированная IANA.> | |
| Id | := | "Content-ID" ":" msg-id | |
| mechanism | := | "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token | |
| MIME-extension-field | := | <Любое поле заголовка RFC 822, которое начинается со строки "Content-"> | |
| MIME-message-headers | := | entity-headers fields version CRLF | Порядок полей заголовка, заданный в BNF-определении не играет никакой роли. |
| MIME-part-headers | := | Заголовки объекта [поля] | Любое поле, начинающееся с "content-", не имеет строго заданного значения и может игнорироваться. |
| parameter | := | атрибут "=" значение | |
| Ptext | := | hex-octet / safe-char | |
| qp-line | := | *(qp-segment transport-padding CRLF) транспортный заполнитель qp-части | |
| qp-part | := | qp-секция | Максимальная длина 76 символов |
| qp-section | := | [*(ptext / SPACE / TAB) ptext] | |
| qp-segment | := | qp-секция *(SPACE / TAB) "=" | Максимальная длина 76 символов |
| Quoted-printable | := | qp-line *(CRLF qp-line) | |
| safe-char | := | <любой октет с десятичным кодом от 33 до 60, включительно, и с 62 до 126> | Символы вне списка "mail-safe" в RFC 2049 не рекомендуются. |
| subtype | := | Лексема расширения / лексема iana | |
| Token | := | 1*<любой US-ASCII-символ за исключением SPACE, CTLs, или tspecials> | |
| transport-padding | := | *LWSP-char | Программа-отправитель не должна формировать транспортное заполнение ненулевой длины, но получатели должны быть способны обрабатывать такие транспортные заполнители. |
| tspecials | := | "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" | При использовании в значениях параметров они должны иметь формат закавыченных строк. |
| Type | := | discretetype / compositetype | |
| Value | := | лексема / закавыченная строка | |
| version | := | "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | |
| x-token | := | <Два символа "X-" или "x-", за которыми следует без пробела любая лексема> | |
II. Типы среды
1. Введение
Поле Content-Type используется для спецификации природы информации в теле MIME-объекта путем присвоения идентификаторов типа и субтипа среды и предоставления дополнительной информации, которая может быть необходима для данной разновидности среды. За именами типа и субтипа среды в поле следует набор параметров, заданных в нотации атрибут/значение. Порядок следования параметров не существенен.
Тип среды верхнего уровня используется для декларации общего типа данных, в то время как субтип определяет специфический формат данного типа информации. Таким образом, тип среды "image/xyz" говорит агенту пользователя, что данные характеризуют изображение и имеют формат "xyz". Такая информация может использоваться, для того чтобы решить, отображать ли пользователю исходные данные нераспознанного субтипа. Такие действия могут быть разумными для нераспознанного фрагмента субтипа "text", но не для субтипов "image" или "audio". По этой причине, зарегистрированные субтипы "text", "image", "audio" и "video" не должны содержать встроенных фрагментов другого типа. Такие составные форматы должны использовать типы "multipart" или "application".
Параметры являются модификаторами субтипа среды, и как таковые не оказывают никакого влияния на содержимое. Набор параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом. Однако определенный тип среды высшего уровня может определить параметры, которые приложимы к любому субтипу данного типа. Параметры могут быть обязательными или опционными. MIME игнорирует любые параметры, имена которых нераспознаны.
Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа "message/external-body" со временем могут обрести новые значения. Для того чтобы гарантировать то, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.