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") "<[email protected]
>" "Compiler diff" "BASE64" 4554 73) "MIXED")) После подтипа multipart следует расширение данных. Это расширение никогда не возвращается в выборках BODY но может содержаться в выборках BODYSTRUCTURE. При наличии расширенных данных они должны размещаться в приведенном ниже порядке.
Все последующие данные еще не определены в данной версии протокола. Такие расширения данных могут содержать 0 или более значений NIL, строк, чисел и потенциально вложенных заключенных в скобки списков таких данных. Реализации клиентов, использующие выборки BODYSTRUCTURE ДОЛЖНЫ быть готовы к восприятию расширенных данных такого типа. Для серверов недопустима передача таких расширений, пока они не будут определены при пересмотре данного протокола. Базовые поля для тел, не содержащих множества частей (non-multipart body) имеют следующий порядок:
Тело типа MESSAGE или подтипа RFC822 содержит сразу же после основных полей структуру конверта, структуру тела и размер текстовых строк инкапсулированного сообщения. Тело типа TEXT содержит сразу же после основных полей размер и собственно тело в форме текстовых строк. Отметим, что поле размера задается для транспортного кодирования, а не для содержимого после декодирования. После основных полей и перечисленных выше полей, связанных с конкретными типами сообщений, следуют поля расширения. Эти поля никогда не возвращаются в выборке BODY, но могут возвращаться выборкой BODYSTRUCTURE. При использовании расширенных данных они ДОЛЖНЫ размещаться в приведенном ниже порядке (для тел, не содержащих множества частей):
Все последующие расширения данных еще не определены в этой версии протокола и описываются как данные 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)