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

5. Работа протокола

5.1. Именование почтовых ящиков

Интерпретация имен почтовых ящиков зависит от реализации. Однако почтовый ящик с независимым от регистра именем INBOX зарезервирован в качестве основного почтового ящика пользователя на данном сервере.

5.1.1. Иерархия имен

Желательно экспортировать иерархические имена почтовых ящиков — имена ДОЛЖНЫ записываться со снижением уровня иерархии слева направо и односимвольным разделителем между иерархическими уровнями. Разделитель для всех переходов между уровнями ДОЛЖЕН быть один.

5.1.2. Соглашение о пространстве имен

По этому соглашению первый иерархический элемент любого имени почтового ящика ДОЛЖЕН начинаться с символа #, идентифицирующего пространство имен (namespace) остальной части имени. Это позволяет различать разные типы почтовых хранилищ (mailbox store), каждый из которых имеет свое пространство имен. Например, реализация, предлагающая доступ к конференциям USENET может использовать пространство #news для отделения имен конференций USENET от других почтовых ящиков. В результате конференция comp.mail.misc будет иметь почтовый ящик #news.comp.mail.misc, а имя comp.mail.misc может указывать на иной объект (например, почтовый ящик пользователя).

5.1.3. Соглашение об использовании других языков в именах

В соответствии с этим соглашение имена почтовых ящиков могут использовать символы других языков с обновленной версией кодирования UTF-7, описанной в работе [UTF-7]. Обновление было предпринято с целью разрешения перечисленных ниже проблем UTF-7:

  1. UTF-7 использует знак "+" для смещения (shifting), что не позволяет применять "+" в именах почтовых ящиков (в частности, с названиях конференций USENET.
  2. UTF-7 использует кодирование BASE64, применение символа "/" в котором конфликтует с использованием "/" в качестве разделителя иерархических уровней.
  3. UTF-7 запрещает некодированное представление символа "\", что не позволяет использовать его в качестве разделителя иерархических уровней.
  4. UTF-7 запрещает некодированное представление символа "~", используемого в некоторых серверах в качестве индикатора домашнего каталога.
  5. UTF-7 допускает множество альтернативных форм представления одной строки (в частности, печатные символы US-ASCII можно представлять в кодированной форме).

В обновленном варианте UTF-7 печатные символы US-ASCII (за исключением "&") представляют себя, т. е., символы с кодами 0x20 - 0x25 и 0x27 - 0x7e. Символ "&" (0x26) представляется 2-октетной последовательностью "&-". Все прочие символы (0x00 - 0x1f, 0x7f - 0xff, 16-битовые символы Unicode) представляются с использованием модифицированного кода BASE64 (в соответствии с [UTF-7] "," используется взамен "/"). Обновленное кодирование BASE64 недопустимо использовать для представления любых печатных символов US-ASCII. Символ "&" используется для перехода к модифицированному кодированию BASE64, а "-" для перехода к US-ASCII. Все имена начинаются с символа US-ASCII и ДОЛЖНЫ заканчиваться символом US-ASCII (т. е., имя из символов Unicode должно завершаться знаком "- "). В качестве примера приведем имя, содержащее текст на английском, японском и китайском языках — ~peter/mail/&ZeVnLIqe-/&U,BTFw-

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