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

RFC 2060, Страница 2 из 51

1. Как работать с документом

1.1. Структура документа

Этот документ представляет протокол с точки зрения разработчика клиента или сервера IMAP4rev1. Кроме обзора главе 2, документ не содержит каких-либо материалов, помогающих понять работу протокола. Главы 3 - 5 содержат общий контекст и определения, используемые IMAP4rev1.

В главах 6, 7 и 9 описаны команды, отклики и синтаксис, соответственно. Соотношения между ними таковы, что почти невозможно разобраться с протоколом, рассматривая команды, отклики и синтаксис по отдельности. В частности, не следует пытаться вывести синтаксис команд, прочтя лишь их описание — обратитесь к главе, описывающей синтаксис.

1.2. Используемые соглашения

В примерах обозначения C: и S: показывают строки, передаваемые клиентом и сервером, соответственно. Термины, используемые для обозначения уровня требований, растолкованы ниже.

  1. MUST — необходимо
  2. Это слово, а также термины требуется (обязательно) и нужно (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

  3. MUST NOT — недопустимо
  4. Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

  5. SHOULD — следует
  6. Это слово, а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

  7. SHOULD NOT — не следует
  8. Эта фраза и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких опций следует учитывать возможность возникновения проблем и принимать взвешенное решение.

  9. MAY — возможно
  10. Это слово, а также прилагательное необязательный (дополнительно) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие — опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счет некоторого ущерба функциональности). Включающие опцию реализации ДОЛЖНЫ быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не поддерживают.

Термин «пользователь» (User) используется для обозначения человека, а слово «клиент» обозначает пользовательские программы.

Термин «соединение» (Connection) описывает всю последовательность операций взаимодействия между клиентом и сервером от момента организации связи и до ее завершения. Термины «сеанс» или «сессия» (Session) обозначают последовательность операций обмена между клиентом и сервером с момента выбора почтового ящика (команда SELECT или EXAMINE) и до отмены этого выбора (команда SELECT или EXAMINE для другого почтового ящика, команда CLOSE или разрыв соединения).

Символом будем называть 7-битовый символ из набора US-ASCII, если явно не указано иное. Другие символьные наборы обозначаются с использованием CHARSET, как описано в [MIME-IMT] и определено в [CHARSET]. Опция CHARSET имеет дополнительную семантику, описанную в вышеупомянутых работах.

Страница 2 из 51

2007 - 2022 © Русские переводы RFC, IETF, ISOC.