RFC: 2060
Оригинал: Internet Message Access Protocol v.4 rev.1
Другие версии: RFC 1730, RFC 3501
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

7.4.2. Отклик FETCH

Содержимое:данные сообщения

Отклик FETCH возвращает клиенту данные о сообщении. Данные представляются в виде пар имя — значение, заключенных в скобки. Этот отклик возвращается по команде в результате команд FETCH и STORE или по инициативе сервера (например, в результате обновления флагов).

Настоящая спецификация определяет следующие типы данных:

BODYформа BODYSTRUCTURE без расширения данных
BODY[<section>]<<origin_octet>>Строковое выражение содержимого тела указанной части сообщения. Клиенту следует интерпретировать строку в соответствии с типом транспортного кодирования содержимого, типом и подтипом тела. Если указан начальный октет, эта строка является подстрокой всего содержимого тела, начиная с

начального октета. Это значит, что BODY[]<0> можно усечь, а BODY[] усекать недопустимо. Допустимо использование 8-битовых текстовых данных, если идентификатор [CHARSET] является частью заключенного в скобки списка параметров тела для этой секции. Отметим, что заголовки (спецификаторы частей HEADER и MIME или части заголовка MESSAGE/RFC822) ДОЛЖНЫ быть 7-битовыми (8-битовые символы недопустимы в заголовках). Отметим также, что в данные заголовка всегда включается пустая строка в конце.

Нетекстовые (бинарные) данные ДОЛЖНЫ передаваться с использованием преобразования в текст (например, BASE64) до передачи клиенту. Для восстановления исходных двоичных данных клиент должен декодировать строку транспортного кодирования.

BODYSTRUCTUREЗаключенный в скобки список, который описывает структуру тела сообщения [MIMEIMB]. Этот список создается сервером в результате разбора полей заголовка [MIME-IMB] и включения при необходимости принятых по умолчанию значений. Например, простое текстовое сообщение из 48 строк и 2279 октетов имеет структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48). При наличии множества частей они указываются вложенными списками в скобках. Вместо типа тела первого элемента заключенного в скобки списка помещается вложенное тело. Вторым элементов списка в скобках является подтип multipart (mixed, digest, parallel, alternative и т. п.). Например, сообщение из 2 частей, содержащее текст и данные в формате BASE64 может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED")) После подтипа multipart следует расширение данных. Это расширение никогда не возвращается в выборках BODY но может содержаться в выборках BODYSTRUCTURE. При наличии расширенных данных они должны размещаться в приведенном ниже порядке.
  • body parameter parenthesized list
  • Заключенный в скобки список пар «атрибут-значение» (например, ("foo" "bar" "baz" "rag"), где "bar" является значением атрибута "foo", а "rag" — значением "baz") в соответствии с [MIME-IMB].
  • body disposition
  • Заключенный в скобки список, который содержит строку типа размещения, за которой следует заключенный в скобки список пар «атрибут размещения — значение». Типы размещения и имена атрибутов будут определены в будущей версии предложенного стандарта [DISPOSITION].
  • body language
  • Строка или заключенный в скобки список, указывающие язык тела в соответствии с [LANGUAGETAGS].

Все последующие данные еще не определены в данной версии протокола. Такие расширения данных могут содержать 0 или более значений NIL, строк, чисел и потенциально вложенных заключенных в скобки списков таких данных. Реализации клиентов, использующие выборки BODYSTRUCTURE ДОЛЖНЫ быть готовы к восприятию расширенных данных такого типа. Для серверов недопустима передача таких расширений, пока они не будут определены при пересмотре данного протокола.

Базовые поля для тел, не содержащих множества частей (non-multipart body) имеют следующий порядок:

  • body type
  • Строка, указывающая название типа среды в соответствии с [MIME-IMB].
  • body subtype
  • Строка, указывающая имя подтипа в соответствии с [MIME-IMB].
  • body parameter parenthesized list
  • Заключенный в скобки список пар «атрибут-значение» (например, ("foo" "bar" "baz" "rag"), где "bar" является значением атрибута "foo", а "rag" — значением "baz") в соответствии с [MIME-IMB].
  • body id
  • Строка, указывающая идентификатор содержимого в соответствии с [MIME-IMB].
  • body description
  • Строка, описывающая содержимое в соответствии с [MIME-IMB].
  • body encoding
  • Строка, указывающая транспортное кодирование в соответствии с [MIME-IMB].
  • body size
  • Число, показывающее размер тела в октетах. Отметим, что это число показывает размер для транспортного кодирования, а не размер после декодирования.

Тело типа MESSAGE или подтипа RFC822 содержит сразу же после основных полей структуру конверта, структуру тела и размер текстовых строк инкапсулированного сообщения.

Тело типа TEXT содержит сразу же после основных полей размер и собственно тело в форме текстовых строк. Отметим, что поле размера задается для транспортного кодирования, а не для содержимого после декодирования.

После основных полей и перечисленных выше полей, связанных с конкретными типами сообщений, следуют поля расширения. Эти поля никогда не возвращаются в выборке BODY, но могут возвращаться выборкой BODYSTRUCTURE. При использовании расширенных данных они ДОЛЖНЫ размещаться в приведенном ниже порядке (для тел, не содержащих множества частей):

  • body MD5
  • Строка, дающая значение MD5 в соответствии с определением [MD5].
  • body disposition
  • Список в скобках таким же содержимым и функциями, как расположение тела для multipart body part.
  • body language
  • Строка или заключенный в скобки список, указывающие язык тела сообщения в соответствии с [LANGUAGE-TAGS].

Все последующие расширения данных еще не определены в этой версии протокола и описываются как данные multipart-расширений.

ENVELOPEЗаключенный в скобки список, описывающий структуру конверта в сообщении. Этот список создается сервером путем разбора заголовка [RFC-822] на составные части и включения при необходимости принятых по умолчанию значений. Поля в структуре конверта располагаются в следующем порядке: date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to, and message-id. Поля date, subject, in-reply-to и message-id представляют собой текстовые строки, поля from, sender, reply-to, to, cc, bcc — заключенные в скобки списки адресных структур.

Адресная структура представляет собой заключенный в скобки список, который описывает адрес электронной почты. Поля структуры располагаются в следующем порядке: personal name, [SMTP] at-domainlist (source route), mailbox name, host name.

Групповой синтаксис [RFC-822] указывается специальной формой адресной структуры, в которой имя хоста имеет значение NIL. Если имя почтового ящика также имеет значение NIL, это говорит о маркере окончания группы (точка с запятой в синтаксисе RFC 822). Если имя почтового ящика отличается от NIL, это говорит о маркере начала группы и поле имени почтового ящика содержит имя группы.

Любые неприменимые поля конверта или адресной структуры содержат значение NIL. Отметим, что сервер должен по умолчанию брать значения полей reply-to и sender из поля from; предполагается, что клиент не обязан их знать.

FLAGSЗаключенный в скобки список флагов, установленных для сообщения.
INTERNALDATEСтрока, представляющая внутреннюю дату сообщения.
RFC822Эквивалент BODY[].
RFC822.HEADERЭквивалент BODY.PEEK[HEADER].
RFC822.SIZEЧисло, выражающее размер [RFC-822] для сообщения.
RFC822.TEXTЭквивалент BODY[TEXT].
UIDЧисло, выражающее уникальный идентификатор сообщения.
Пример:  S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
2007 - 2017 © Русские переводы RFC, IETF, ISOC.