| Версия 5.2
Введение
Установка
Администрирование
Сеть
Объекты
Почта
Сигналы
Доступ
Услуги
Справочник
Кластеры
Программы
Разное
Лицензирование
Веб Почта
Pronto!
PBX
Программы | Данные | CLI/API | Правила | CG/PL | PBXApp | XIMSS | WebApp | WSSP | Помощники
# XIMSS Протокол Протокол и Синтаксис Сообщения Операции, Предшествующие Входу Операции Входа Служебные Операции Управление Папкой Операции с Папкой Операции с Сообщениями Управление Пользователем Безопасный обмен Сообщениями (S/MIME) Операции с Контактами Операции с Календарём Сигналы Мгновенные Сообщения Ростер и Статус Присутствия Настройки Операции с Хранилищем Файлов Управление Автоматическими Правилами Дистанционное обслуживание POP Управление Приложениями Реального Времени Справочник Наборы Данных Тарификация Получение Рекламы Форматы Данных XML `EMail` `MIME` `MIMEReport` HTTP Доступ Получение Части Сообщения Загрузка Файла на Сервер Скачивание Файла В Сервере CommuniGate Pro реализован XML Интерфейс для протокола Сообщений, Расписаний и Сигналов (XIMSS протокол). Интерфейс реализован в XIMSS модуле и поддерживается в TCP/IP сетях. В примерах сессий протокола маркером `S:` помечаются данные, отправляемые Сервером, а маркером `C:` помечаются данные, отправляемые Клиентом.

## Протокол и Синтаксис Сообщения

XML клиенты должны устанавливать незашифрованные или безопасные TCP соединения с XML модулем Сервера CommuniGate Pro. После установления соединения обе стороны могут отправлять и получать сообщения.

Каждое сообщение является текстовой строкой, оканчивающееся специальным байтом - двоичным нулем.

Каждое сообщение должно быть сформатировано как XML документ.

Клиент, отправляя сообщение с запросом, просит Сервер совершить определённые действия и/или получить данные. Каждое сообщение запроса должно содержать атрибут `id`.

Когда Сервер завершает требуемую операцию, он отправляет обратно сообщение response:

`response`
  Атрибуты:
  `id`
    совпадает с атрибутом `id` сообщения запроса.
  `errorText`
    этот опциональный атрибут присутствует, только если операция закончилась неуспешно. В нём содержится текст сообщения об ошибке.
  `errorNum`
    этот опциональный атрибут присутствует, только если операция закончилась неуспешно. В нём содержится числовой код ошибки.
  Пример:
  C:<noop id="A001"/>
  S:<response id="A001"/>
  C:<myCommand id="A002" myParam="user1@example.dom" />
  S:<response id="A002" errorText="unknown command" errorNum="500" />

Клиент может отправить следующее сообщения запроса не ожидая ответа на текущий запрос (конвейерная обработка).

Сервер может отправлять клиенту сообщения с данными:

- при обработке сообщения запроса клиента;
  эти сообщения отправляются до отправки сообщения ответа;
  эти сообщения содержат тот же атрибут `id`, что и сообщение запроса.
- при доставку в сессию клиента асинхронного события Сервера (такого, как поступление Предупреждения или Мгновенного Сообщения).
  эти сообщения не содержат в себе никакого атрибута `id`.

  Пример:
  C:<noop id="A001"/>
  S:<alert gmtTime="20070502T083313" localTime="20070502T003313">Account is over quota</alert>
  S:<response id="A001"/>
  S:<alert gmtTime="20070502T083500" localTime="20070502T003500">Please logout, as we are shutting down.</alert>

Обратите внимание: Клиент должен отправлять какую-либо команду на Сервер как минимум раз в 10 минут, в противном случае Сервер закрывает соединение.

## Операции, Предшествующие Входу

После установления соединения с Сервером и до выполнения операции `login`, клиент может выполнять только те операции, которые перечислены в этом разделе.

При установлении соединения, Сервер берёт IP Адрес, с которым соединился клиент и выбирает Домен, которому назначен этот IP адрес.

В этом разделе в операциях может явно задаваться альтернативный целевой Домен: если он найден, то он считается целевым доменом и используется в следующих операциях.

`listFeatures`
  Эта операция указывает Серверу вернуть сообщение `features`, содержащее текущие доступные опции аутентификации и коммуникации.
  Атрибуты:
  `domain`
    опциональное имя целевого Домена.
`readStrings`
  Эта операция читает словарь (слова, тэги, имена кнопок и т.п.), хранящийся в текущем Web-Интерфейсе Домена. Сервер отправляет сообщение с данными `strings`, содержащее данные словаря.
  Атрибуты:
  `skinName`
    название Вида Web-Интерфейса. Если не указан, то используется Безымянный Вид Интерфейса.
  `language`
    язык словаря. Если атрибут отсутствует, то используется строка из настройки Пользователя `Язык`.
  `timeModified`
    Если этот атрибут задан, то он должен содержать значения даты и времени (по GMT). Если этот атрибут задан, то сообщение с данными `strings` не имеет элемента тело, при условии, что время изменения требуемого словаря не новее, чем это значение этого атрибута.
`starttls`
  Эта операция указывает серверу установить SSL/TLS безопасное соединение.
  Атрибуты:
  `domain`
    опциональное имя целевого Домена.

  Если сервер возвращает положительный ответ, то клиент немедленно должен начать процесс установки параметров SSL/TLS.

`recoverPassword`
  Эта операция просит сервер отправить по электронной почте пароль указанного Пользователя на адрес электронной почты, заданный Пользователем.
  Атрибуты:
  `domain`
    опциональное имя целевого Домена.
  `userName`
    имя Пользователя.

  Если сервер возвращает положительный ответ, то пароль Пользователя высылается по электронной почте.
  Обратите внимание: эта операция имеет некоторую задержку при отправке ответа.

`signup`
  Эта операция предписывает Серверу создать нового Пользователя.
  Атрибуты:
  `domain`
    опциональное имя целевого Домена.
  `userName`
    новое Имя Пользователя.
  `password`
    новый пароль Пользователя.
  `realName`
    Настоящее Имя нового Пользователя (опционально).
  `recoverPassword`
    адрес электронной почты, который используется для отправки забытого пароля (опционально).

  Если сервер возвращает положительный ответ, то Пользователь был создан.
  Обратите внимание: эта операция не производит вход на сервер от имени нового пользователя.
  Обратите внимание: эта операция имеет некоторую задержку при отправке ответа.

Сервер отправляет следующие сообщения данных:

`features`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает операцию `listFeatures`.
  Тело:
    набор XML элементов:
    `domain`
      имя целевого Домена.
    `sasl`
      текстовым телом этого элемента является имя SASL механизма, доступного для целевого Домена.
    `starttls`
      если этот элемент представлен, то клиент может выполнять операцию `starttls`.
    `language`
      в текстовом теле этого элемента содержится язык по умолчанию, выбранный для целевого Домена. Если этот элемент отсутствует, то выбирается значение языка по умолчанию (English).
    `signup`
      если этот элемент представлен, то клиент может выполнять операцию `signup`.
    `connect`
      если этот элемент присутствует, то он указывает на метод соединения, которым должен пользоваться клиент для входа и для запросов сессии. Он основывается на Рекомендуемых XIMSS Протоколах в Установках Домена для целевого Домена.
      Этот элемент имеет следующие атрибуты:
      `protocol`
        используемый протокол `http` или `ximss`. Рекомендуемый протокол должен быть безопасным (например, https) если операция `listFeatures` выполнялась через безопасный протокол.
      `port`
        номер используемого TCP порта. Если он не указан, то клиент должен использовать тот же порт, что использовался для отправки операции `listFeatures`.

## Операции Входа

Клиент должен операцию `login` для того, что бы аутентифицироваться и создать сессию XIMSS.

`login`
  Атрибуты:
  `domain`
    опциональное имя целевого Домена.
  `method`
    этот атрибут задаёт использование SASL метода. Если этот атрибут отсутствует, то используется незашифрованный метод (пароль передаётся в открытом виде).
  `authData`
    Если используется незашифрованный метод, то этот атрибут содержит имя пользователя.
    Для всех остальных методов, это строка с данными протокола в кодировке base64.
  `password`
    Этот атрибут используется только для незашифрованного метода и он содержит пароль пользователя в открытом виде.
  Пример:
  C:<login id="A001" authData="user1@example.dom" password="123rtu" />
  S:<session id="A001" urlID="12-skejlkieuoiuoi-dnciru" userName="user1@example.dom" realName="User J. Smith"/>
  S:<response id="A001"/>

Сервер отправляет следующие сообщения данных:

`session`
  В этом сообщении содержится информация о вновь созданной сессии. Оно посылается перед отправкой положительного ответа на операцию `login`.
  Атрибуты:
  `urlID`
    строка с идентификатором сессии. Эта строка с идентификатором может использоваться для доступа к данным сессии через HTTP.
  `userName`
    полное имя аутентифицированного Пользователя (`accountName@domainName`).
  `realName`
    Настоящее Имя аутентифицированного Пользователя (этот атрибут отсутствует, если Настоящее Имя не указано в Установках Пользователя).
  Примеры:
  C:<login id="A001" authData="user1@example2.dom" password="rrr123" />
  S:<response id="A001" errorCode="account has been moved to a remote system" errorNum="518" />

  Когда указанный SASL метод должен отправить клиенту challenge, он отправляет сообщение данных `challenge` с атрибутом `value`, в котором содержатся данные challenge в кодировке base64 для SASL протокола.
  Клиент должен отвечать отправкой запроса `auth` с тем же самым атрибутом `id`, что использовался при запросе `login` и с атрибутом `value`, в котором содержатся данные ответа SASL протокола в кодировке base64.

  Пример (смотрите RFC2195):
  C:<login id="A001" method="CRAM-MD5" />
  S:<challenge value="PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+" />
  C:<auth id="A001" value="dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw" />
  S:<session id="A001" urlID="12-skejlkieuoiuoi-dnciru" userName="user1@example.dom" realName="User J. Smith"/>
  S:<response id="A001"/>

## Служебные Операции

Следующие операции могут использоваться для управления соединением клиент-сервер.

`noop`
  Эта операция не делает ничего и всегда заканчивается успешно.
`bye`
  Эта операция не делает ничего и всегда заканчивается успешно. После того, как сообщение с ответом было отправлено клиенту, Сервер закрывает соединение и уничтожает текущую сессию.
`passwordModify`
  Эта операция изменяет Пароль Пользователя и/или адрес электронной почты, куда будет высылаться забытый пароль.
  Атрибуты:
  `oldPassword`
    текущий пароль Пользователя. Операция проверяет этот пароль до того, как пытается изменить его.
  `newPassword`
    в этом опциональном атрибуте задаётся новый пароль. Для этого Пользователя должна быть разрешена операция Изменение Пароля.
  `recoveryEMail`
    этот опциональный атрибут указывает новый адрес электронной почты для восстановления пароля.
`clearUploaded`
  Эта операция удаляет один или все файлы из "набора загруженных файлов".
  Атрибуты:
  `uploadID`
    если этот опциональный параметр указан, то из "набора загруженных файлов" удаляется файл только с таким fileID.
    Если этот параметр не указан, то из "набора загруженных файлов" удаляются все файлы.
`readStrings`
  Эта операция читает новый словарь (слова, тэги, имена кнопок и т.п.), хранящийся на Сервере. Сервер отправляет сообщение с данными `strings`, содержащее данные словаря (смотрите ниже).
  Атрибуты:
  `language`
    язык словаря. Если атрибут отсутствует, то используется строка из настройки Пользователя `Язык`.
  `timeModified`
    Если этот атрибут задан, то он должен содержать значения даты и времени (по GMT). Если этот атрибут задан, то сообщение с данными `strings` не имеет элемента тело, при условии, что время изменения требуемого словаря не новее, чем это значение этого атрибута.
`readTime`
  Эта операция читает текущее время Сервера. Сервер отправляет сообщение `currentTime`.
`readStatus`
  Эта операция читает текущий статус Пользователя. Сервер отправляет сообщение `currentStatus`.
`listKnownValues`
  Эта операция приводит к отправке сервером сообщения `knownValues`. Это сообщение содержит наборы "известных значений": известные названия Часовых Поясов, имена кодировок и т.д.
`skinList`
  Эта операция перечисляет Виды Интерфейса из текущего Домена.
  Атрибуты:
  `filter`
    опциональный атрибут, указывающий на "картинку" строки с символом звёздочка (`*`), используемым как шаблон подстановки. Возвращаются только те имена Видов Интерфейса, которые соответствуют этой "картинке".
  Сервер возвращает одно сообщение `skinInfo` для каждого найденного Вида Интерфейса.
`skinFileList`
  С помощью этой операции можно получить список имён файлов выбранного Вида Интерфейса.
  Атрибуты:
  `skinName`
    название Вида Web-Интерфейса. Если не указан, то используется Безымянный Вид Интерфейса.
  `filter`
    опциональный атрибут, указывающий на "картинку" строки с символом звёздочка (`*`), используемым как шаблон подстановки. Возвращаются только те имена файлов, которые соответствуют этой "картинке".
  Сервер возвращает одно сообщение `skinFileInfo` для каждого найденного файла.
`skinFileRead`
  Эта операция читает файл из указанного Вид Интерфейса текущего Домена.
  Атрибуты:
  `skinName`
    название Вида Web-Интерфейса. Если не указан, то используется Безымянный Вид Интерфейса.
  `fileName`
    имя файла, который необходимо прочитать.
  `type`
    Если этот опциональный атрибут существует и его значением является `binary`, то данные файла возвращается в кодировке base64.
  Сервер возвращает сообщение `skinFileData`.
`cliExecute`
  Эта операция выполняет команду CLI.
  Атрибуты:
  `report`
    если этот атрибут присутствует и имеет значение `xml`, то результирующий объект будет отправлен как XML представление.
  Тело:
    текст команды CLI
  Если команда CLI имеет результат, то сервер отправляет сообщение `cliResult`.
`retrieveXML`
  Эта операция читает XML документ на удалённом сервере. Текущий пользователь должен иметь включённой `HTTP` Услугу.
  Атрибуты:
  `url`
    URL на XML документ (`http:` или `https:`).
  `timeout`
    тайм-аут выполнения операции (в секундах).
  Если документ получен успешно, то Сервер отправляет сообщение `retrievedXML` с содержимым полученного документа.
`retrieveURL`
  Эта операция читает документ, хранящийся на удалённом сервере. Текущий пользователь должен иметь включённой `HTTP` Услугу.
  Атрибуты:
  `url`
    URL на XML документ (`http:` или `https:`).
  `Content-Type`
    тип содержимого тела запроса.
  `Content-Subtype`
    подтип содержимого тела запроса. Этот атрибут используется только если указан атрибут `Content-Type`.
  `method`
    метод запроса. Если этот элемент отсутствует, то, если тело запроса не указано, используется метод `GET`, иначе используется метод `POST`.
  `Cookie`
    данные поля Cookie.
  `authName`, `authPassword`
    если указаны, то эти атрибуты используются для аутентификации запроса.
  `timeout`
    число из диапазон 0..30, используемое как максимальное время ожидания завершения транзакции (таймаут), в секундах Если не указано, то используется таймаут в 30 секунд.
  Тело:
    используется один из следующих форматов:
    - текс тела запроса
    - элемент `base64`, содержащий двоичные данные тела запроса в кодировке base64
    - набор XML элементов `field`. Каждый элемент `field` имеет атрибут `name` и текстовое тело. Эти элементы используются для создания запроса типа form, в котором указываются входные значения формы.
  По завершению транзакции, Сервер отправляет сообщение `retrievedURL` с результатами транзакици.
`spellerList`
  Эта операция приводит к тому, что сервер отправляет сообщения `speller`, в которых содержатся имена установленных программ для проверки орфографии.
`spellerCheck`
  Эта операция проверяет корректность написания произвольного текста. Для каждой обнаруженной ошибки, Сервер отправляет сообщение `spellerReport`.
  Атрибуты:
  `speller`
    имя программы для проверки орфографии.
  Тело:
    проверяемый текст.

Сервер может отправлять следующие служебные сообщения данных в любое время:

`alert`
  Аутентифицированный Пользователь получает Предупреждение. Как только сервер отправляет Клиенту сообщение данных с Предупреждением, сообщение Предупреждения помечается как "подтверждённое".
  Атрибуты:
  `gmtTime`
    время опубликования предупреждения (GMT).
  `localTime`
    время опубликования предупреждения (в выбранном часовом поясе).
  Тело:
    текст Предупреждения (в кодировке UTF-8).
`bye`
  Сервер решил закрыть сессию (тайм-аут, действия администратора и т.д.).
  Клиент должен закрыть соединение с Сервером (если оно имеется) и проинформировать пользователя.

Сервер может отправлять следующие сообщения данных:

`strings`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `readStrings`.
  Атрибуты:
  `language`
    выбранный язык.
  `timeModified`
    дата и время изменения словаря (время GMT).
  Тело:
    набор из XML элементов `string` и `strings`. Каждый элемент имеет атрибут `name` - имя (или "ключ") элемента словаря.
    Элементы словаря типа строка представляются с использованием элементов `string`. Телом элемента `string` является значение элемента словаря.
    Элементы словаря типа словарь представляются с использованием элементов `strings`. Телом элемента `strings` является набор XML элементов `string`.
    Элементы словаря типа массив представляются при помощи элементов `strings`. Телом элемента `strings` является набор XML элементов `string` без атрибута `name`.
  Пример:
  Клиент читает словарь по умолчанию (английский).
  C:<readStrings id="A001" />
  S:<strings id="A001" language="" >
  <string name="AppendButton">Append</string>
  <strings name="AppendModes">
  <string name="simple">Simple Mode</string>
  <string name="advanced">Advanced Mode</string>
  </strings>
  <strings name="KnownFields">
  <string>From</string>
  <string>Subject</string>
  </strings>
  </strings>
  S:<response id="A001"/>
`currentTime`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `readTime`.
  Атрибуты:
  `gmtTime`
    текущее Время Сервера (GMT).
  `localTime`
    текущее Время Сервера (в выбранном часовом поясе).
`currentStatus`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `readStatus`.
  Тело:
    набор XML элементов:
    `messageStore`
      Информация о Хранилище Почты Пользователя.
      Атрибуты:
      `used`
        текущий объём использованного хранилища (в байтах).
      `limit`
        размер Квоты Хранилища. Этот атрибут отсутствует, если ограничение для квоты не установлено.
    `PrevLogin`
      Информация о предыдущем успешном входе на сервер.
      Атрибуты:
      `gmtTime`
        время входа (GMT).
      `localTime`
        время входа (в выбранном часовом поясе).
      `ip`
        сетевой адрес, с которого вошёл пользователь.
    `LastFailedLogin`
      Информация о последнем неуспешном входе на сервер.
      Атрибуты:
      `gmtTime`
        время последнего неуспешного входа на сервер (GMT).
      `localTime`
        время последнего неуспешного входа на сервер (в выбранном часовом поясе).
      `ip`
        сетевой адрес, с которого была предпринята попытка неуспешного входа на сервер.
    `RulesAllowed`, `SignalRulesAllowed`, `RPOPAllowed`, `PWDAllowed`
      Фактически действующие Установки Пользователя. Эти элементы не имеют атрибутов и текст их тела является значением установки.
    `option`
      ноль, один или несколько XML элементов. Телом элемента является строка, указывающая опцию, включённую для текущего Пользователя:
      `S/MIME`
        Услуги Безопасной Почты (S/MIME Защиты) включены.
      `SMIMEActive`
        Услуги Безопасной Почты (S/MIME Защиты) разблокированы.
      `SMIMEInactive`
        Услуги Безопасной Почты (S/MIME Защиты) заблокированы (но Пользователь имеет Защитный Ключ PKI).
      `WebCAL`
        Услуги календаря включены.
      `WebSite`
        Веб Доступ к Хранилищу Файлов по HTTP включён.
      `Signal`
        Услуги Сигналов включены.
      `PBX`
        Услуги PBX включены.
      `HTTP`
        Услуги HTTP транзакций включены.
`knownValues`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `listKnownValues`.
  Тело:
    набор XML элементов:
    `tzid`
      атрибут `name` элемента указывает наименование известного Часового Пояса;
    `charset`
      атрибут `name` элемента указывает наименование известной кодировки;
    `mailRuleAllowed`
      атрибут `name` элемента задаёт поддерживаемые режимы Разрешённых Почтовых Правил. Каждый режим определяет, какие действия Почтовых Правил пользователю разрешается изменять; Элементы сортируются так, что бы вначале были перечислены "наиболее ограничивающие" режимы.
    `mailRuleCondition`
      атрибут `name` элемента указывает поддерживаемое условие Почтовых Правил.
    `mailRuleAction`
      атрибут `name` элемента указывает поддерживаемое действие Почтовых Правил; атрибут `allowedSet` элемента указывает задействование имени Разрешённого Почтового Правила. Пользователь может изменять Правило, содержащую эту операцию, только если в значении Установки `Разрешённые Правила для Почты` Пользователя установлен менее ограничивающий режим для Разрешённых Правил для Почты.
    `signalRuleAllowed`, `signalRuleCondition`, `signalRuleAction`
      аналогично элементам `mailRuleAllowed`, `mailRuleCondition`, `mailRuleAction`, но для Правил Сигналов.
`skinInfo`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `skinList`.
  Атрибуты:
  `skinName`
    название Вида Web-Интерфейса.
`skinFileInfo`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `skinFileList`.
  Атрибуты:
  `skinName`
    название Вида Web-Интерфейса.
  `fileName`
    имя файла.
  `size`
    размер файла в байтах.
  `timeModified`
    опциональный атрибут, в котором находится дата и время изменения файла (местное время).
`skinFileData`
  Это сообщение отправляется, когда Сервер обрабатывает запрос `skinFileRead`.
  Атрибуты:
  `fileName`
    имя файла для чтения.
  `timeModified`
    дата и время изменения файла (местное время).
  Тело:
    Либо текст с данными файла, либо элемент `base64`. Текстовым телом этот XML элемента являются данные файла в кодировке base64 (кодировка base64 позволяет вам получать двоичные данные).
`cliResult`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `cliExecute`.
  Тело:
    текстовое или XML представление результата работы команды CLI.
  Пример:
  Клиент читает некоторые из псевдонимов Пользователя.
  C:<cliExecute id="A001">GETACCOUNTALIASES user@domain.com<cliExecute/>
  S:<cliResult id="A001">(alias1,alias2)</strings>
  S:<response id="A001"/>
  C:<cliExecute id="A002" report="xml">GETACCOUNTALIASES user@domain.com<cliExecute/>
  S:<cliResult id="A002"><subValue>alias1</subValue><subValue>alias2</subValue></strings>
  S:<response id="A002"/>
`retrievedXML`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `retrieveXML`.
  Атрибуты:
  `url`
    URL документа.
  Тело:
    один XML документ, в котором содержится полученный документ.
`retrievedURL`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `retrieveURL`.
  Атрибуты:
  `url`
    URL документа.
  `responseCode`
    числовой код HTTP-ответа.
  `Content-Type`
    тип содержимого тела ответа (опционально).
  `Content-Subtype`
    подтип содержимого тела ответа (опционально).
  `charset`
    кодировка тела ответа (опционально).
  `Date`, `Last-Modified`, `Expires`
    значения полей заголовка ответа в формате даты-времени iCalendar (опционально).
  `Server`, `Location`, `Set-Cookie`
    значения полей заголовка ответа (опционально).
  Тело:
    используется один из следующих форматов:
    - XML элемент, если типом содержимого ответа является text/xml и разбор XML был проведён успешно.
    - текст, если типом содержимого ответа является любой не-XML тип text/*.
    - для всех других типов содержимого - элемент `base64`, в котором содержатся данные в кодировке base64.
`speller`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `spellerList`.
  Атрибуты:
  `speller`
    имя программы для проверки орфографии, обычно - название языка или название диалекта (такое, как English-US или French-CA).
`spellerReport`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `spellerCheck` и обнаруживает ошибку орфографии.
  Атрибуты:
  `position`
    позиция неверно написанного слова в отправленном тексте.
  `size`
    размер неверно написанного слова в отправленном тексте (в байтах).
  Тело:
    ноль, один или несколько XML элементов `guess`. Текст тела каждого элемента является предлагаемой заменой для неверно написанного слова.
  Обратите внимание: отправляемый текст сначала декодируется из XML и в атрибутах указывает позиция слова и размер в результирующем декодированном тексте (который должен быть в кодировке UTF-8).

## Управление Папкой

Клиент может использовать следующий набор операций для работы с Папками аутентифицированного Пользователя, а также с Папками других Пользователей (указывая полное имя Папки в виде `~accountName@domainName/mailboxName`).

Обратите внимание: все не ASCII имена Папок задаются в кодировке UTF-8 (используемый в IMAP метод UTF-7 не применяется).

`mailboxCreate`
  Эта операция создаёт новую Папку.
  Атрибуты:
  `mailbox`
    в этом атрибуте задаётся имя новой Папки.
  `mailboxClass`
    этот опциональный атрибут указывает класс Папки.
`mailboxRename`
  Эта операция переименовывает Папку.
  Атрибуты:
  `mailbox`
    в этом атрибуте задаётся имя существующей Папки.
  `newName`
    в этом атрибуте задаётся имя новой Папки.
  `children`
    если этот опциональный атрибут присутствует, то все "дети" Папки (вложенные Папки) также переименовываются.
`mailboxRemove`
  Эта операция удаляет Папку.
  Атрибуты:
  `mailbox`
    имя существующей Папки.
  `children`
    если этот опциональный атрибут присутствует, то удаляются также и все "дети" Папки (вложенные Папки).
`mailboxList`
  Эта операция заставляет Сервер отправить сообщение данных `mailbox` (смотрите ниже) для каждой видимой Папки (Папки, к которой аутентифицированный Пользователь имеет Права Доступа Видеть).
  Атрибуты:
  `filter`
    в этом опциональном атрибуте задаётся строка с фильтром в формате протокола IMAP.
  `mailboxClass`
    если этот опциональный атрибут указан, то перечисляются только Папки указанного класса. Укажите значение пустая строка для перечисления только Папок с классом "mail".
  `pureFolder`
    если этот опциональный атрибут существует и его значением является yes, то в результат включаются "чистые" папки; если его значением является `no`, то "чистые" папки не включаются.
    Подробности смотрите в описании сообщения данных `mailbox`.
`mailboxSubList`
  Эта операция заставляет Сервер отправить сообщение данных `mailboxSubscription` (смотрите ниже) для каждого элемента из набора подписанных папок Пользователя. Заметьте, что Папок в этом наборе может и не быть.
  Атрибуты:
  `filter`
    в этом опциональном атрибуте задаётся строка с фильтром в формате протокола IMAP.
`mailboxSubUpdate`
  Эта операция изменяет набор подписанных папок Пользователя.
  Тело:
    набор элементов `mailboxSubscription`.
    Атрибуты:
    `mailbox`
      имя папки в кодировке UTF-8.
    `mode`
      если значением этого атрибута является `add`, то имя `mailbox`добавляется в набор подписанных Папок (за исключением случая, когда в наборе уже имеется папка с таким именем).
      в противном случае, имя `mailbox` удаляется из набора подписанных папок.
`mailboxAliasList`
  Эта операция заставляет Сервер отправить сообщение данных `mailboxAlias` (смотрите ниже) для каждого Псевдонима Папки для текущего Пользователя.
`mailboxAliasUpdate`
  Эта операция изменяет набор Псевдонимов Папок Пользователя.
  Тело:
    набор XML элементов `mailboxAlias`.
    Атрибуты:
    `name`
      Имя Псевдонима Папки в кодировке UTF-8.
    `mode`
      если значением этого атрибута является `add`, то имя Псевдоним `name`добавляется в набор Псевдонимов Папки. Если в наборе уже имеется Псевдоним с таким именем, то он замещается.
      в противном случае, Псевдоним `name` удаляется из набора Псевдонимов Папки.
    Тело:
      строка: имя требуемой Папки в кодировке UTF-8.
`mailboxRightsGet`
  Эта операция заставляет Сервер отправить сообщение данных `mailboxRight` (смотрите ниже) с правами доступа к указанной Папке.
  Атрибуты:
  `mailbox`
    имя существующей Папки.
`mailboxACLList`
  Эта операция заставляет Сервер отправить сообщение данных `mailboxACL` с данными из Списка Прав Доступа к Папке.
  Атрибуты:
  `mailbox`
    имя существующей Папки.
`mailboxACLUpdate`
  Эта операция изменяет Список Прав Права Доступа к Папке для указанной Папки.
  Атрибуты:
  `mailbox`
    имя существующей Папки.
  Тело:
    Набор XML элементов `aclElem`:
    Атрибуты:
    `pattern`
      "имя" элемента ACL. Оно может быть именем Пользователя, именем с префиксом "+" или "-" и т.д. Дополнительную информацию смотрите в разделе Список Прав Доступа к Папке.
    `mode`
      если этот опциональный атрибут имеет значение `add`, то указанные права добавляются к набору прав, уже заданных для этого элемента ACL. Если элемент ACL не существует, то он будет создан.
      если этот опциональный атрибут имеет значение `sub`, то указанные права убираются из набора прав, заданных для этого элемента ACL.
      если этот опциональный атрибут имеет значение `clear`, то этот элемент ACL удаляется.
      если этот опциональный атрибут имеет любое другое значение или этот атрибут отсутствует, то указанные права замещают набор прав, уже заданный для этого элемента ACL. Если элемент ACL не существует, то он будет создан.
    Тело:
      строка; каждый символ определяет Права Доступа к Папке.

Сервер отправляет следующие сообщения данных:

`mailbox`
  Эти синхронные сообщения данных отправляются, когда Сервер обрабатывает запрос `mailboxList`.
  Атрибуты:
  `mailbox`
    имя Папки в кодировке UTF-8.
  `UIDVALIDITY`, `MESSAGES`, `UIDNEXT`, `UNSEEN`, `OLDEST`, `CLASS`, `MEDIA`, `UNSEENMEDIA`
    стандартные и расширенные атрибуты IMAP.
  `SIZE`
    размер папки (внутренний, аналогично INTERNALSIZE для IMAP).
  `pureFolder`
    этот атрибут существует и имеет значение yes, если Папка является папкой в строгом смысле и не может содержать сообщений, но может содержать Подпапки.
    Обратите внимание: Папка рассматривается как папка в строгом смысле если она может содержать сообщения, но класс Папки не соответствует классу, указанному в запросе `mailboxList`.
  `isFolder`
    этот атрибут существует и имеет значение yes, если Папка является обычной папкой - то есть может содержать сообщения и может содержать Подпапки.
  `rights`
    действующие права доступа к Папке. Если этот атрибут отсутствует, то доступ к Папке не ограничен.
`mailboxSubscription`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `mailboxSubList`.
  Атрибуты:
  `mailbox`
    имя Папки в кодировке UTF-8.
`mailboxAlias`
  Эти сообщения отправляются, когда Сервер обрабатывает запрос `mailboxSubList`.
  Атрибуты:
  `name`
    Имя Псевдонима Папки в кодировке UTF-8.
  Тело:
    строка; имя требуемой Папки в кодировке UTF-8.
`mailboxRights`
  Это сообщение отправляется, когда Сервер обрабатывает запрос `mailboxRightsGet`.
  Атрибуты:
  `mailbox`
    имя Папки.
  Тело:
    строка; каждый символ определяет фактически действующие Права Доступа к Папке, предоставленные текущему пользователю.
`mailboxACL`
  Это сообщение отправляется, когда Сервер обрабатывает запрос `mailboxACLList`.
  Атрибуты:
  `mailbox`
    имя Папки.
  Тело:
    Набор XML элементов `aclElem`, один элемент для каждого элемента из Списка Прав Доступа к Папке:
    Атрибуты:
    `pattern`
      "имя" элемента ACL. Оно может быть именем Пользователя, именем с префиксом "+" или "-" и т.д. Дополнительную информацию смотрите в разделе Список Прав Доступа к Папке.
    Тело:
      строка; каждый символ определяет Права Доступа к Папке, предоставленные или забранные от "имени".

Пример:

- A001: Клиент просит Сервер создать Папку типа Блокнот `MyNotes`.
- A002: Клиент просит Сервер переименовать папку `MyNotes` в `SharedNotes`.
- A003: Клиент просит Сервер предоставить права Видеть (Lookup) и Входить (Select) к Папке `SharedNotes` пользователям `user1` и `user2`.
- A004: Клиент просит Сервер добавить права Удалить (Delete) и Добавить (Inser) для Папки `SharedNotes` пользователям `user1` и забрать право Входить у пользователя `user2`.
- A005: Клиент просит Сервер получать ACL данные для Папки `SharedNotes`.

C:<mailboxCreate id="A001" mailbox="MyNotes" mailboxClass="IPF.StickyNote" />
S:<response id="A001"/>
C:<mailboxRename id="A002" mailbox="MyNotes" newName="SharedNotes" />
S:<response id="A002"/>
C:<mailboxACLUpdate id="A003" mailbox="SharedNotes">
<aclElem pattern="user1">lr</aclElem>
<aclElem pattern="user2">lr</aclElem>
</mailboxACLUpdate>
S:<response id="A003"/>
C:<mailboxACLUpdate id="A004" mailbox="SharedNotes">
<aclElem pattern="user1" mode="add">di</aclElem>
<aclElem pattern="user2" mode="sub">r</aclElem>
</mailboxACLUpdate>
S:<response id="A004"/>
C:<mailboxACLList id="A005" mailbox="SharedNotes"/>
S:<mailboxACL id="A005" mailbox="SharedNotes">
<aclElem pattern="user1">lrdi</aclElem>
<aclElem pattern="user2">l</aclElem>
</mailboxACL>
S:<response id="A005"/>

## Операции с Папкой

Клиент может использовать следующий набор операций для работы с Папками аутентифицированного Пользователя, а также с Папками других Пользователей (указывая полное имя Папки в виде `~accountName@domainName/mailboxName`).

`folderOpen`
  Эта операция открывает указанную Папку как "Представление Папки" ("Folder").
  Представление Папки представляет собой Папку Сервера, в которой сообщения были отсортированы и, опционально, отфильтрованы.
  Каждое представление папки имеет имя; в одной сессии не может быть двух представлений с одинаковыми именами. С другой стороны, в одной сессии могут быть открыто два различных преставления (с разными именами) для одной и той же Папки. Например, приложение может использовать одно представление для показа содержимого Папки, отсортированным по полю Дата, а в другом окне будет оно будет показывать ту же Папку, но отсортированную по полю От Кого и только с теми сообщениями, в поле Keywords которых имеется тэг `Business`.
  Когда в Папку добавляются сообщения (а также, когда сообщения изменяются или удаляются), Сервер уведомляет об этих изменениях всех клиентов, открывших какое-либо Представление этой Папки.
  Для каждого представления уведомление об изменениях отправляется независимо, так что клиенту нет необходимости знать, что два представления папки фактически показывают разные виды одной и той же Папки Сервера.
  Атрибуты:
  `folder`
    имя нового Представления папки, которое необходимо открыть. В качестве имени Представления клиент может использовать произвольную строку.
  `mailbox`
    имя Папки. Если этот атрибут не указан, то используется имя представления папки.
  `mailboxClass`
    опциональный атрибут. Если указанная Папка не существует и этот опциональный атрибут указан, то указанная Папка будет создана.
    Если значением этого атрибута является непустая строка, то это значение используется как Класс Папки для создаваемой Папки.
  `sortField`
    имя поля заголовка сообщения, используемое для сортировки Папки.
  `sortOrder`
    если этот опциональный атрибут задан и имеет значение `desc`, то применяется обратный порядок сортировки.
  `filter`
    если этот опциональный атрибут указан, то в представление папки включаются только те сообщения, которые соответствуют значению этого атрибута.
  `filterField`
    если этот опциональный атрибут указан, то его значение задаёт поле заголовка сообщения для сравнения с атрибутом filter. В представление папки включаются только те сообщения, у которых указанное поле существует и значение которого соответствует значению атрибута filter.
    Если значением атрибута является `FLAGS`, то значение атрибута `filter` должно быть разделённым через запятую списком имён флагов сообщения и/или обратных имён флагов сообщения (negative names). В представление папки включаются только те сообщения, которые содержат указанный набор флагов и набор обратных флагов. Например, атрибут filter="Media,Unseen" укажет Серверу построить представление папки с использованием только тех сообщений, у которых установлен флаг `Media` и не установлен флаг `Seen`.
    Если значением этого атрибута является `body`, то в представление папки включаются только те сообщения, которые содержат в какой-либо части тела сообщения значение атрибута filter.
    Если этот атрибут отсутствует, то в представление папки включаются те сообщения, которые содержат значение атрибута filter в какой-либо части тела сообщения или в любом поле заголовка сообщения.
  `UIDValidity`, `UIDMin`
    Если имеются эти опциональные числовые атрибуты и значение UIDValidity представления Папки равно значению атрибута запроса UIDValidity, то в представление Папки включаются только те сообщения, UID которых не меньше, чем значение UIDMin.
  Тело:
    тело запроса должно содержать один или более элементов `<field>`.
    Каждое тело элемента должно содержать имя поля заголовка, получаемого для каждого сообщения.
    Эти поля известны как поля просмотра.
  Могут быть указаны следующие поля просмотра и `sortField`:
  - `From`, `To`, `Cc`, `Bcc`, `Reply-To`, `Sender`, `Return-Path` или другое имя Email-field. Если заголовок сообщения содержит указанное Email-field, то оно разбирается. Если поле содержит "комментарий" (то есть "настоящее имя"), то оно используется. В противном случае разобранный адрес электронной почты не используется.
  - `Date`, `Resent-Date`. Значение даты поля конвертируется в GMT. Если элементы с такими значениями поля отправляются в сообщении `folderReport`, то они содержат атрибут `localTime`, указывающий значение поля в Часовом Поясе, выбранном для текущего пользователя.
  - любое другое имя поля заголовка (`Subject`, `X-Mailer` и т.п.). Используется MIME-декодированное значение этого поля.
  - `E-From`, `E-To`, или другое имя `E-Email-field`. Если заголовок сообщения содержит указанное Email-field, то оно разбирается и разобранный адрес электронной почты используется.
  - `Pty`. Значение поля `X-Priority` конвертируется в строки `High`, `Low` или в пустую строку.
  - `UID`. Метаданные сообщения - UID (уникальный идентификатор) в Папке.
  - `SIZE`. Метаданные сообщения - "сырой" размер сообщения в Папке.
  - `INTERNALDATE`. Метаданные сообщения - его отметка о времени. Она форматируется также, как элемент `Date`.
  - `FLAGS` - используются значения атрибутов метаданных сообщения.
    Дополнительную информацию о флагах сообщения в Папке смотрите в разделе Папки.

  Сессия может использовать несколько Представлений Папки одновременно.

Клиент должен обслуживать внутренний вид Представления папки - массив или таблицу элементов для каждого сообщения из Представления. Клиент должен держать этот вид синхронизированным с видом Сервера (реализованным в этом Представлении Папки).

При открытии Представления папки Сервер отправляет сообщение данных `folderReport`, содержащее общее число сообщений в Представлении папки. Клиент использует это число для создания первоначальной таблицы внутреннего вида и заполнения её пустыми элементами.

Для отображения содержимого Папки на экране, клиент проверяет, какой элемент из таблицы внутреннего вида он должен использовать. Если некоторые из этих элементов пустые, то клиент должен запросить Сервер отправить ему информацию об этих сообщениях Представления папки, задаваемых значениями индекса (позиции) в отсортированном виде (в Представлении Папки).

В некоторых Операциях с Папкой для задания сообщений Папки, к которым применяется операция, используется набор сообщений. Сообщения могут задаваться как по их UID, так и по номеру их индекса (по их позиции в Представлении папки).

Для задания сообщений по их UID, используйте один или более элементов `UID`.
Каждый элемент `UID` может включать в себя одно сообщение, в этом случае UID сообщения указывается как тело элемента <UID>12377</UID>.
Элемент `UID` может включать в себя диапазон UIDов сообщений, задаваемых при помощи атрибутов `from` и `till`: <UID from="12377" till="12455" />. Операция применяется ко всем сообщениям Папки, UID которых не меньше, чем значение атрибута `from` и не больше, чем значение атрибута `till`. Пожалуйста, помните, что сообщения в Представлении папки не отсортированы, вообще говоря, по их UIDам (за исключением случая использования атрибута `sortField="UID"` в операции `folderOpen`).

Для задания сообщения по индексу, используйте один или более элементов `index`.
Каждый элемент `index` может включать в себя одно сообщение, в этом случае индекс сообщения указывается как тело элемента <index>14</index>.
Элемент `index` может включать в себя диапазон индексов сообщений, задаваемых при помощи атрибутов `from` и `till`: <index from="12" till="10000" />. Операция применяется ко всем сообщениям Представления папки, позиция (индекс) которых не меньше, чем значение атрибута `from` и не больше, чем значение атрибута `till`.

Набор сообщений может включать в себя один или более элементов `UID` или же один или более элементов `index`, но он не может включать в себя одновременно элементы `UID` и `index`.

`folderBrowse`
  Эта операция заставляет Сервер отправить сообщения данных для указанного интервала индексов (позиций) в открытом Представлении папки.
  Атрибуты:
  `folder`
    имя Представления папки.
  Тело:
    набор сообщений (смотрите выше). В этом наборе сообщений разрешается использовать только элементы `index`.
  Сервер отправляет сообщение данных `folderReport` для каждого индекса из указанного диапазона. Атрибуты сообщения данных указывают индекс (позицию) сообщения в Представлении папке и UID сообщения.
  Тело сообщения данных `folderReport` содержит значения `viewer fields`.

Для синхронизации клиента с сервером используется модель "по требованию". При добавлении, изменении или удалении сообщения из Представления папки, клиент получает асинхронное сообщение данных `folderReport` со значением атрибута `mode`, установленного в значение `notify` (сообщение "notify-mode").

Новые добавленные сообщения не становятся видимыми в логическом Представлении папки, а удалённые сообщения не удаляются из логического Представления папки. Запросы на получение данных из удалённых сообщений не возвращают единицы данных или же возвращают пустые единицы данных.

Когда клиентские приложения готово обновить свой "внутренний вид", оно должно использовать операцию `folderSync`:

`folderSync`
  Эта операция предписывает Серверу отправить клиенту все ожидающие изменения Представления папки.
  Атрибуты:
  `folder`
    имя Папки.

  Сервер отправляет сообщения данных `folderReport` с атрибутом `mode`, установленным в значение `removed`, `added` или `updated`.

  После того, как Сервер отправляет "уведомительные" сообщения Клиенту, Сервер может не отправлять дальнейшие "уведомительные" сообщения для этого Представления папки до тех пор, пока клиент не выполнит операцию `folderSync` в этом Представлении папки.

Клиент может отправлять запросы на Сервер, запрашивая проведение определённых операций изменения (таких, как удаление сообщения), но он должен обновлять свой внутренний вид только когда Сервер отправляет сообщение данных `folderReport`, информирующее клиента о фактических изменениях в Представлении папки.

Обратите внимание: в отличие от UIDов, индекс сообщения в Представлении папки может изменяться каждый раз при проведении операции `folderSync`. До того, как вы начнёте любую операцию с использованием набора сообщений, базирующегося на индексах, убедитесь, что вы корректно изменили внутренний вид в соответствии со всеми сообщениями данных `folderReport`, сгенерированными предыдущей операцией `folderSync`.

Обратите внимание: если сообщение было удалено или, наоборот, добавлено в Папку, то Сервер отправляет только сообщения данных `folderReport` с атрибутом `mode="notify"`. Серверная сторона "вида" изменённого Представления Папки (логического Представления папки) не изменяется и можно безопасно использовать основывающиеся на индексах наборы сообщений для начала операции с Представлением папки.

`messageCopy`
  Эта операция копирует сообщения из открытого Представления папки в целевую Папку.
  Обратите внимание: цель является Папкой, а не Представлением папки.
  Атрибуты:
  `folder`
    имя Представления папки - источника.
  `targetMailbox`
    имя Папки - приёмника.
  `mailboxClass`
    Если Папка - приёмник не существует и этот опциональный атрибут указан, то Папка - приёмник будет создана. Если значением этого атрибута является непустая строка, то это значение используется как Класс Папки для создаваемой Папки.
  `encrypt`
    если этот опциональный атрибут существует и имеет значение yes, то все сообщения копируются в зашифрованном виде с использованием S/MIME Сертификата текущего пользователя.
  Тело:
    набор сообщений (смотрите выше).
`messageMove`
  Эта операция аналогична операции `messageCopy`, но если сообщение было скопировано успешно, то операция удаляет оригинальное сообщение.

  Эта операция также может быть использована для реализации "шифрования сообщений": выбранные сообщения должны быть передвинуты в ту же Папку с использованием атрибута `encrypt` операции.

`messageMark`
  Эта операция изменяет флаги сообщения Папки в открытом Представлении папки.
  Атрибуты:
  `folder`
    имя Представления папки.
  `flags`
    этот атрибут задаёт добавляемые или удаляемые флаги сообщения Папки. Могут быть указаны несколько операций, отделённые символом запятой. Дополнительную информацию смотрите в разделе Папки.
  Тело:
    набор сообщений (смотрите выше).
`messageRemove`
  Эта операция удаляет сообщения из открытого Представления папки.
  Атрибуты:
  `folder`
    имя Представления папки.
  Тело:
    набор сообщений (смотрите выше).
  Операция проверяет настройку Пользователя `DeleteMode` и действует в зависимости от её значения:
  - `Немедленно` - сообщения физически удаляются из Папки.
  - `Перенести в Корзину` - сообщения передвигаются в Мусорную Корзину (её имя указывается в настройке Пользователя `TrashBox`). Если указанное Представление папки является Папкой Мусорной Корзины, то сообщения удаляются физически.
  - `Пометить` - сообщения помечаются флагом Deleted.
`folderExpunge`
  Эта операция удаляет все сообщения, помеченные флагом `Deleted` из Папки.
  Обратите внимание: она удаляет ВСЕ отмеченные сообщения Папки, а не только сообщения, видимые в этом Представлении папки.
  Атрибуты:
  `folder`
    имя Представления папки.
`folderClose`
  Эта операция закрывает открытое Представления папки.
  Атрибуты:
  `folder`
    имя Представления папки.
`folderReopen`
  Эта операция перестраивает открытое Представление папки, повторно сканируя Папку с использованием других параметров сортировки и других фильтров.
  Атрибуты:
  `folder`
    имя Представления папки.
  `sortField`, `sortOrder`, `filter`, `filterField`, `UIDValidity`, `UIDMin`
    эти атрибуты имеют тот же смысл, что и атрибуты операции `folderOpen`.
  Тело:
    если тело запроса содержит хотя бы один элемент `<field>`, то такие элементы задают новый набор полей просмотра. Если не указано ни одного элемента `<field>`, то набор полей просмотра не изменяется.

  Когда клиент использует эту команду, Сервер отправляет сообщение `folderReport` с атрибутом `mode`, установленным в значение `init`, уведомляя клиента о размере нового Представления папки.
  Клиент должен очистить свой внутренний вид Представления папки и заново заполнить его.

  Обратите внимание: если Клиент получает сообщение `folderReport` с атрибутом `mode`, установленным в значение `notify`, то после отправления Клиентом команды `folderReopen`, Клиент должен использовать команду `folderSync` по получению ответа на команду `folderReopen`.

`emptyTrash`
  Эта операция физически удаляет все сообщения из Папки - Мусорной Корзины (если она задана).

Сервер отправляет следующие сообщения данных:

`folderReport`
  Эти сообщения отправляются синхронно, когда Представление папки открывается или переоткрывается, а также когда клиент отправляет запросы `folderBrowse` или `folderSync`.
  Эти сообщения отправляются асинхронно, когда статус Представления папки изменяется (сообщения добавляются, изменяются или удаляются), в этом случае атрибут `mode` устанавливается в `notify`.
  Атрибуты:
  `folder`
    имя Представления папки.
  `mode`
    в этом опциональном атрибуте задаётся тип уведомления.
    - Если значением атрибута является `init`, то атрибут `messages` указывает общее число сообщений в Представлении папки, а атрибут `unseen` указывает общее число непрочитанных сообщений (сообщений без флага Seen) в Представлении папки.
      Это асинхронное сообщение данных отправляется, когда Представление папки открывается или переоткрывается.
    - Если значением атрибута является `notify`, то некоторые сообщения Папки были добавлены, изменены или удалены.
      Это сообщение отправляется как асинхронное сообщение данных.
      Ожидается, что в ответ клиент направит запрос `folderSync` для этого Представления папки.
    - Если значением атрибута является `removed`, то атрибуты `index` и `UID` указывают сообщение, удаляемое из Представления папки.
      Это сообщение данных отправляется в ответ на запрос `folderSync`.
      Клиент должен немедленно изменить свой внутренний вид: для всех сообщений со значениями индекса большими, чем указано в значении атрибута `index`, значение индекса уменьшается на 1.
    - Если значением атрибута является `added`, то атрибуты `index` и `UID`, задающие сообщение, добавляются в Представление папки.
      Это сообщение данных отправляется в ответ на запрос `folderSync`.
      Клиент должен немедленно изменить свой внутренний вид: для всех сообщений со значениями индекса большими либо равными, чем указано в значении атрибута `index`, значение индекса увеличивается на 1.
    - Если значением атрибута является `updated` или атрибут отсутствует, то атрибуты `index` и `UID` задают сообщение Папки и в теле содержатся значения полей просмотра сообщения.
  `index`
    индекс сообщения в этом Представлении папки.
    Этот атрибут не присутствует, когда значением атрибута `mode` является `init`.
  `UID`
    идентификатор сообщения (уникальный UID).
    Этот атрибут не присутствует, когда значением атрибута `mode` является `removed`, `updated` или `added`.
  `messages`
    общее число сообщений в этом Представлении папки.
    Этот атрибут не присутствует, когда значением атрибута `mode` является `init`, `removed`, или `added`.
  `unseen`
    общее число непрочитанных сообщений в этом Представлении папки.
    Этот атрибут присутствует, когда значением атрибута `mode` является `init`, `removed`, `updated` или `added`.
  `rights`
    действующие права доступа для Представления папки.
    Этот атрибут присутствует, когда значением атрибута `mode` является `init`. Если этот атрибут отсутствует, то доступ к Представлению папки не ограничен.
  `UIDValidity`
    значение UIDValidity Папки.
    Этот атрибут присутствует, когда значением атрибута `mode` является `init`.
  Тело:
    Тело присутствует, когда значением атрибута `mode` является `updated` или `added`.
    Оно содержит набор элементов со значениями поля просмотра.

Пример 1:

- A001: Клиент просит Сервер открыть Папку INBOX как Представление папки "INBOX" и отсортировать её по полю INTERNALDATE (которое является не фактическим полем сообщения, а элементом метаданных сообщения, указывающим время поступления сообщения в Папку). Клиент информирует Сервер, что ему необходимо получить поля FLAGS, From и Subject сообщений Папки.
- Сервер открывает Папку INBOX и сортирует её; Сервер информирует Клиента, что в Представлении папки имеется 234 сообщения.
- A002: Клиент просит Сервер отправить ему данные первых 4 сообщений, находящихся в Представлении папки и Сервер отправляет эту информацию Клиенту.
- Пока Сервер обрабатывал этот запрос, в Папку добавляется одно сообщение.
- после того, как Сервер отправил сообщение с ответом, сообщения 2 и 35 из Представления папки удаляются.
- A003: Клиент снова просит Сервер отправить ему данные первых 4 сообщений, находящихся в отсортированном Представлении папки.
- A004: Клиент просит Сервер отправить ему все изменения Представления папки.
- Сервер информирует Клиента о том, что сообщение с номером 35 удаляется. Клиент должен удалить элемент номер 35 из своей таблицы внутреннего вида и, если необходимо, обновить информацию на экране. Общее число сообщений в Представлении папки изменяется на 233.
- Сервер информирует Клиента о том, что сообщение с номером 2 удаляется. Клиент должен удалить элемент номер 2 из своей таблицы внутреннего вида. Сообщение номер 3 становится сообщением номер 2, сообщение номер 4 становится сообщением номер 3 и т.д.
- Сервер добавляет новое сообщение в Представление папки и информирует Клиента о том, что он вставил это сообщение как сообщение номер 1. Клиент должен обновить свою таблицу внутреннего вида, вставив в неё новый элемент как элемент номер 1. Элемент номер 1 становится сообщением номер 2, элемент номер 2 становится элементом номер 3 и т.д.
- A005: Клиент снова просит Сервер отправить ему данные первых 4 сообщений, находящихся в Представлении папки.

C:<folderOpen id="A001" folder="INBOX" mailbox="INBOX" sortField="INTERNALDATE" sortOrder="asc">
<field>FLAGS</field><field>From</field><field>Subject</field>
</folderOpen>
S:<folderReport id="A001" folder="INBOX" mode="init" messages="234" unseen="12" />
S:<response id="A001"/>
C:<folderBrowse id="A002" folder="INBOX"><index from="0" till="3" /></folderBrowse>
S:<folderReport id="A002" folder="INBOX" index="0" UID="123">
<FLAGS>Seen,Deleted</FLAGS><From>John H. Smith</From>
<Subject>Hello - just a test</Subject>
</folderReport>
S:<folderReport id="A002" folder="INBOX" index="1" UID="543">
<FLAGS>Seen,Answered</FLAGS><From>Jim Spammer</From>
<Subject>This is the best offer!</Subject>
</folderReport>
S:<folderReport id="A002" folder="INBOX" index="2" UID="343">
<FLAGS>Seen,Media</FLAGS><From>user@example.com</From>
<Subject>Meeting reminder</Subject>
</folderReport>
S:<folderReport folder="INBOX" mode="notify" />
S:<folderReport id="A002" folder="INBOX" index="3" UID="512">
<FLAGS>Seen,Flagged</FLAGS><From>Admin@hq.example.com</From>
<Subject>Shutdown @ 4:45AM</Subject>
</folderReport>
S:<response id="A002" />
S:<folderReport folder="INBOX" mode="notify" />
C:<folderBrowse id="A003" folder="INBOX"><index from="0" till="3" /></folderBrowse>
S:<folderReport id="A003" folder="INBOX" index="0" UID="123">
<FLAGS>Seen,Deleted</FLAGS><From>John H. Smith</From>
<Subject>Hello - just a test</Subject>
</folderReport>
S:<folderReport id="A003" folder="INBOX" index="1" UID="543">
<FLAGS>Seen,Answered</FLAGS><From>Jim Spammer</From>
<Subject>This is the best offer!</Subject>
</folderReport>
S:<folderReport id="A003" folder="INBOX" index="2" UID="343">
<FLAGS>Seen,Media</FLAGS><From></From>
<Subject></Subject>
</folderReport>
S:<folderReport id="A003" folder="INBOX" index="3" UID="512">
<FLAGS>Seen,Flagged</FLAGS><From>Admin@hq.example.com</From>
<Subject>Shutdown @ 4:45AM</Subject>
</folderReport>
S:<response id="A003" />
C:<folderSync id="A004" folder="INBOX" />
S:<folderReport id="A004" folder="INBOX" index="35" UID="117" mode="deleted" messages="233" unseen="11" />
S:<folderReport id="A004" folder="INBOX" index="2" UID="343" mode="deleted" messages="232" unseen="11" />
S:<folderReport id="A004" folder="INBOX" index="1" UID="976" mode="added" messages="233" unseen="12" >
<FLAGS>Recent</FLAGS><From>CGatePro Discussions</From>
<Subject>[CGP] Re: Session Timer?</Subject>
</folderReport>
S:<response id="A004" />
C:<folderBrowse id="A005" folder="INBOX"><index from="0" till="3" /></folderBrowse>
S:<folderReport id="A005" folder="INBOX" index="0" UID="123">
<FLAGS>Seen,Deleted</FLAGS><From>John H. Smith</From>
<Subject>Hello - just a test</Subject>
</folderReport>
S:<folderReport id="A005" folder="INBOX" index="1" UID="976">
<FLAGS>Recent</FLAGS><From>CGatePro Discussions</From>
<Subject>[CGP] Re: Session Timer?</Subject>
</folderReport>
S:<folderReport id="A005" folder="INBOX" index="2" UID="543">
<FLAGS>Seen,Answered</FLAGS><From>Jim Spammer</From>
<Subject>This is the best offer!</Subject>
</folderReport>
S:<folderReport id="A005" folder="INBOX" index="3" UID="512">
<FLAGS>Seen,Flagged</FLAGS><From>Admin@hq.example.com</From>
<Subject>Shutdown @ 4:45AM</Subject>
</folderReport>
S:<response id="A005" />

Пример 2:

- A010: Клиент просит Сервер скопировать 3 сообщения из уже открытой Папки INBOX в Папку Archive
- Папка Archive будет открыта и Сервер отправляет Клиенту сообщение уведомления

C:<messageCopy id="A010" folder="INBOX" targetMailbox="Archive">
<UID>512</UID><UID>123</UID><UID>976</UID>
</messageCopy>
S:<folderReport folder="Archive" mode="notify" />
S:<response id="A010"/>

Пример 3:

- A020: Клиент просит Сервер отметить 3 сообщения (UIDы 512, 123 и 976) флагом Deleted.
- Сервер устанавливает эти флаги и отправляет Клиенту сообщение уведомления.
- A021: Клиент просит Сервер отправить ему все изменения Папки.
- Сервер отправляет изменённую информацию для сообщения с UID 512 и сообщения с UID 976. У сообщения с UID 123 флаг Deleted уже установлен, так что запрос не изменяет это сообщение и Сервер не отправляет информацию для этого сообщения.
- A022: Клиент просит Сервер вычистить Папку.
- Сервер удаляет сообщения с UIDами 512, 123 и 976, а также сообщения с UIDами 446 и 756, у которых, как оказалось, флаг Deleted тоже был установлен. Сервер отправляет Клиенту сообщение уведомления.
- A023: Клиент просит Сервер отправить ему все изменения Папки.
- Сервер отправляет сообщения данных, информируя клиента, что он удалил сообщения с UIDами 512, 123, 976, 446 и 756 из отсортированного вида Папки.
- A024: Клиент закрывает Папку INBOX.

C:<messageMark id="A020" folder="INBOX" flags="Deleted">
<UID>512</UID><UID>123</UID><UID>976</UID>
</messageMark>
S:<folderReport folder="INBOX" mode="notify" />
S:<response id="A020"/>
C:<folderSync id="A021" folder="INBOX" />
S:<folderReport id="A021" folder="INBOX" index="1" UID="976" mode="updated" unseen="12" >
<FLAGS>Recent,Deleted</FLAGS><From>CGatePro Discussions</From>
<Subject>[CGP] Re: Session Timer?</Subject>
</folderReport>
S:<folderReport id="A021" folder="INBOX" index="3" UID="512" mode="updated" unseen="12" >
<FLAGS>Seen,Deleted,Flagged</FLAGS><From>Admin@hq.example.com</From>
<Subject>Shutdown @ 4:45AM</Subject>
</folderReport>
S:<response id="A021"/>
C:<folderExpunge id="A022" folder="INBOX" />
S:<folderReport folder="INBOX" mode="notify" />
S:<response id="A022"/>
C:<folderSync id="A023" folder="INBOX" />
S:<folderReport id="A023" folder="INBOX" index="0" UID="123" mode="deleted" messages="232" unseen="12" />
S:<folderReport id="A023" folder="INBOX" index="0" UID="976" mode="deleted" messages="231" unseen="11" />
S:<folderReport id="A023" folder="INBOX" index="29" UID="446" mode="deleted" messages="230" unseen="11" />
S:<folderReport id="A023" folder="INBOX" index="123" UID="756" mode="deleted" messages="229" unseen="11" />
S:<folderReport id="A023" folder="INBOX" index="1" UID="512" mode="deleted" messages="228" unseen="11" />
S:<response id="A023"/>
C:<closeMailbox id="A024" folder="INBOX" />
S:<response id="A024"/>

## Операции с Сообщениями

Для получения Сообщений из Папок клиент может использовать следующий набор операций.

`folderRead`
  Эта операция указывает Серверу получить Сообщение или его часть. Оно отправляется клиенту как сообщение данных `folderMessage`.
  Атрибуты:
  `folder`
    имя Представления папки.
  `UID`
    UID сообщения.
  `partID`
    в этом опциональном атрибуте задаётся часть сообщения, которую необходимо прочитать. Если он не указан, то читается всё сообщение.
  `mode`
    если этот опциональный атрибут установлен в `replyFrom` или `replyAll`, то атрибут partID должен либо отсутствовать, либо указывать элемент подчасти `EMail`. Телом сообщения ответа `folderMessage` является элемент `EMail` с пресозданным ответом на электронную почту.
  `totalSizeLimit`
    максимальный общий размер всех возвращаемых частей сообщений.
`messageAppend`
  Эта операция предписывает серверу сформировать Сообщение и добавить его в открытое представление папки или в произвольную Папку.
  Атрибуты:
  `folder`
    имя целевого Представления папки. Если оно указано, то атрибут `targetMailbox` игнорируется.
  `targetMailbox`
    имя Папки - приёмника. Если атрибут `folder` отсутствует, то оно должно быть указано.
  `mailboxClass`
    этот опциональный атрибут может быть указан, если указан атрибут `targetMailbox`.
    Если Папка - приёмник не существует и этот опциональный атрибут указан, то Папка - приёмник будет создана. Если значением этого атрибута является непустая строка, то это значение используется как Класс Папки для создаваемой Папки.
  `flags`
    этот опциональный атрибут задаёт флаги, которые создаваемое сообщение будет иметь в Папке. Могут быть указаны несколько флагов, разделённые символом запятой. Дополнительную информацию смотрите в разделе Папки.
  `internalDate`
    в этом опциональном атрибуте задаётся "внутренняя отметка о времени" для создаваемого сообщения. Если этот параметр не указан, то используется текущее время.
  `replacesUID`
    этот опциональный атрибут может быть указан, если задан атрибут `folder`.
    Если сообщение было успешно создано и добавлено в Представление папки, то сообщение с UID `replacesUID` удаляется из Представления папки.
  `checkOld`
    этот опциональный атрибут может быть указан, если задан атрибут `replacesUID`. Если этот атрибут существует, то он должен иметь значение yes.
    Если этот атрибут указан, то операция заканчивается неуспешно если в Папке не содержится сообщения с UID `replacesUID`. Это позволяет проверить что операции append/delete выполняются атомарно.
  `report`
    этот опциональный атрибут может быть указан, если задан атрибут `folder`. Если этот атрибут задан, то он должен иметь значение `uid`.
    Если сообщение было успешно создано и добавлено в Представление папки, то Сервер отправляет синхронное сообщение `messageAdded`, содержащее UID нового добавленного сообщения.
  Тело:
    XML представление Сообщения (данные `EMail`).
    Текстовые части XML представления сообщения должны использовать в качестве символа EOL символ Перевода Строки (0x0A).
    Если XML представление не включает поля `Message-ID` или `Date`, то сервер создаёт эти поля сообщения самостоятельно.

  Пример:
  Клиент добавляет простое текстовое сообщение с флагами `Seen` и `Answered` в Папку "Sent". Если Папка не существует, то она создаётся.
  C:<messageAppend id="A001" targetMailbox="Sent" flags="Seen,Answered" mailboxClass="" >
  <EMail>
  <From realName="Sender Name">fromName@domain</From><Subject>I'll be there!</Subject>
  <To realName="Recipient Name">toName@domain</To><X-Mailer>SuperClient v7.77</X-Mailer>
  <MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
  </EMail>
  </messageAppend>
  S:<response id="A001"/>
  Эта операция добавляет в Папку следующее сообщение:
  From: "Sender Name" <fromName@domain>
  Subject: I'll be there!
  To: "Recipient Name" <toName@domain>
  X-Mailer: SuperClient v7.77
  Date: Wed, 21 Jun 2006 21:51:24 -0800
  Message-ID: <ximss-38150012@this.server.dom>
  Content-Type: text/plain; charset="utf-8"
  Dear Susan,
  I will come to your place tomorrow, thank you for the invitation!
  Mary.

  Для того, что бы создать сообщения с вложенными файлами, сначала поместите файлы в "набор загруженных файлов". Затем вы можете указать их в элементах MIME, используя атрибут `uploadID`.
  Вы можете указывать атрибуты `type`, `subtype` и (для текстовых файлов) атрибут `charset`. Если вы не указываете явно эти атрибуты, то они копируются из поля Content-Type HTTP запроса, который использовался при загрузке файла.

  Пример:
  Сначала клиент загружает 2 файла - `test.gif` (используя uploadID `att01`) и `sample.pdf` (используя uploadID `att02`). Затем клиент добавляет сообщение в Представление папки "Drafts" с флагом сообщения "Draft", заменяя существующее сообщение с UID 578.
  В сообщении содержится некоторый текст в alternative форматах (plain и html) и загруженные файлы как вложения.
  Клиент указывает Серверу отправить UID нового созданного сообщения (756).
  Пока клиент добавлял новое сообщение, другой процесс добавил другие сообщения (с UID=755) в Папку "Drafts".
  Затем клиент очищает "набор загруженных файлов" и повторно синхронизирует своё состояние с Представлением папки "Drafts".
  C:<messageAppend id="A001" folder="Drafts" flags="Draft,Seen" replacesUID="578" report="uid" >
  <EMail>
  <From realName="Sender Name">fromName@domain</From><Subject>Text with attachments</Subject>
  <To realName="Recipient Name">toName@domain</To><X-Mailer>SuperClient v7.77</X-Mailer>
  <MIME type="multipart" subtype="mixed">
  <MIME type="multipart" subtype="alternative">
  <MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
  <MIME type="text" subtype="html">&lt;html&gt;&lt;body&gt;&lt;i&gt;Dear Susan,&lt;/i&gt;&lt;p&gt;I will come to your place tomorrow, thank you for the invitation!&lt;p&gt;&lt;i&gt;Mary.&lt;/i&gt;</MIME>
  </MIME>
  <MIME uploadID="att01" />
  <MIME uploadID="att02" type="application" subtype="pdf" />
  </MIME>
  </EMail>
  </messageAppend>
  S:<folderReport folder="Drafts" mode="notify" />
  S:<messageAdded id="A001" folder="Drafts" UID="756" />
  S:<response id="A001"/>
  C:<clearUploaded id="A002" />
  S:<response id="A002"/>
  C:<folderSync id="A003" folder="Drafts"/>
  S:<folderReport id="A003" folder="Drafts" index="17" UID="578" mode="removed" messages="301" unseen="0"/>
  S:<folderReport id="A003" folder="Drafts" index="127" UID="755" mode="added" messages="302" unseen="1">
  <FLAGS>Recent,Drafts</FLAGS>
  <From>Other Name</From>
  </folderReport>
  S:<folderReport id="A003" folder="Drafts" index="17" UID="756" mode="added" messages="303" unseen="1" >
  <FLAGS>Recent,Drafts,Seen</FLAGS>
  <From>Sender Name</From>
  </folderReport>
  S:<response id="A003"/>
  Эта операция добавляет в Папку следующее сообщение:
  From: "Sender Name" <fromName@domain>
  Subject: Text with attachments
  To: "Recipient Name" <toName@domain>
  X-Mailer: SuperClient v7.77
  Date: Wed, 21 Jun 2006 21:59:55 -0800
  Message-ID: <ximss-38330025@my.server.domain>
  Content-Type: multipart/mixed; boundary="_===38330025====my.server.domain===_"
  --_===38330025====my.server.domain===_
  Content-Type: multipart/alternative; boundary="_===38330025-X====my.server.domain===_"
  --_===38330025-X====my.server.domain===_
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 8bit
  Dear Susan,
  I will come to your place tomorrow, thank you for the invitation!
  Mary.
  --_===38330025-X====my.server.domain===_
  Content-Type: text/html; charset="utf-8"
  Content-Transfer-Encoding: 8bit
  <html><body><i>Dear Susan,</i><p>I will come to your place tomorrow, thank you for the invitation!<p><i>Mary.</i>
  --_===38330025-X====my.server.domain===_--
  --_===38330025====my.server.domain===_
  Content-Type: image/gif; name="test.gif"
  Content-Disposition: attachment; filename="test.gif"
  Content-Transfer-Encoding: base64
  R0lGODlhCgAMAPf/AP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+Z
  zP+Zmf+ZZv+ZM/+ZAP9m//9mzP9mmf9mZv9mM/9mAP8z//8zzP8zmf8zZv8zM/8zAP8A//8A
  zP8Amf8AZv8AM/8AAMz//8z/zMz/mcz/Zsz/M8z/AMzM/8zMzMzMmczMZszMM8zMAMyZ/8yZ
  zMyZmcyZZsyZM8yZAMxm/8xmzMxmmcxmZsxmM8xmAMwz/8wzzMwzmcwzZswzM8wzAMwA/8wA
  zMwAmcwAZswAM8wAAJn//5n/zJn/mZn/Zpn/M5n/AJnM/5nMzJnMmZnMZpnMM5nMAJmZ/5mZ
  zJmZmZmZZpmZM5mZAJlm/5lmzJlmmZlmZplmM5lmAJkz/5kzzJkzmZkzZpkzM5kzAJkA/5kA
  zJkAmZkAZpkAM5kAAGb//2b/zGb/mWb/Zmb/M2b/AGbM/2bMzGbMmWbMZmbMM2bMAGaZ/2aZ
  zGaZmWaZZmaZM2aZAGZm/2ZmzGZmmWZmZmZmM2ZmAGYz/2YzzGYzmWYzZmYzM2YzAGYA/2YA
  zGYAmWYAZmYAM2YAADP//zP/zDP/mTP/ZjP/MzP/ADPM/zPMzDPMmTPMZjPMMzPMADOZ/zOZ
  zDOZmTOZZjOZMzOZADNm/zNmzDNmmTNmZjNmMzNmADMz/zMzzDMzmTMzZjMzMzMzADMA/zMA
  zDMAmTMAZjMAMzMAAAD//wD/zAD/mQD/ZgD/MwD/AADM/wDMzADMmQDMZgDMMwDMAACZ/wCZ
  zACZmQCZZgCZMwCZAABm/wBmzABmmQBmZgBmMwBmAAAz/wAzzAAzmQAzZgAzMwAzAAAA/wAA
  zAAAmQAAZgAAM+4AAN0AALsAAKoAAIgAAHcAAFUAAEQAACIAABEAAADuAADdAAC7AACqAACI
  AAB3AABVAABEAAAiAAARAAAA7gAA3QAAuwAAqgAAiAAAdwAAVQAARAAAIgAAEe7u7t3d3bu7
  u6qqqoiIiHd3d1VVVURERCIiIhEREQAAACH+HUdpZkJ1aWxkZXIgMC40IGJ5IFl2ZXMgUGln
  dWV0ACH5BAUEALkALAAAAAAKAAwAAAg1AHPlG0gw379cAgEoXHgw4UKFDfM9hIhQ4sSIEwFg
  vCiQ4L+PIC1m/Cfx34qQGkVeBMkSZEAAOw==
  --_===38330025====my.server.domain===_
  Content-Type: application/pdf; name="sample.pdf"
  Content-Disposition: attachment; filename="sample.pdf"
  Content-Transfer-Encoding: base64
  JVBERi0xLjIgDSXi48/TDQogDTggMCBvYmoNPDwNL0xlbmd0aCA5IDAgUg0vRmlsdGVyIC9G
  bGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIic2X3VLjuBaFn6DfQXfDuaCP5X9fJiQEpkNI2eFQ
  [......skipped......]
  Ug0vSUQgWzxjNjIyNzFiYzY4YmFlYjY3YzBkM2ViNTk4MjJiZTA4Nz48YzYyMjcxYmM2OGJh
  ZWI2N2MwZDNlYjU5ODIyYmUwODc+XQ0+Pg1zdGFydHhyZWYNODc1NA0lJUVPRg0=
  --_===38330025====my.server.domain===_--

  Для того, что бы создать сообщения, в которых MIME части (приложения) скопированы из других сообщений, хранящихся на Сервере, используйте вместо MIME элемента элемент copyMIME:

  `copyMIME`
    Атрибуты:
    `folder` или `calendar`
      имя открытого Представления папки или открытого Календаря.
    `UID`
      UID сообщения.
    `partID`
      в этом опциональном атрибуте задаётся часть сообщения, которую необходимо скопировать. Если он не указан, то копируется всё сообщение.
  Пример:
  Клиент сохраняет Заметку в Папке "Notes", добавляя части 3 и 4 (приложения) к сообщению 156, хранящегося в представлении папки INBOX:
  C:<messageAppend id="A001" targetMailbox="Notes" flags="Seen">
  <EMail>
  <From realName="Sender Name">fromName@domain</From>
  <Subject>Vacation Pictures</Subject>
  <MIME type="multipart" subtype="mixed">
  <MIME type="text" subtype="plain">The first part of the underwater shots.</MIME>
  <copyMIME folder="INBOX" UID="156" partID="3"/>
  <copyMIME folder="INBOX" UID="156" partID="4"/>
  </MIME>
  </EMail>
  </messageAppend>
  S:<response id="A001"/>

  Вы можете прикладывать файлы, хранящиеся в Персональном Хранилище Файлов. Укажите полное имя файла в элементах MIME, используя атрибут `fileName`.
  Вы должны явно указывать атрибуты `type`, `subtype` и (для текстовых файлов) атрибут `charset`.
  Вы должны указать атрибут `disposition-filename`, так как атрибут `fileName` не используется для формирования имени приложенного файла.

  Пример:
  Клиент сохраняет Заметку в Папке "Notes", добавляя файл `private/MyFile.jpg` как приложение `photo.jpg`:
  C:<messageAppend id="A001" targetMailbox="Notes" flags="Seen">
  <EMail>
  <From realName="Sender Name">fromName@domain</From>
  <Subject>Vacation Pictures</Subject>
  <MIME type="multipart" subtype="mixed">
  <MIME type="text" subtype="plain">Attached please find the images I have stored as files.</MIME>
  <MIME type="image" subtype="jpeg" fileName="private/MyFile.jpg" disposition-filename="photo.jpg" />
  </MIME>
  </EMail>
  </messageAppend>
  S:<response id="A001"/>

  Обратите внимание: если для элемента `<MIME />` значение атрибута `disposition` задано как `none`, то поле заголовка `Content-Disposition:` не создаётся, и поле `Content-Type` сохраняется без параметра `name`.

  Обратите внимание: в качестве разделителя строк в текстовых частях MIME должен использоваться один символ перевода строки (0x0A, десятичное 10).

  Вы можете попросить Сервер использовать "перетекающий" формат для MIME частей.

  Пример:
  C:<messageAppend id="A001" targetMailbox="Notes" flags="Seen">
  <EMail>
  <Subject>Test text</Subject>
  <MIME type="text" subtype="plain" format="flowed">This is a very long long long long long long long long long long superlong long long long long long long line, followed with a shorter line:
  This is a shorter line.</MIME>
  </EMail>
  </messageAppend>
  S:<response id="A001"/>
  Эта операция добавляет в Папку следующее сообщение:
  Subject: Test text
  Content-Transfer-Encoding: 8bit
  Content-Type: text/plain; format="flowed"; charset="utf-8"
  This is a very long long long long long long long long long long superlong
  long long long long long long line, followed with a shorter line:
  This is a shorter line.
  (после слова "superlong" есть концевые пробелы)

  Для того, что бы создать подписанное сообщение, убедитесь, что ваш Закрытый Ключ разблокирован и укажите атрибут `sign` в самом верхнем элементе `EMail`.

  C:<messageAppend id="A001" targetMailbox="Sent" flags="Seen,Answered" >
  <EMail sign="yes">
  <From realName="Sender Name">fromName@domain</From><Subject>I'll be there!</Subject>
  <To realName="Recipient Name">toName@domain</To><X-Mailer>SuperClient v7.77</X-Mailer>
  <MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
  </EMail>
  </messageAppend>
  S:<response id="A001"/>
  Эта операция добавляет в Папку следующее сообщение:
  From: "Sender Name" <fromName@domain>
  Subject: I'll be there!
  To: "Recipient Name" <toName@domain>
  X-Mailer: SuperClient v7.77
  Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="_===signed==2610002====my.server.domain===_"
  This is a signed S/MIME message
  --_===signed==2610002====my.server.domain===_
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 8bit
  Dear Susan,
  I will come to your place tomorrow, thank you for the invitation!
  Mary.
  --_===signed==2610002====my.server.domain===_
  Content-Type: application/x-pkcs7-signature; name="smime.p7s"
  Content-Transfer-Encoding: base64
  Content-Disposition: attachment; filename="smime.p7s"
  MIIE6wYJKoZIhvcNAQcCoIIE3DCCBNgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
  ArkwggK1MIICX6ADAgECAgcAk9RF+n/7MA0GCSqGSIb3DQEBBAUAMIG6MQswCQYDVQQGEwJV
  UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC01pbGwgVmFsbGV5MSIwIAYDVQQKExlDb21tdW5p
  .............
  gIbXNT64QJ+gEYkI9mnePiS1TUOOzGYfXaLy1pqm6jmzBUt7/3UY8ZNHVIwM0Fzj7NwzqM1U
  Esbkyi3WHNxTZ4HSCs8J2enGQEZjNWHOuX96xQojYGLV0m5Z/FatV9GQ8jNVBmQ9xYGKxmlY
  jT9ze/oHyKuj7KR8QrgQSYiJVnn7
  --_===signed==2610002====my.server.domain===_--
`messageSubmit`
  Эта операция предписывает серверу сформировать Сообщение и передать его в Очередь на доставку. Копия сообщения может быть сохранена в Папке.
  Атрибуты:
  `useDSN`
    если этот опциональный атрибут существует и его значением является yes, то при доставке сообщения или при ошибке в доставке генерируются соответствующие уведомления.
    Если этот атрибут отсутствует, то уведомления генерируются только в том случае, если доставка сообщения завершилась неуспешно.
  `targetMailbox`, `mailboxClass`, `flags`, `internalDate`
    если опциональный атрибут `targetMailbox` указан, то созданное сообщение добавляется в указанную Папку. Эти атрибуты имеют тот же смысл, что и атрибуты операции `messageAppend`.
  Тело:
    XML представление Сообщения (элемент `EMail`) и ноль, один или несколько элементов `Envelope-To`. Каждый элемент `Envelope-To` должен иметь текстовое тело - адрес электронной почты, на который должно отправляться сообщение.
    Если не указано никакого элемента `Envelope-To`, то сообщение отправляется на адрес, указанный в элементах `To`, `Cc` и `Bcc`, находящихся внутри элемента `EMail`.
    При формировании MIME текста сообщения все адреса, находящиеся в элементе `Bcc`, пропускаются.
  Пример:
  Клиент отправляет простое текстовое сообщение на адрес `toName@domain` и его скрытую копию Bcc на адрес `bccName@domain`. Клиент запрашивает уведомление о доставке.
  C:<messageSubmit id="A001" useDSN="yes" >
  <EMail>
  <From realName="Sender Name">fromName@domain</From>
  <Subject>I'll be there!</Subject>
  <To realName="Recipient Name">toName@domain</To>
  <X-Mailer>SuperClient v7.77</X-Mailer>
  <Bcc>bccName@domain</Bcc>
  <MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
  </EMail>
  </messageSubmit>
  S:<response id="A001"/>

  Пример:
  Клиент отправляет простое текстовое сообщение на адреса `a1@domain` и `a2@domain` (отличающиеся от адресов, указанных в элементах `To` и `Cc`).
  Копия сообщения должна быть сохранена в Папке Отправленное ("Sent Items") с флагом Seen.
  Клиент запрашивает уведомление о доставке.
  C:<messageSubmit id="A001" targetMailbox="Sent Items" flags="Seen" >
  <Envelope-To>a1@domain address</Envelope-To>
  <Envelope-To>a2@domain address</Envelope-To>
  <EMail>
  <From realName="Sender Name">fromName@domain</From>
  <Subject>I'll be there!</Subject>
  <To realName="Recipient Name">toName@domain</To>
  <X-Mailer>SuperClient v7.77</X-Mailer>
  <Cc>ccName@domain</Cc>
  <MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
  </EMail>
  </messageSubmit>
  S:<response id="A001"/>

  Пример:
  Клиент пересылает сообщение 156, хранящееся в Представлении папки INBOX на адрес `a1@domain`:
  C:<messageSubmit id="A001">
  <EMail>
  <From realName="Sender Name">fromName@domain</From>
  <Subject>Fwd: Sorry, I cannot make it :-(</Subject>
  <To realName="Recipient Name">a1@domain</To>
  <X-Mailer>SuperClient v7.77</X-Mailer>
  <MIME type="multipart" subtype="mixed">
  <MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;Attached please find the message I received this morning...&#x0A;Mary.&#x0A;</MIME>
  <copyMIME folder="INBOX" UID="156" />
  </EMail>
  </messageSubmit>
  S:<response id="A001"/>

  Эта операция добавляет в Папку следующее сообщение:

  From: "Sender Name" <fromName@domain>
  Subject: Fwd: Sorry, I cannot make it :-(
  To: "Recipient Name" <toName@domain>
  X-Mailer: SuperClient v7.77
  Date: Wed, 21 Jun 2006 22:55:24 -0800
  Message-ID: <ximss-38150012@this.server.dom>
  Content-Type: multipart/mixed; boundary="_===38330025====my.server.domain===_"
  --_===38330025====my.server.domain===_
  Content-Type: text/plain; charset="utf-8"
  Dear Susan,
  Attached please find the message I received this morning...
  Mary.
  --_===38330025====my.server.domain===_
  Content-Type: message/rfc822
  From: "Barbara Smith" <barbara@domain>
  Subject: Sorry, I cannot make it :-(
  To: "Sender Name" <fromName@domain>
  X-Mailer: OtherClient v8.88
  Date: Wed, 21 Jun 2006 21:51:24 -0800
  Message-ID: <zzzzzzzzz@other.server.dom>
  Content-Type: text/plain; charset="utf-8"
  Mary,
  Sorry, but I will be out of town tomorrow...
  Barbara.
  --_===38330025====my.server.domain===_--
`messageRedirect`
  Эта операция предписывает серверу сформировать копию сообщения, хранящегося в Папке и передать его в Очередь на доставку.
  Атрибуты:
  `folder`
    имя Представления папки.
  `UID`
    UID сообщения.
  Тело:
    Набор из одного или более элементов `To` задаёт адрес(а)получателя (получателей).

  Пример:
  Клиент перенаправляет сообщение 156, хранящееся в Представлении папки INBOX на адреса `a1@domain` и `a2@domain`:
  C:<messageRedirect id="A001" folder="INBOX" UID="156">
  <To realName="Recipient Name">a1@domain</To>
  <To realName="Recipient-2">a2@domain</To>
  </messageRedirect>
  S:<response id="A001"/>
`messageForward`
  Эта операция предписывает серверу сформировать копию сообщения, хранящегося в Папке и передать его в Очередь на доставку. Операция использует те же атрибуты, что и операция `messageRedirect`.
`messageConfirm`
  Эта операция предписывает серверу сформировать MDN-уведомление (Уведомление об Открытии Сообщения) для сохранённого в папке сообщения и передать его в Очередь на доставку.
  Клиентские приложения должны использовать эту операцию в следующих случаях:
  - сообщение было показано пользователю, и
  - сообщение имеет поле заголовка Disposition-Notification, и
  - сообщения не имеет флага $MDNSent, и
  - Настройка пользователя `SendMDNMode` установлена в значение `Automatically` или установлена в значение `Manually` и пользователь явно потребовал отправить подтверждение.
  Атрибуты:
  `folder`
    имя Представления папки.
  `UID`
    UID сообщения.
  `type`
    этот атрибут должно быть установлен в `auto` (если подтверждение генерируется автоматически) или в `manual` (если пользователь явно затребовал отправку подтверждения).

Сервер отправляет следующие сообщения данных:

`folderMessage`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `folderRead`.
  Атрибуты:
  `folder`, `UID`, `partID`, `mode`
    копии атрибутов запроса `folderRead`.
  Тело:
    XML представление Сообщения или его части.
`messageAdded`
  Эти синхронные сообщения данных отправляются, когда Сервер обрабатывает запросы `messageAppend` и `contactAppend` с установленными атрибутами `report`.
  Атрибуты:
  `folder`
    имя Представления папки.
  `UID`
    UID добавленного сообщения.
  Обратите внимание: даже если это сообщение данных отправлено, Сервер всё-равно будет отправлять асинхронные сообщения данных `folderReport`, уведомляющие клиентов о том, что в Представление папки было добавлено новое сообщение. Клиент ДОЛЖЕН использовать операцию `folderSync` для синхронизации своего внутреннего вида с видом Сервера, в противном случае вновь добавленные сообщения не будут "видны" в Представлении папки.

## Управление Пользователем

Для управления Списками Прав Доступа Пользователя (ACL) клиент может использовать следующий набор операций.

`accountRightsGet`
  Эта операция заставляет Сервер отправить сообщение данных `accountRight` (смотрите ниже) с правами доступа текущего или указанного Пользователя.
  Атрибуты:
  `userName`
    (опционально) задаёт имя требуемого Пользователя. Если этот атрибут отсутствует, то используется текущий Пользователь.
`accountACLList`
  Эта операция заставляет Сервер отправить сообщение данных `accountACL` (смотрите ниже), содержащее данные из Списка Прав Доступа к Папке.
  Атрибуты:
  `userName`
    (опционально) задаёт имя требуемого Пользователя. Если этот атрибут отсутствует, то используется текущий Пользователь.
`accountACLUpdate`
  Эта операция изменяет Список Прав Доступа Пользователя.
  Атрибуты:
  `userName`
    (опционально) задаёт имя требуемого Пользователя. Если этот атрибут отсутствует, то используется текущий Пользователь.
  Тело:
    Набор XML элементов `aclElem`. Эти элементы аналогичны изпользуемым в операции `mailboxACLUpdate` , но в строках их тела применяются символы, которые задают Права Доступа Пользователя.

Сервер отправляет следующие сообщения данных:

`accountRights`
  Это сообщение отправляется, когда Сервер обрабатывает запрос `accountRightsGet`.
  Атрибуты:
  `userName`
    имя Пользователя (если указано в запросе).
  Тело:
    строка; каждый символ определяет фактически действующие Права Доступа Пользователя, предоставленные текущему пользователю.
`accountACL`
  Это сообщение отправляется, когда Сервер обрабатывает запрос `accountACLLis`.
  Атрибуты:
  `userName`
    имя Пользователя (если указано в запросе).
  Тело:
    Набор XML элементов `aclElem`, один элемент для каждого элемента из Списка Прав Доступа Пользователя; аналогично используемым в сообщениях данных `mailboxACL`, но строки тела элемента содержат символы, представляющие Права Доступа Пользователя.

## Безопасный обмен Сообщениями (S/MIME)

Для задействования возможностей Сервера по работе с S/MIME, клиент может использовать следующий набор операций.

`SMIMEUnlock`
  Эта операция разблокирует Закрытый Ключ Пользователя, хранящийся на Сервере.
  Когда Закрытый Ключ разблокирован, Сервер расшифровывает части сообщений с использованием операции `folderRead`.
  Сервер также может зашифровывать и/или подписывать цифровой подписью передаваемые сообщения.
  Обратите внимание: эта операция передаёт разблокирующую строку ("пароль хранения") открытым текстом. Клиентское приложение должно использовать эту команду только через безопасное (TLS) соединение.
  Обратите внимание: разблокированный Закрытый Ключ добавляется только к данным текущей сессии и нигде не сохраняется. Если для одного и того же Пользователя открывается другая сессия, то ему необходимо самостоятельно разблокировать в ней Закрытый Ключ.
  Атрибуты:
  `password`
    разблокирующая строка (пароль).
  `duration`
    опциональный атрибут - время (в секундах), в течение которого Закрытый Ключ будет находиться разблокированным; по истечении этого времени Закрытый Ключ блокируется автоматически.
`SMIMELock`
  Эта операция блокирует Закрытый Ключ Пользователя, хранящийся на Сервере (она удаляет разблокированный Закрытый Ключ из данных текущей сессии).
  Эту операцию рекомендуется использовать после определённого времени бездействия пользователя.
`SMIMEModifyPassword`
  Эта операция изменяет парольную строку, защищающую Закрытый Ключ Пользователя на Сервере. Закрытый Ключ Пользователя должен быть разблокирован.
  Обратите внимание: эта операция передаёт разблокирующую строку ("пароль хранения") открытым текстом. Клиентское приложение должно использовать эту команду только через безопасное (TLS) соединение.
  Атрибуты:
  `password`
    новая разблокирующая строка (пароль).

Cервер находит все подписанные части сообщения и пытается проверить, что тело части не изменялось с момента подписания и что сертификаты корректны (то есть, были выпущены известными центрами сертификации).

Тело элемента `MIME` для подписанной части сообщения содержит два XML подэлемента: первым элементом являются подписанные данные (элемент `EMail` или `MIME`), а второй частью является XML элемент `SMIMESignature`.

Если Сервер не смог раскодировать или расшифровать данные подписи, то тело элемента `MIME` для подписанной части сообщения содержит атрибут `decryptionError` c текстом кода ошибки.

Тело элемента `SMIMESignature` содержит подэлементы Certificate для всех подписей, соответствующим данным части. Если Сервер не смог проверить Сертификат, то его элемент содержит атрибут validationError с текстом кода ошибки. Если данным части не соответствует никакая подпись, то элемент `SMIMESignature` является пустым.

Пример:
Клиент забирает одписанное сообщение:
C:<folderRead id="A001" folder="INBOX" UID="55" totalSizeLimit="100000" />
S:<folderMessage id="A001" folder="INBOX" UID="55">
<EMail>
<Return-Path>fromName@domain</Return-Path>
<From realName="Sender Name">fromName@domain</From>
<Subject>Re: I'll be there!</Subject>
<To realName="Recipient Name">a1@domain</To>
<X-Mailer>SuperClient v7.77</X-Mailer>
<Date localTime="20070830T204318" timeShift="-25200">20070830T184318Z</Date>
<Message-ID>web-40721383@domain.dom</Message-ID>
<MIME digesterName="SHA1" estimatedSize="5171" subtype="signed" type="multipart"
Type-micalg="SHA1" Type-protocol="application/x-pkcs7-signature" />
<MIME estimatedSize="3032" partID="01" subtype="mixed" type="multipart">
<MIME charset="utf-8" estimatedSize="86" partID="01-01" subtype="plain" type="text">Dear Susan,&#x0A;&#x0A;Attached please find a file I received this morning...&#x0A;Mary.&#x0A;
</MIME>
<MIME disposition="attachment" Disposition-filename="logo.gif" estimatedSize="1929" partID="01-02" subtype="gif" type="image" />
</MIME>
<SMIMESignature>
<x509 subject="fromName@domain" validationError="presented certificate is issued by an unknown authority" version="2">
<subject><cn>Sender Name</cn><contact>fromName@domain</contact></subject>
<issuer><c>US</c><cn>issuer.dom</cn><contact>postmaster@issuer.dom</contact><l>Mill Valley</l>
<o>Issuer Company, Inc.</o><ou>Issuer Department</ou><st>CA</st></issuer>
<validFrom>20040924T231857Z</validFrom>
<validTill>20170923T231857Z</validTill>
</x509>
</SMIMESignature>
</MIME>
</EMail>
</folderMessage>
S:<response id="A001"/>

Если Закрытый Ключ Пользователя разблокирован, то Сервер пытается расшифровать все зашифрованные части сообщения.

Если расшифровка заканчивается неудачно, то элемент для зашифрованной части содержит дополнительный атрибут:
`decryptionError`
  текст сообщения об ошибке расшифровки.

Если расшифровка заканчивается неудачно, то зашифрованная часть показывается как XML подэлемент `MIME` или `EMail` элемента зашифрованной части.

Если расшифровка заканчивается успешно, то тело элемента зашифрованной части содержит XML подэлемент `MIME` или `EMail` с расшифрованными данными.

Элемент зашифрованной части содержит допонительные атрибуты:
`cipherName`
  имя криптографического шифра, используемого для шифрования или расшифровки части.
`keyLength`
  длина (в битах) использованного для шифрования зашифрованной части ключа криптографического шифра.

Пример:
Клиент забирает зашифрованное сообщение, затем разблокирует Закрытый Ключ Пользователя и потом повторно получает то же самое сообщение:
C:<folderRead id="A001" folder="INBOX" UID="55" totalSizeLimit="100000" />
S:<folderMessage id="A001" folder="INBOX" UID="55">
<EMail>
<Return-Path>fromName@domain</Return-Path>
<From realName="Sender Name">fromName@domain</From>
<Subject>Re: I'll be there!</Subject>
<To realName="Recipient Name">a1@domain</To>
<X-Mailer>SuperClient v7.77</X-Mailer>
<Date localTime="20070830T204318" timeShift="-25200">20070830T184318Z</Date>
<Message-ID>web-40721383@domain.dom</Message-ID>
<MIME disposition="attachment" Disposition-filename="smime.p7m" estimatedSize="4536"
subtype="x-pkcs7-mime" type="application" Type-name="smime.p7m" Type-smime-type="enveloped-data" />
</EMail>
</folderMessage>
S:<response id="A001"/>
C:<SMIMEUnlock id="A002" password="smime-password" />
S:<response id="A002"/>
C:<folderRead id="A003" folder="INBOX" UID="55" totalSizeLimit="100000" />
S:<folderMessage id="A003" folder="INBOX" UID="55">
<EMail>
<Return-Path>fromName@domain</Return-Path>
<From realName="Sender Name">fromName@domain</From>
<Subject>Re: I'll be there!</Subject>
<To realName="Recipient Name">a1@domain</To>
<X-Mailer>SuperClient v7.77</X-Mailer>
<Date localTime="20070830T204318" timeShift="-25200">20070830T184318Z</Date>
<Message-ID>web-40721383@domain.dom</Message-ID>
<MIME cipherName="RC2" disposition="attachment" Disposition-filename="smime.p7m" estimatedSize="4536" keyLength="40"
subtype="x-pkcs7-mime" type="application" Type-name="smime.p7m" Type-smime-type="enveloped-data" >
<EMail partID="E">
<From realName="Sender Name">fromName@domain</From>
<Subject>Re: I'll be there!</Subject>
<To realName="Recipient Name">a1@domain</To>
<X-Mailer>SuperClient v7.77</X-Mailer>
<Date localTime="20070830T204318" timeShift="-25200">20070830T184318Z</Date>
<Message-ID>web-40721383@domain.dom</Message-ID>
<MIME estimatedSize="3275" partID="E" subtype="mixed" type="multipart">
<MIME charset="utf-8" estimatedSize="329" partID="E-01" subtype="plain" type="text" Type-format="flowed">
This is an encrypted E-mail with an attachment.
On Thu, 30 Aug 2007 20:40:49 -0800
&quot;Sender Name&quot; &lt;fromName@domain&gt; wrote:
&gt; Dear Susan,
&gt;
&gt; I will come to your place tomorrow, thank you for the invitation!
&gt; Mary.
</MIME>
<MIME disposition="attachment" Disposition-filename="logo.gif" estimatedSize="1929" partID="E-02"
subtype="gif" type="image" />
</MIME>
</EMail>
</MIME>
</EMail>
</folderMessage>
S:<response id="A003"/>

Когда Закрытый Ключ Пользователя разблокирован, клиент может передать подписанное сообщение электронной почты.

Элемент `EMail` должен содержать дополнительный атрибут:
`sign`
  если этот опциональный атрибут существует и его значением является yes, то тело сообщения подписано.

Пример:
Клиент отправляет подписанное сообщение на адрес `toName@domain`:

C:<messageSubmit id="A001">
<EMail sign="yes">
<From realName="Sender Name">fromName@domain</From>
<Subject>I'll be there!</Subject>
<To realName="Recipient Name">toName@domain</To>
<X-Mailer>SuperClient v7.77</X-Mailer>
<MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
</EMail>
</messageSubmit>
S:<response id="A001"/>

Когда Закрытый Ключ Пользователя разблокирован, клиент может передать зашифрованное сообщение при условии, что в Записной Книге содержатся соответствующие записи для всех получателей этого сообщения и для каждой из этих записей имеется PKI Сертификат получателя.

Элемент `EMail` верхнего уровня должен содержать дополнительные атрибуты:
`encrypt`
  если этот опциональный атрибут существует и его значением является yes, то тело сообщения зашифровано.
`addressBook`
  имя Записной Книги, в которой будет осуществляться поиск сертификатов получателей.

Элемент `EMail` верхнего уровня должен содержать один "внутренний" элемент `EMail` - содержимое этого элемента будет зашифровано. Поля заголовков внутреннего элемента `EMail` могут как совпадать с аналогичным в элементе `EMail` верхнего уровня, так и различаться. Например, элемент `Subject` "внутреннего" элемента `EMail` может отличаться.

Обратите внимание: вы не можете указать оба атрибута `sign` и `encrypt` для элемента `EMail` верхнего уровня. Для отправки зашифрованого и подписанного сообщения, добавьте атрибут `sign` к внутреннему элементу `EMail`.

Пример:
Клиент отправляет зашифрованное и подписанное текстовое сообщение на адрес `toName@domain`. Обратите внимание на несовпадающие поля Тема. Клиент запрашивает уведомление о доставке.

C:<messageSubmit id="A001" useDSN="yes" >
<EMail encrypt="yes" addressBook="Contacts" >
<From realName="Sender Name">fromName@domain</From>
<Subject>A message regarding your request</Subject>
<To realName="Recipient Name">toName@domain</To>
<EMail sign="yes">
<From realName="Sender Name">fromName@domain</From>
<Subject>I'll be there!</Subject>
<To realName="Recipient Name">toName@domain</To>
<X-Mailer>SuperClient v7.77</X-Mailer>
<MIME type="text" subtype="plain">Dear Susan,&#x0A;&#x0A;I will come to your place tomorrow, thank you for the invitation!&#x0A;Mary.&#x0A;</MIME>
</EMail>
</EMail>
</messageSubmit>
S:<response id="A001"/>

## Операции с Контактами

Информация о контактах (vCard и vCardGroup) может быть сохранена в любой Папке как сообщение. Элемент данных vCard может быть приложен (как MIME часть) к любому сообщению электронной почты. Каждое сообщение может содержать несколько MIME частей, содержащих несколько объектов vCard.

`MIME` части с типом `text` и `x-vcard` или с подтипом `dictionary` содержат элементы `vCard`.

`MIME` части с типом `text` и `x-vcard` содержат один элемент `vCardGroup`.

Для того, что бы включить данные vCard в сообщение (используя операции `messageAppend`, `messageSubmit`), включите элемент `MIME` с атрибутами `type="text"` и `subtype="directory"`. Тело элемента должно содержать один или более элементов `vCard`.

Для того, что бы включить данные vCardGroup в сообщение (используя операции `messageAppend`, `messageSubmit`), включите элемент `MIME` с атрибутами `type="text"` и `subtype="x-vgroup"`. Тело элемента должно содержать один элемент `vCardGroup`.

Папки класса Контакты используются для хранения специальных сообщений ("элементов данных"), в которых содержатся только vCard или vCardGroup данные. В правильно сформированном элементе vCard:

- в поле `Subject` содержится свойство vCard `FN`.
- в поле `To` содержатся свойства vCard `EMAIL`.
- в поле `X-Telnum` содержатся свойства vCard `TEL`.
- поле `X-Has-Certificate` существует и содержит значение `true`, если vCard имеет свойство `KEY`.

В правильно сформированном элементе данных vCardGroup:

- в поле `Subject` содержится свойство vCardGroup `NAME`.

Используйте следующие операции для формирования, сохранения и получения этих специальных сообщений:

`contactAppend`
  Эта операция создаёт специальное сообщение электронной почты, в теле которого содержатся данные vCard или vCardGroup, а также формирует все необходимые поля заголовка сообщения электронной почты и сохраняет получившееся сообщение в указанной Папке или в Представлении Папки.
  Атрибуты:
  `folder`
    имя целевого Представления папки. Если оно указано, то атрибут `targetMailbox` игнорируется.
  `targetMailbox`
    имя Папки - приёмника. Если атрибут `folder` отсутствует, то оно должно быть указано.
    если Папка-приёмник не существует, то она создаётся.
  `flags`, `replacesUID`, `checkOld`, `report`
    эти опциональные атрибуты имеют тот же смысл, что и атрибуты операции `messageAppend`. Если атрибут `flags` не указан, его значение подразумевается равным `Seen`.
  Тело:
    в точности один элемент `vCard` или `vCardGroup`.
  Операция добавляет атрибуты vCard `UID` и `FN` в случае если они отсутствуют.

  Пример 1:
  Клиент добавляет объект vCard в Папку `Contacts`.
  C:<contactAppend id="A011" targetMailbox="Contacts" >
  <vCard>
  <NAME>Bjorn Jensen</NAME>
  <N><FAMILY>Jensen</FAMILY><GIVEN>bjorn</GIVEN>
  <MIDDLE>A</MIDDLE><PREFIX>Mr.</PREFIX><SUFFIX>II</SUFFIX></N>
  <EMAIL><INTERNET /><USERID>bjorn@domain.dom</USERID></EMAIL>
  <TEL><WORK /><VOICE /><MSG /><NUMBER>+1 313 747-4454</NUMBER></TEL>
  <KEY><x509 /><BINVAL>dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK</BINVAL></KEY>
  </vCard>
  </contactAppend>
  S:<response id="A011"/>
`contactsImport`
  Эта операция разбирает загруженный файл, в котором должны содержаться элементы vCard. Получившиеся элементы копируются в специальное Представление папки.
  Атрибуты:
  `folder`
    имя Представления папки.
  `uploadID`
    строка, идентифицирующая файл в "наборе загруженных файлов".
`contactFind`
  Эта операций осуществляет поиск в открытом Представлении папки сообщения vCard с адресом электронной почты или телефонным номером, соответствующим указанному адресу.
  Проверяются только поля заголовков сообщения электронной почты (`To` и `X-Telnum`), а не фактические данные vCard.
  Атрибуты:
  `folder`
    имя Представления папки.
  `totalSizeLimit`
    аналогично как для операции `folderRead`.
  `peer`
    искомый адрес.
  Эта операция останавливается когда она находит первое соответствующее сообщение.
  Содержимое обнаруженного сообщения электронной почты отправляется клиенту как сообщение данных `folderMessage` со следующими дополнительными атрибутами:
  Атрибуты:
  `peer`
    имеет то же значение, что и в запросе.
  `foundAddress`
    элемент адреса `To` или `X-Telnum`, который соответствует значению `peer`.

## Операции с Календарём

Клиент может использовать следующие операции для работы с Календарём аутентифицированного Пользователя, а также с Календарями других Пользователей (указывая полное имя Папки в виде `~accountName@domainName/mailboxName`).

`calendarOpen`
  Эта операция открывает указанную Папку как "Календарь".
  Календарь представляет собой Папку Сервера, в которой сообщения были разобраны и из которых была получена вся календарная информация.
  Каждый календарь имеет имя; в одной сессии не может быть двух календарей с одинаковыми именами. С другой стороны, в одной сессии могут быть открыто два различных календаря (с разными именами) для одной и той же Папки.
  Атрибуты:
  `calendar`
    имя нового Календаря, которое необходимо открыть. В качестве имени Календаря клиент может использовать произвольную строку.
  `mailbox`
    имя Папки. Если этот атрибут не указан, то используется имя календаря.
  Сессия может использовать несколько Календарей одновременно.
`findEvents`
  Эта операция получает объекты VEVENT из указанного Календаря. Будут получены только те События (Встречи), которые попадают в указанный временной интервал.
  Атрибуты:
  `calendar`
    имя Календаря.
  `timeFrom`, `timeTill`
    начало и конец временного интервала (значения времени должны быть указаны для выбранного часового пояса).
  `byAlarm`
    если этот опциональный атрибут существует и его значением является yes, то операция ищет не События (Встречи) в указанном временном интервале, а такие События (встречи), элемент Alert которых задан в указанном временном интервале.
  `limit`
    этот опциональный числовой атрибут ограничивает число возвращаемых Встреч.
  `skip`
    этот опциональный числовой атрибут указывает, сколько из "возвращаемых" Встреч должны быть пропущены. Используя этот атрибут клиент может получать большой набор Встреч по "кусочкам".
  Сервер отправляет сообщение данных `events`, если в указанном временном интервале обнаружена как минимум одна встреча.
`calendarClose`
  Эта операция закрывает открытый Календарь.
  Атрибуты:
  `calendar`
    имя Календаря.
`calendarRead`
  Эта операция указывает Серверу получить Сообщение или его часть. Оно отправляется клиенту как сообщение данных `calendarMessage`.
  Эта операция аналогична операции `folderRead`, но вместо атрибута `folder` она использует арибут `calendar` для указания имени открытого Календаря.
`calendarPublish`
  Эта операция помещает элемент данных календаря в Календарь. Существующие элементы данных, имеющие тот же UID, удаляются.
  Атрибуты:
  `calendar`
    имя Календаря.
  `sendRequests`
    если этот опциональный атрибут существует и его значением является `no`, то элемент данных сохраняется без рассылки уведомления другим участникам.
    В противном случае, если ранее существовал элемент данных с таким же UID, то отправляются запросы на Отмену всем тем участникам старого элемента данных, которых нет в новом элементе данных. Запрос на встречу или указание задания отправляется всем участникам, или, если значением атрибута является `new`, только новым участникам.
  Тело:
    Элемент `iCalendar` для помещения в выбранный Календарь и опциональные элементы `MIME` и/или `copyMIME` для добавления (аналогично элементам, используемым в операции `messageAppend`).
  Элемент `iCalendar` должен содержать опциональные элементы `vtimezone` и в точности один элемент данных календаря.
  Для часового пояса, используемого в элементе данных календаря, если этот часовой пояс является одним из стандартных часовых поясов, известных серверу, элемент `vtimezone` можно не включать.
  Можно также не указывать название часового пояса в свойствах, содержащих значения данных без суффикса `Z`. В этом случае используется часовой пояс, выбранный для текущего пользователя.
  Если элемент данных не содержит элемента UID, то Сервер генерирует такой уникальный UID и добавляет его к элементу данных.

  Пример 1:
  Клиент публикует объект iCalendar в календаре `Calendar` .
  C:<calendarPublish id="A021" calendar="Calendar">
  <iCalendar xmlns="urn:ietf:params:xml:ns:xcal">
  <vCalendar method="PUBLISH" prodid="CommuniGate Pro 5.1.7" version="2.0">
  <vevent>
  <organizer CN="Big Boss">MAILTO:boss@company.dom</organizer>
  <attendee CN="Small Boy">MAILTO:boy@company.dom</attendee>
  <rrule>FREQ=WEEKLY;BYDAY=MO,TH</rrule>
  <dtstamp>20061022T091143Z</dtstamp>
  <uid>18927897984@kjjkjkjk-123444</uid>
  <sequence>0</sequence>
  <summary>Report Meeting</summary>
  <dtstart tzid="NorthAmerica/Pacific">20060515T100000</dtstart>
  <dtend tzid="NorthAmerica/Pacific">20060515T110000</dtend>
  <busystatus>BUSY</busystatus>
  <last-modified>20060516T034850Z</last-modified>
  <created>20060516T034850Z</created>
  <priority>5</priority>
  <description>A twice-a-week meeting to discuss the progress of the assigned projects.</description>
  </vevent>
  </vCalendar>
  </iCalendar>
  <MIME uploadID="att01" />
  <copyMIME folder="INBOX" UID="156" partID="3"/>
  </calendarPublish>
  S:<response id="A021"/>
  Обратите внимание: Если значение времени указывается без суффикса "Z", то подразумевается местное время в Часовом Поясе, выбранном для текущего пользователя.
`calendarCancel`
  Эта операция удаляет элемент данных календаря из Календаря. Всем участникам отправляются запросы на отмену.
  Атрибуты:
  `calendar`
    имя Календаря.
  `UID`
    опционально; UID сообщения (числовой).
  `itemUID`
    опционально; строка с UID записи о Встрече (iCalendar).
  `sendRequests`
    если этим опциональным атрибутом является `no`, то всем приглашённым на встречу сообщения с запросами на отмену не отправляются.
  Тело:
    - опциональный элемент `iCalendar`, который необходимо отменить.
      Если этот элемент не указан, то из Календаря берётся запись с заданным UID Встречи iCalendar или с заданным UID сообщения. Затем все записи с одинаковыми UID записи Встреча (iCalendar) удаляются.
    - опциональный элемент `requestComment`, содержащий текстовое тело - комментарий, включаемый в сообщение с запросом на отмену.
`calendarUpdate`
  Эта операция изменяет элемент данных календаря в Календаре с использованием объекта `iCalendar` типа reply. Этот элемент данных указывает, принял или отвергнул данный конкретный приглашённый приглашение на встречу.
  Атрибуты:
  `calendar`
    имя Календаря.
  Тело:
    Элемент данных `iCalendar` типа reply.
`calendarAccept`
  Эта операция помещает элемент данных календаря в Календарь. Существующие элементы данных, имеющие тот же UID, удаляются.
  Атрибуты:
  `calendar`
    имя Календаря.
  `PARTSTAT`
    статус принятия: `ACCEPTED`, `TENTATIVE`, `IN-PROCESS` (только для Заданий), `COMPLETED` (только для Заданий).
  `sendReply`
    если этим опциональным атрибутом является `no`, то организатору не отправляется сообщение с ответом.
  Тело:
    - Элемент `iCalendar` для помещения в выбранный Календарь;
    - опциональные элементы `MIME` и/или `copyMIME` для добавления (аналогично элементам, используемым в операции `messageAppend`);
    - опциональный элемент `replyComment`, содержащий текстовое тело - комментарий, включаемый в сообщение ответа.
  Если элемент данных помещён успешно, тот организатору отправляется сообщение ответа iCalendar. Ответы не отправляются для элементов данных типа Встреча для текущего пользователя (если он является приглашённым на встречу с параметром `RSVP=FALSE`) или если атрибут запроса `sendReply` имеет значение `no`.
`calendarDecline`
  Эта операция удаляет элемент данных календаря.
  Атрибуты:
  `calendar`
    имя Календаря. Этот параметр является опциональным. Если он указан, то элементы данных с таким же UID удаляются из этого Календаря.
  `sendReply`
    если этим опциональным атрибутом является `no`, то организатору не отправляется сообщение с ответом.
  Тело:
    - Отклоняемый элемент `iCalendar`.
    - опциональный элемент `replyComment`, содержащий текстовое тело - комментарий, включаемый в сообщение ответа.

  Используйте эту операцию, если пользователь решает не присутствовать на встрече, хранящейся как опубликованный элемент данных в Календаре (если текущий пользователь является организатором встречи, используйте вместо этого операцию `calendarCancel`.
  Укажите сам опубликованный элемент данных и атрибут `calendar` для удаления элемента данных из Календаря.
  Операция отправляет отрицательный ответ организатору этого элемента данных (за исключением случаев, когда атрибут `sendReply` установлен в значение `no`).

  Используйте эту операцию, если пользователь открывает элемент данных с запросом (во входящем сообщении электронной почты) и решает отклонить этот запрос.
  Укажите элемент данных с запросом и не указывайте никаких атрибутов `calendar`.
  Операция отправляет отрицательный ответ организатору этого элемента данных (за исключением случаев, когда атрибут `sendReply` установлен в значение `no`).

  Используйте эту операцию, если пользователь открывает элемент данных с запросом на отмену (во входящем сообщении электронной почты) и решает удалить отменённый элемент данных из Календаря.
  Укажите элемент данных с запросом на отмену и атрибут `calendar` (обычно - имя Главного Календаря) для того, что бы удалить соответствующие элементы данных из этого календаря.
  Операция не отправляет никакого сообщения с ответом.

  Если указанный элемент данных является запросом, то операция отправляет отрицательный ответ организатору этого элемента данных.
  Если указанный элемент данных является запросом на отмену, то операция не отправляет сообщение с ответом организатору этого элемента данных; укажите атрибут `calendar` для удаления соответствующего элемента данных из Календаря.
`calendarImport`
  Эта операция разбирает загруженный файл, в котором должны содержаться элементы iCalendar/vCalendar. Получившиеся элементы копируются в Календарь. Существующие элементы данных, имеющие тот же UID, удаляются.
  Атрибуты:
  `calendar`
    имя Календаря.
  `uploadID`
    строка, идентифицирующая файл в "наборе загруженных файлов".
`freeBusyRead`
  Эта операция получает информацию о календарной Занятости для указанного Пользователя.
  Атрибуты:
  `userName`
    имя требуемого Пользователя. Если этот атрибут не указан, то запрашивается информация о календарной Занятости текущего Пользователя.
  `timeFrom`, `timeTill`
    начало и конец временного интервала (значения времени должны быть указаны для выбранного часового пояса).
  Сервер отправляет сообщение данных `freeBusyData`.

Сервер отправляет следующие сообщения данных:

`events`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `findEvents`.
  Атрибуты:
  `calendar`, `timeFrom`, `timeTill`, `skip`
    аналогично запросу `findEvents`.
  `items`
    общее число найденных Встреч.
  Тело:
    набор элементов `event` для каждой найденной Встречи.
    Атрибуты:
    `UID`
      UID сообщения Встречи (число).
    `itemUID`
      строка с UID записи о Встрече (iCalendar).
    `timeFrom`
      время начала этой Встречи (в выбранном часовом поясе). Этот атрибут не включается для Встреч (Событий) "на весь день".
    `dateFrom`
      дата начала этой Встречи (в выбранном часовом поясе). Этот атрибут включается только для Встреч (Событий) "на весь день".
    `duration`
      продолжительность Встречи (в секундах).
    `alarmTime`
      этот атрибут включается только если запрос содержал атрибут `byAlarm`. Значение атрибута указывает на время (в выбранном часовом поясе), когда должно произойти Уведомление о Встрече.
    `busyStatus`
      строка со статусом занятости Встречи (`BUSY`, `TENTATIVE`, `UNAVAILABLE`, `FREE`).
    `organizer`
      этот атрибут присутствует и имеет значение yes если текущий пользователь является организатором Встречи.
    `recurrence`
      этот атрибут присутствует и имеет значение yes если Встреча (Событие) является повторяющейся.
    `attendees`
      этот атрибут присутствует или у Встречи есть участники. Значением атрибута является число участников.
    `location`
      этот атрибут присутствует, если у Встречи есть элемент Location. Значением атрибута является значение элемента Location (опционально сокращённое).
    Тело:
      Поля Встречи: `summary`
`calendarReport`
  Эти сообщения отправляются при изменении данных Календаря.
  Атрибуты:
  `calendar`
    имя Календаря.
  `mode`
    в этом опциональном атрибуте задаётся тип уведомления.
    - Если значением атрибута является `notify`, то некоторые сообщения были добавлены в Календарь, изменены или удалены из Календаря.
      Ожидается, что в ответ клиент направит запрос `findEvents` для этого Календаря.

  После того, как Сервер отправляет "уведомительное" сообщение `calendarReport` Клиенту, Сервер может не отправлять дальнейшие "уведомительные" сообщения для этого Календаря до тех пор, пока клиент не выполнит для этого Календаря операцию `findEvents`.

`calendarMessage`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `calendarRead`.
  Это сообщение аналогично сообщению `folderMessage`, но вместо атрибута `folder` в нём содержится атрибут `calendar` с именем Календаря.
`freeBusyData`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `freeBusyRead`.
  Атрибуты:
  `userName`
    копия этого же атрибута из запроса `freeBusyRead`.
  Тело:
    объект `vfreebusy`, содержащий набор элементов `freebusy`. Все возвращаемые значения времени является местным временем в Часовом Поясе, выбранном для текущего пользователя.

  После того, как Сервер отправляет "уведомительное" сообщение `calendarReport` Клиенту, Сервер может не отправлять дальнейшие "уведомительные" сообщения для этого Календаря до тех пор, пока клиент не выполнит для этого Календаря операцию `findEvents`.

## Сигналы

Клиент должен использовать операции "привязки" для того, что бы начать получать сигналы, направляемые аутентифицированному пользователю.

Клиент может обслуживать одну или несколько одновременных коммуникационных сессий ("вызовов"). Каждый вызов идентифицируется по его идентификатору `callLeg`.

`signalBind`
  Эта операция позволяет текущей сессии XIMSS получать сигналы, направляемые аутентифицированному пользователю.
  Атрибуты:
  `deviceName`
    опциональный параметр, указывающий используемое устройство.
  `presence`
    если этот опциональный атрибут существует и его значением является yes, то клиент начинает получать уведомления Ростера и Статуса Присутствия.
  Тело (опционально):
    XML представление дескриптора SDP клиента.
    Дескриптор используется для указания возможностей клиента (способность принимать принимать аудио/видео вызовы) и для определения конфигураций "дальнего NAT".
    Обратите внимание: для того, что бы определять "дальние NAT" конфигурации, SDP дескриптор должен содержать атрибут `ip` с IP адресом медиа, используемым клиентом по умолчанию (смотрите ниже).
`signalUnbind`
  После завершения этой операции текущая сессия XIMSS не получает сигналы, направляемые аутентифицированному пользователю.
`callKill`
  Используйте эту операцию, для того, что бы завершить вызов и освободить все связанные ресурсы.
  Если звонок находился в состоянии "calling", то исходящий звонок прекращается.
  Если звонок находился в состоянии "alerting", то входящий звонок отвергается.
  Если звонок находился в состоянии "connected", то участнику отправляется звонок на отсоединение.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  После успешного завершения этой операции можно создавать новые вызовы с таким же идентификатором.
`callStart`
  Используйте эту операцию для того, что бы начать исходящий звонок.
  Атрибуты:
  `callLeg`
    новый идентификатор вызова. Текущая сессия XIMSS не должна иметь других вызовов с таким идентификатором.
  `peer`
    адрес электронной почты вызова или SIP URI вызова.
  Тело:
    XML представление дескриптора SDP клиента.
  Если эта операция завершается успешно, то создаётся объект с новым вызовом и инициируется исходящий вызов. Сервер может отправлять ноль, одно или несколько сообщений `callProvisioned`, за которым следует сообщение `callDisconnect` или `callConnected`.
  Обратите внимание: клиент должен быть готов обрабатывать эти сообщения Сервера даже в том случае, если до этого он получил положительный ответ на свой запрос `callStart`.
  Обратите внимание: для того, что бы корректно обрабатывать вызовы "за NAT", SDP дескриптор должен содержать атрибут `ip` с IP адресом медиа, используемым клиентом по умолчанию.
  Обратите внимание: если вызов заканчивается неуспешно (получено сообщение `callDisconnected`, то клиенту все-равно необходимо использовать операцию `callKill` для того, что бы освободить ресурсы, связанные с этим вызовом и сделать возможным повторное использование идентификатора вызова.
`callProvision`
  Используйте эту операцию для того, что бы направить промежуточный отклик на входящий вызов.
  Атрибуты:
  `callLeg`
    идентификатор входящего звонка.
  тело (опционально):
    XML представление дескриптора SDP клиента.
`callRedirect`
  Используйте эту операцию для того, что бы перенаправить входящий вызов.
  Атрибуты:
  `callLeg`
    идентификатор входящего звонка.
  Тело:
    один или более элементов XML `To`. Каждый элемент должен иметь текстовое тело, в котором указывается URI, на который необходимо перенаправить звонок.

  Обратите внимание: клиенту все-равно необходимо использовать операцию `callKill` для того, что бы освободить ресурсы, связанные с этим вызовом и сделать возможным повторное использование идентификатора вызова.

  Пример:
  Перенаправление входящего вызова `inp003` на `user1@example.com` и `user2@example.com`.
  C:<callRedirect id="A018" callLeg="inp003" >
  <To>user1@example.com</To><To>user2@example.com</To>
  </callRedirect>
  S:<response id="A018"/>
`callReject`
  Используйте эту операцию, для того, что бы отвергнуть входящий вызов. Вы так же можете использовать операцию `callKill`, но эта операция позволяет вам указать код ошибки.
  Атрибуты:
  `callLeg`
    идентификатор входящего звонка.
  `signalCode`
    числовой код (определяемый согласно стандартам SIP), который передаётся в компонент Signal как код ошибки.
    Используйте код 486 ("Здесь занято") для того, что бы просигнализировать, что это устройство "Занято" (но другие устройства, зарегистрированные на этого пользователя, будут продолжать звонить).
    Используйте код 6xx (600 - "Занято везде" или 603 - "Отклонено"_ что бы просигнализировать, что пользователь не хочет принимать этот сигнал ни на каком устройстве (все другие устройства также прекратят звонить).
  Обратите внимание: клиенту все-равно необходимо использовать операцию `callKill` для того, что бы освободить ресурсы, связанные с этим вызовом и сделать возможным повторное использование идентификатора вызова.

  Пример:
  Отвергаем входящий вызов `inp004` с кодом 603 "Declined":
  C:<callReject id="A020" callLeg="inp004" signalCode="603" />
  S:<response id="A020"/>
`callAccept`
  Используйте эту операцию для того, что бы принять входящий вызов.
  Атрибуты:
  `callLeg`
    идентификатор входящего звонка.
  Тело:
    XML представление дескриптора SDP клиента.
`callSendDTMF`
  Используйте эту операцию для отправки DTMF сигнала через канал сигнализации.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело:
    строка с DTMF кодом, который необходимо отправить (10 для '*', 11 для '#').

  Если операция заканчивается успешно, то сервер возвращает сообщение `callOpCompleted`.

  Если операция заканчивается неуспешно, то сервер возвращает сообщение `callOpFailed`.

`callUpdate`
  Используйте эту операцию для того, что бы изменить вызов (изменить SDP дескриптор вызова).
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело:
    XML представление нового дескриптора SDP клиента.

  Если операция заканчивается успешно, то сервер возвращает сообщение `callOpCompleted`.

  Если операция заканчивается неуспешно, то сервер возвращает сообщение `callOpFailed`.

  Клиент не должен пытаться выполнять другие операции (кроме операции `callKill`) с этим вызовом до получения сообщения `callOpCompleted` или `callOpFailed`.

`callTransfer`
  Используйте эту операцию, для того, что бы передать присоединённого участника другой стороне.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  `peer`
    адрес электронной почты или SIP URI, на которые необходимо передать звонок. Используйте этот атрибут для того, что бы начать "несопровождаемый перевод".
  `otherLeg`
    идентификатор вызова. Он должен указывать на некоторые другие "вызовы" в этой сессии. Задача должна находиться в режиме "connected". Используйте этот атрибут для завершения операции "сопровождаемого" перевода. Удалённый участник вызова "callLeg" соединяется с удалённым участником вызова "otherLeg".

  Если атрибут `otherLeg` указан, то атрибут`peer` игнорируется.

  Если операция перевода звонка завершилась успешно, то вызов "callLeg" отсоединяется (клиенту отправляется сообщение `callDisconnected`). В дополнении к этому, если операцией была операция "сопровождаемого" перевода, то клиент также получает сообщение `callDisconnected` и для вызова "otherLeg".

  Если операция перевода звонка заканчивается неуспешно, то сервер возвращает сообщение `callOpFailed`.

`callSendInfo`
  Используйте эту операцию для того, что бы передать присоединённому участнику сигнал INFO.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело:
    `MIME` XML элемент:
    Атрибуты:
    `type`
      Content-Type содержимого INFO.
    `subtype`
      подтип содержимого INFO (опционально).
    Тело:
      строка с данными содержимого INFO.

  Если операция заканчивается успешно, то сервер возвращает сообщение `callOpCompleted`.

  Если операция заканчивается неуспешно, то сервер возвращает сообщение `callOpFailed`.

`makeCall`
  Используйте эту операцию, для того, что бы совершить звонок с использованием любого зарегистрированного устройства или клиента. Сервер инициирует вызов аутентифицированному Пользователю ("само-вызов"), что приводит к тому, что все зарегистрированные устройства Пользователя начинают звонить. Когда любое устройство отвечает на звонок, то это устройство получает указание совершить вызов указанного адреса (или телефонного номера).
  Атрибуты:
  `peer`
    адрес электронной почты вызова или SIP URI вызова.
  `callerParams`
    опциональный атрибут, содержащий параметры SIP URI для "само-вызова".

  `makeCallReport` сообщения отправляются клиенту, информируя его о ходе звонка. Эта операция завершается или при установлении звонка, или когда операция заканчивается неуспешно, или после истечения отведённого на неё времени (15 секунд). Если вызов не был установлен до истечения времени, то операция завершается, но процесс совершения звонка продолжается.

Сервер может отправлять следующие сообщения данных:

`callProvisioned`
  Эти асинхронные сообщения данных отправляются, когда исходящий вызов находится в процессе обработки (после того, как Сервером был получен `callStart`):
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело (опционально):
    XML представление промежуточного отклика SDP.
`callDisconnected`
  Эти асинхронные сообщения данных отправляются, когда исходящий вызов заканчивается неуспешно, или когда входящий звонок был прерван, или когда установленный звонок отсоединяется:
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  `errorText`
    в этом опциональном атрибуте указывается причина отсоединения звонка.
  `signalCode`
    в этом опциональном атрибуте указывается числовой код ошибки.
  Обратите внимание: клиенту все-равно необходимо использовать операцию `callKill` для того, что бы освободить ресурсы, связанные с этим вызовом и сделать возможным повторное использование идентификатора вызова.
`callConnected`
  Эти асинхронные сообщения данных отправляются, когда исходящий вызов завершается успешно и устанавливается звонок:
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело:
    XML представление SDP удалённой стороны.
`callIncoming`
  Эти сообщения отправляются при получении новых входящих звонков (для получения входящих звонков вам необходимо использовать операцию `signalBind`):
  Атрибуты:
  `callLeg`
    идентификатор вызова. Сервер самостоятельно формирует эти идентификаторы.
  `peer`
    адрес электронной почты удалённого участника.
  `peerName`
    опционально; настоящее имя удалённого участника.
  Тело:
    XML представление SDP запроса.
`callUpdated`
  Эти сообщения отправляются когда существующий звонок изменяется (помещается на удержание, переключается на другого удалённого участника и т.д.).
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  `peer`
    опционально; адрес электронной почты удалённого участника. Он отправляется, когда звонок был переведён.
  `peerName`
    опционально; настоящее имя удалённого участника.
  Тело:
    XML представление изменённого SDP участника (опционально).
  Обратите внимание: Это сообщение может быть получено в то время, когда исходящий звонок все еще активен, что указывает на то, что другая сторона перехватила ("взяла") звонок.
`callOpCompleted`
  Эти сообщения отправляются, если операции, совершаемые во время звонка (такие как `callUpdate`, `callSendDTMF`, `callSendInfo`) были завершены.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
`callOpFailed`
  Эти сообщения отправляются, если операции, совершаемые во время звонка (такие как `callUpdate`, `callSendDTMF`, `callSendInfo`) закончились неуспешно.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  `errorText`
    текст сообщения об ошибке.
`callDTMF`
  Эти сообщения отправляются по получению сигнала DTMF через канал сигнализации.
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело:
    Строка с полученным числовым DTMF кодом.
`callInfo`
  Эти сообщения отправляются по получению сигнала INFO:
  Атрибуты:
  `callLeg`
    идентификатор вызова.
  Тело:
    аналогично операции `callSendInfo`.
`makeCallReport`
  Эти сообщения отправляются во время операции `makeCall`.
  Тело:
    Строка, содержащая статус текущей операции.

## Мгновенные Сообщения

Модель Мгновенных Сообщений подразумевает, что клиент обслуживает отдельное окно для каждого "участника", где "участником" является какой-либо другой пользователь Мгновенных Сообщений, обменивающийся Мгновенными Сообщениями.

`sendIM`
  Эта операция отправляет Мгновенное Сообщение указанному пользователю. Сервер отправляет XIMSS ответ не ожидая фактической доставки Мгновенного сообщения.
  Отдельная операция по открытию сессии Мгновенных Сообщений не производится. Если Сервер не имеет открытой сессии Мгновенных Сообщений с указанным участником, то создаётся новая сессия.
  Атрибуты:
  `peer`
    адрес электронной почты пользователя, которому необходимо отправить сообщение.
  Тело:
    текст Мгновенного Сообщения (в кодировке UTF-8) или элемент `composing`.
    Этот элемент должен отправляться в случае, если пользователь приготовил сообщение, но пока не отправил его.
`closeIM`
  Запрос на закрытие всех сессий Мгновенных Сообщений с указанным пользователем.
  Клиентское приложения должно отправлять этот запрос при закрытии окна обмена Мгновенными Сообщениями.
  Атрибуты:
  `peer`
    адрес электронной почты пользователя.

Сервер отправляет следующие сообщения данных:

`readIM`
  Эти асинхронные сообщения данных отправляются, когда Сервер получает Мгновенное Сообщение для клиента пользователя.
  Атрибуты:
  `peer`
    адрес электронной почты отправителя.
  `peerName`
    опционально; настоящее имя отправителя.
  Тело:
    Либо текст Мгновенного Сообщения (в кодировке UTF-8), либо элемент `composing` XML.
    Этот элемент отправляется, когда удалённый участник готовит сообщение, но пока не отправляет его.
  Операции явного открытия сессии не существует. Если у клиента отсутствуют открытое окно по обмену Мгновенными Сообщениями для указанного пользователя, то он должен открыть новое окно.
`errorIM`
  Эти синхронные сообщения данных отправляются, когда Сервер не смог доставить Мгновенное Сообщение.
  Атрибуты:
  `peer`
    адрес электронной почты получателя.
  `errorText`
    текст сообщения об ошибке.
  `errorNum`
    числовой код сообщения об ошибке.
  `sendid`
    атрибут `id` той операции `sendIM`, в которой произошла ошибка при отправке Мгновенного Сообщения.

## Ростер и Статус Присутствия

Модель Ростера и Статуса Присутствия похожа на соответствующую модель протокола XMPP.

Ростером является набор элементов данных, каждый из которых описывает "контакт" - некоторого другого локального или удалённого пользователя. Пользователь может быть наблюдать за информацией о статусе присутствия "контакта", а "контакту" могут быть предоставлены права на наблюдение за информацией о статусе присутствия пользователя.

`rosterList`
  Эта операция получает все активные элементы данных Ростера.
  Атрибуты:
  `accountName`
    если этот опциональный атрибут задан, то операция читает элементы Ростера указанного Пользователя.
  Сервер отправляет сообщения данных `rosterItem` для всех активных "контактов" Ростера.
`rosterSet`
  Эта операция изменяет "контакт" Ростера.
  Атрибуты:
  `accountName`
    если этот опциональный атрибут задан, то операция изменяет Ростер указанного Пользователя.
  `peer`
    адрес электронной почты контакта.
  `subscription`
    опциональный атрибут:
    - `update` или без атрибутов: изменяет информацию контакта.
    - `remove`: удаляет контакт из Ростера.
    - `subscribed`: подтверждает запрос контакта на наблюдение за информацией о статусе присутствия пользователя.
    - `unsubscribed`: отвергает запрос контакта на наблюдение за информацией о статусе присутствия пользователя или забирает ранее предоставленное право на наблюдение.
    - `subscribe`: отправляет запрос на наблюдение за информацией о статусе присутствия контакта.
    - `subBoth`: подтверждает запрос контакта на наблюдение за информацией о статусе присутствия пользователя и отправляет запрос на наблюдение за информацией о статусе присутствия контакта.
    - `unsubscribe`: останавливает наблюдение за информацией о статусе присутствия контакта.
  `name`
    опциональный атрибут, в котором содержится настоящее имя Контакта.
  Тело:
    набор XML элементов `group`; тело каждого элемента указывает имя Группы, которой принадлежит этого контакт.

  Операции `update`, `subscribed` и `subscribe` создают новый элемент данных Ростера, если ранее элемент данных с таким адресом не существовал.

`rosterGroupSet`
  Эта операция управляет Ростером "группы контактов".
  Атрибуты:
  `accountName`
    если этот опциональный атрибут задан, то операция изменяет Ростер указанного Пользователя.
  `group`
    имя группы.
  `mode`
    - `add`: создаёт новую группу контактов с указанным именем.
    - `delete`: удаляет существующую группу контактов с указанным именем из Ростера.
    - `rename`: переименовывает существующую группу контактов.
  `newName`
    новое имя группы контактов (используется только если атрибут `mode` имеет значение `rename`).
`presenceSet`
  Эта операция устанавливает статус присутствия пользователя. Сервер собирает информацию о статусе присутствия от всех подключенных клиентов (XIMSS, XMPP, SIP) и распространяет её всем сетевым субъектам, подписанным на эту информацию.
  Атрибуты:
  `type`
    этот опциональный элемент может иметь значение `unavailable`. Он указывает, что пользователь "как будто вне сети".
    Если этот атрибут отсутствует, то пользователь находится в сети.
  Тело:
    опциональный XML элемент `show`; его текстовое тело указывает статус присутствия пользователя в стиле XMPP:
    - `dnd` - Не беспокоить, Занят(а), На телефоне.
    - `away` - Скоро вернусь, На совещании, На перерыве.
    - `xa` - Нет на месте ("расширенное" Нет на месте).
    В качестве альтернативы вы можете использовать XML элемент `presence` вместо XML элемента `show`. Тело текстового XML элемента `presence` содержит более подробный статус присутствия пользователя:
    - `offline` - "как будто вне сети".
    - `online` - В сети.
    - `on-phone` - пользователь в настоящее время разговаривает.
    - `in-meeting` - пользователь находится на совещании.
    - `busy` - общая форма для "не могу сейчас говорить".
    - `be-back` - пользователь скоро вернётся
    - `out-lunch` - пользователь вышел на перерыв.
    - `away` - Нет на месте.

  При начале сессии пользователь находится "как будто вне сети". Клиент должен использовать эту операцию, для того, что бы показать, что пользователь находится в сети.

  Когда пользователь отсоединяется, статус его сессии автоматически меняется на `unavailable` (вне сети).

Сервер отправляет следующие сообщения данных:

`rosterItem`
  Эти сообщения данных отправляются синхронно при обработке Сервером запроса `rosterList`. Для каждого элемента данных Ростера (для каждого "Контакта") отправляется одно сообщение.
  Эти сообщения данных также могут быть отправлены асинхронно (смотрите ниже).
  Атрибуты:
  `peer`
    адрес электронной почты контакта.
  `subscription`
    - `to`: пользователь может наблюдать за контактом.
    - `from`: контакт может наблюдать за пользователем.
    - `both`: пользователь и контакт могут наблюдать друг за другом.
    - `both`: пользователь и контакт не могут наблюдать друг за другом.
  `ask`
    этот опциональный атрибут имеет значение `subscribe` если пользователь затребовал подписку на информацию о статусе присутствия контакта, но этот запрос еще не был подтверждён.
  `name`
    опциональный атрибут, в котором содержится настоящее имя Контакта.
  Тело:
    набор XML элементов `group`; тело каждого элемента указывает имя Группы, которой принадлежит этого контакт.
  Если для разрешения уведомлений Ростера и Статуса Присутствия была использована `операция` signalBind:
  - Каждый раз, когда элемент данных Ростера добавляется или изменяется, Сервер отправляет сообщения `rosterItem` с новыми или изменёнными данными.
  - Каждый раз, когда элемент данных Ростера удаляется, Сервер отправляет сообщения `rosterItem` с атрибутом `subscription`, имеющим значение `remove`.
  - Сервер отправляет сообщения данных `presence`.
`presence`
  Эти асинхронные сообщения данных отправляются когда статус присутствия некоторого "контакта" (элемента) Ростера изменяется и уведомленя об изменении Статуса включены.
  Атрибуты:
  `peer`
    адрес электронной почты контакта.
  `type`
    опциональный атрибут:
    - `unavailable`: контакт находится вне сети.
    - `subscribe`: контакт требует подписку на информацию о статусе присутствия пользователя.
    - absent: контакт в сети.
  Тело:
    XML элемент `presence`; его текстовое тело указывает детализированный статус присутствия контакта (смотрите выше);
    опциональный XML элемент `show`; его текстовое тело указывает статус присутствия контакта в стиле XMPP (смотрите выше).

## Настройки

Клиент может получать и изменять Настройки аутентифицированного пользователя и данные О Себе ("Публично Доступные").

`prefsRead`
  Эта операция получает Настройки аутентифицированного пользователя или его данные "О Себе" ("Публично Доступные").
  Атрибуты:
  `type`
    это опциональный параметр.
    Если указанное значение является `default`, то возвращаются Настройки, задаваемые для Пользователя Домена по умолчанию.
    Если указанное значение является `custom`, то возвращаются явно указанные Настройки Пользователя.
    Если его значением является `publicInfo`, то запрашиваются настройки Пользователя "О Себе" ("Публично Доступные").
    Если атрибут не указан, то будут получены все фактически действующие Настройки Пользователя.
  Тело:
    Ноль или более XML элементов `name`. Тело этих элементов задаёт имена получаемых элементов; если не указано ни одного элемента `name`, то получаются все элементы Настройки или элементы "О Себе" ("Публично Доступные").
`prefsStore`
  Эта операция изменяет Настройки аутентифицированного пользователя или его данные "О Себе" ("Публично Доступные").
  Атрибуты:
  `type`
    это опциональный параметр.
    Если его значением является `publicInfo`, то изменяется настройки Пользователя "О Себе" ("Публично Доступные").
    Если атрибут не указан, то будут обновлены все изменённые Настройки Пользователя.
  Тело:
    XML элементы с именами, совпадающими с именами элементов Настройки. Тело элемента содержит новое значение элемента Настройки. Если значением является строка `default`, то значения пользовательских Настроек или настроек "О Себе" ("Публично Доступные") удаляются и фактически действующими Настройками Пользователя становятся Настройки по умолчанию.
    Если значение является массивом, то он должен быть представлен с использованием XML представления `aray`.
    Если значением является словарь, то он должен быть представлен с использованием XML представления `dictionary`.

  Если тело содержит элемент `UserFromAddr`, то Сервер использует этот элемент и опциональный элемент `UserFromName` для составления элемента `UserFrom`, имеющим значение адрес электронной почты (в формате "UserFromName_value" <UserFromAddr_value>).

`prefsReload`
  Реализация некоторых операция Cервером (таких, как удаление сообщений) зависит от значениях Настроек, читаемых при открытии сессии. Когда какая-либо сессия изменяет Настройки, то клиент может использовать эту операцию для того, что бы Сервер обновил их "кэшированные" значения.
  Атрибуты:
    отсутствуют

Сервер отправляет следующие сообщения данных:

`prefs`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `prefsRead`.
  Атрибуты:
  `type`
    опциональный атрибут, такой же, как и атрибут запроса.
  Тело:
    XML элементы с именами, совпадающими с именами элементов "О Себе". В теле элемента содержится значение элемента.
    Если значение является массивом, то он представляется с использованием XML представления `aray`.
    Если значением является словарь, то представляется с использованием XML представления `dictionary`.

  Если данные `prefs` содержат строку `UserFrom`, то Сервер пытается разобрать этот адрес электронной почты. Если адрес может быть разобран, то к телу сообщения данных добавляется элемент `UserFromAddr` (содержащим "чистый" адрес `userName@domainName`) и, опционально, элемент `UserFromName` (с комментарием адреса).

`prefsModified`
  Эти асинхронные сообщения данных отправляются при изменении Настроек Пользователя (в этой сессии, в другой сессии или некоторым другим компонентом Сервера GommuniGate Pro). Рекомендуется, что бы в ответ на это сообщение клиент прочитал Настройки Пользователя заново.

## Операции с Хранилищем Файлов

Клиент может работать с Хранилищем Файлов Пользователя.
Если аутентифицированный пользователь имеет право администратора домена CanAccessWebSites (Полный доступ ко всем Файлам), то этот клиент, используя префикс перед именем файла `~accountName/fileName`, может также работать с файлами, принадлежащими другому Пользователю.

`fileList`
  С помощью этой операции можно получить список имеющихся файлов.
  Атрибуты:
  `directory`
    опциональный атрибут с именем поддиректории в Хранилище Файлов. Если он отсутствует, то возвращается содержимое верхней директории Пользователя в Хранилище Файлов.
  Сервер возвращает одно сообщение `fileInfo` для каждого файла или директории, находящихся в указанной директории в Хранилище Файлом.
`fileDirInfo`
  Эта операция возвращает информацию о всех файлах Пользователя или обо всех файлах, находящихся в указанной директории.
  Атрибуты:
  `directory`
    опциональный атрибут с именем поддиректории в Хранилище Файлов. Если он отсутствует, то возвращается информация обо всех файлах в Хранилище Файлов Пользователя.
  Сервер возвращает одно сообщение `fileDirInfo`.
`fileDirList`
  С помощью этой операции можно получить список имеющихся всех папок в Хранилище Файлов. Сервер возвращает одно сообщение `fileDirName` для каждой директории Хранилища Файлов.
`fileWrite`
  Эта операция сохраняет данные в файл.
  Атрибуты:
  `fileName`
    имя записываемого файла.
  `position`
    Если этот атрибут отсутствует, то эта операция полностью перезаписывает указанный файл. Если файл не существовал, то он создаётся.
    Если значением этого атрибута является `append`, то эта операция добавляет данные в конец файла (атомарно).
    Если значением этого атрибута является `new`, то эта операция сначала проверяет что указанный файл не существует, а затем создаёт файл и сохраняет в нём данные.
    Если значением этого атрибута является число, то файл должен существовать, а операция перезаписывает файл, начиная с позиции (байта), указываемого этим числом.
  `type`
    Если этот опциональный атрибут существует и его значением является `binary`, то телом запроса является XML элемент `base64`; перед записью в файл тело раскодируется из base64.
    Если этот опциональный атрибут существует и его значением является `object`, то телом запроса является XML представление данных, содержащихся в Object; в файл записывается текстовое представление этого Объекта. Если этот значение используется, то атрибут `position` не должен указываться.
    Если этот опциональный атрибут существует и его значением является `xml`, то тело запроса должно быть одним XML элементом. Его текстовое представление записывается в файл. Если этот значение используется, то атрибут `position` не должен указываться.
  Тело:
    Или текст с данными файла, или XML элемент `base64`, или XML представление объекта, или XML элемен для записи в файл.
`fileStore`
  Эта операция сохраняет загруженный на сервер файл или MIME часть сообщения как файл в Хранилище Файлов.
  Атрибуты:
  `fileName`
    имя создаваемого файла.
  `uploadID`
    строка, идентифицирующая файл в "наборе загруженных файлов".
  `folder`, `UID`, `partID`
    эти атрибуты имеют тот же смысл, что и атрибуты операции `fileRead`. Они идентифицируют MIME часть сообщения, которую необходимо получить, раскодировать и сохранить как файл.
  `calendar`
    используйте этот атрибут вместо атрибута `folder` для копирования MIME части из открытого Календаря, а не из папки с сообщениями электронной почты.
  `position`
    Если этот опциональный атрибут указан и значением этого атрибута является `new`, то эта операция сначала проверяет, что указанный файл не существует, а затем создаёт файл и копирует в него загруженный файл или данные из MIME части.
  Если файл с таким именем уже существует, то старый файл сначала удаляется.
  Должен быть задан или атрибут `uploadID`, или атрибут `folder`, или атрибут `calendar`. Никакие из этих двух атрибутов не могут быть заданы одновременно в одной операции `fileStore`.
`fileRead`
  Эта операция читает данные из файла.
  Атрибуты:
  `fileName`
    имя файла, который необходимо прочитать.
  `position`
    Этот числовой атрибут задаёт позицию файла, с которой начинается чтение. Если этот атрибут отсутствует, то файл читается с начала (с позиции 0).
  `limit`
    Этот числовой атрибут задаёт максимальный размер читаемой порции данных. Если он указан, то он не должен превышать 3 Мб. Если он не указан, то используется ограничение в 3Мб.
  `type`
    Если этот опциональный атрибут существует и его значением является `binary`, то данные файла возвращается в кодировке base64 как тело XML элемента `base64`.
    Если этот опциональный атрибут существует и его значением является `object`, то данные файла разбираются как текстовое представление Object и возвращается XML прдставление Объекта. Если используется это значение, то атрибуты `position` и `length` не должны указываться и размер файла не должен превышать 3 Мб.
    Если этот опциональный атрибут существует и его значением является `xml`, то данные файла разбираются как XML документ и возвращается XML содержимое. Если используется это значение, то атрибуты `position` и `length` не должны указываться и размер файла не должен превышать 3 Мб.
  Сервер возвращает сообщение `fileData`.
`fileRename`
  Эта операция переименовывает файл в Хранилище Файлов.
  Атрибуты:
  `fileName`
    имя файла, который необходимо переименовать.
  `newName`
    новое имя файла.
`fileRemove`
  Эта операция удаляет файл из Хранилища Файлов.
  Атрибуты:
  `fileName`
    имя файла, который необходимо удалить.
`fileCopy`
  Эта операция копирует файл или содержимое сообщения в файл в Хранилище Файлов.
  Атрибуты:
  `newName`
    имя создаваемого файла (для копии файла). Если файл с этим именем уже существует, то он удаляется.
  `fileName`
    опционально: этот параметр задаёт имя файла, которое необходимо скопировать.
  Тело:
    опциональный элемент `copyMIME`. Он задаёт часть сообщения, которую необходимо декодировать с скопировать в указанный файл.
  Операция должна иметь либо атрибут `fileName`, либо один элемент тела `copyMIME`.
`fileDirCreate`
  Эта операция удаляет создаёт файловую директорию в Хранилище Файлов.
  Атрибуты:
  `fileName`
    имя файловой директории, которая будет создана.
`fileDirRename`
  Эта операция переименовывает директорию в Хранилище Файлов.
  Атрибуты:
  `fileName`
    имя переименовываемой директории.
  `newName`
    новое имя директории.
`fileDirRemove`
  Эта операция удаляет директорию из Хранилища Файлов.
  Атрибуты:
  `fileName`
    имя удаляемой директории. Удалены могут быть только пустые директории.

Сервер отправляет следующие сообщения данных:

`fileInfo`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `folderList`.
  Атрибуты:
  `fileName`
    имя файла или поддиректории.
  `directory`
    опциональный атрибут, аналогично атрибуту `directory` в запросе `fileList`.
  `type`
    опциональный атрибут существует и содержит значение `directory`, если это сообщение описывает поддиректорию.
  `size`
    опциональный атрибут с размером файла в байтах (отсутствует, если это сообщение описывает поддиректорию).
  `timeModified`
    опциональный атрибут, в котором находится дата и время изменения файла (местное время).
`fileDirInfo`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `fileDirInfo`.
  Атрибуты:
  `directory`
    опциональный атрибут, аналогично атрибуту `directory` в запросе `fileDirInfo`.
  `files`
    общее число файлов Пользователя или в указанной поддиректории (и во всех вложенных директориях).
  `size`
    общий размер всех файлов (в байтах).
`fileDirName`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `fileDirList`.
  Атрибуты:
  `directory`
    имя директории Хранилища Файлов.
`fileData`
  Это сообщение отправляется, когда Сервер обрабатывает запрос `fileRead`.
  Атрибуты:
  `fileName`
    имя файла для чтения.
  `position`
    позиция, начиная с которое читаются данные файла.
  `slice`
    размер читаемых данных (в байтах). Для того, что бы получить новое значение `position` и прочитать следующую порцию файла, сложите значения `position` и `slice`.
  `size`
    общий размер файла.
  `timeModified`
    опциональный атрибут, в котором находится дата и время изменения файла (местное время).
  `type`
    копия атрибута `type` из запроса.
  Тело:
    Или текст с данными файла, или `base64` (телом являются данные в кодировке base64), или XML представление содержимого файла с Объектом.

  Примеры:
  C:<fileRead id="A001" fileName="test.txt" />
  S:<fileData id="A001" fileName="test.txt"position="0" slice="22" size="22" timeModified="20061018T115836">This is not your file!</fileData>
  S:<response id="A001"/>
  C:<fileRead id="A002" fileName="test.txt" limit="15" />
  S:<fileData id="A002" fileName="test.txt"position="0" slice="15" size="22" timeModified="20061018T115836">This is not you</fileData>
  S:<response id="A002"/>
  C:<fileRead id="A003" fileName="test.txt" limit="15" position="15" />
  S:<fileData id="A003" fileName="test.txt"position="15" slice="7" size="22" timeModified="20061018T115836">r file!</fileData>
  S:<response id="A003"/>
  C:<fileRead id="A004" fileName="test.txt" limit="15" position="15" type="binary" />
  S:<fileData id="A004" fileName="test.txt"position="15" slice="7" size="22" timeModified="20061018T115836"><base64>ciBmaWxlIQ==</base64></fileData>
  S:<response id="A004"/>
  C:<fileRead id="A005" fileName="test.txt" position="25" />
  S:<response id="A005" errorText="reading beyond the EOF mark" errorNum="500" />

## Управление Автоматическими Правилами

Клиент может работать с Автоматическими Правилами Пользователя. Наборы Правил адресуются с использованием параметра `type`. Поддерживаются следующие значения параметров:

- `mailIn` - входящие почтовые Правила (Правила Очереди) .
- `signalIn` - входящие Правила Сигналов.

Каждое Правило в наборе имеет атрибуты с именем и приоритетом. Правила Сигналов также имеют атрибут `stage`, указывающий, когда должно применяться Правило.

Каждое Правило содержит ноль или более элементов `condition`, ноль или более элементов `action` и ноль или один элемент `comment`:

`condition`
  Дополнительную информацию смотрите в разделе Правила.
  Атрибуты:
  `opCode`
    данные условия Правил.
  `operator`
    операция условия Правил.
  Тело:
    параметр условия Правила.
`action`
  Дополнительную информацию смотрите в разделе Правила.
  Атрибуты:
  `opCode`
    операция действия Правила.
  Тело:
    параметр действия Правила.
`comment`
  Тело:
    текст комментария к Правилу.

Пример:
Почтовое Правило, сохраняющее все сообщения с `X-Junk: 5` поле заголовка в Папке `Junk`. Исключение сделано для сообщений, приходящих от аутентифицированных пользователей.
<rule type="mailIn" name="Junk Filter" priority="2" >
<condition opCode="Header Field" operator="is">X-Junk: 5*</condition>
<condition opCode="Source" operator="is not">authenticated</condition>
<action opCode="Store in">Junk</action>
<action opCode="Discard"></action>
<comment>This is my test Rule&#x21;</comment>
</rule>

`ruleList`
  Эта операция предписывает Серверу отправить сообщение `rule` для каждого Правила указанного типа, существующего у Пользователя. Эти сообщения не имеют тела.
  Атрибуты:
  `type`
    набор Правил.
`ruleRead`
  Эта операция предписывает серверу отправить одно или более сообщений `rule` для указанного Правила. В теле этого сообщения содержатся XML элементы с условиями Правил, действиями и опциональный комментарий.
  Атрибуты:
  `type`
    набор Правил.
  `name`
    имя Правила.
`ruleSet`
  Эта операция сохраняет новое Правило. Если есть существующее Правило с таким же именем, то оно удаляется.
  Пользователь должен иметь право указывать условия и действия, используемые как в новых, так и в старых Правилах.
  Атрибуты:
  `type`
    набор Правил.
  `name`
    имя Правила.
  `priority`
    приоритет Правила.
  `stage`
    стадия применения Правила (для Правил Сигналов).
  Тело:
    аналогично XML элементам, используемым в сообщении `rule`: ноль или более элементов `condition`, ноль или более элементов `action` и ноль или один элемент `comment`.
`ruleUpdate`
  Эта операция изменяет приоритет Правила и/или его стадию применения (для Правил Сигналов).
  Пользователь должен иметь право указывать условия и действия, используемые в изменяемом Правиле.
  Атрибуты:
  `type`
    набор Правил.
  `name`
    имя Правила.
  `priority`
    приоритет Правила.
  `stage`
    стадия применения Правила (для Правил Сигналов).
`ruleRename`
  Эта операция переименовывает существующее Правило.
  Пользователь должен иметь право указывать условия и действия, используемые в переименовываемом Правиле.
  Атрибуты:
  `type`
    набор Правил.
  `name`
    имя существующего Правила.
  `newName`
    новое имя Правила.
`ruleRemove`
  Эта операция удаляет существующее Правило.
  Пользователь должен иметь право указывать условия и действия, используемые в удаляемом Правиле.
  Атрибуты:
  `type`
    набор Правил.
  `name`
    имя существующего Правила.

Сервер отправляет следующие сообщения данных:

`rule`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `ruleList` или `ruleRead`. Смотрите выше формат сообщения `rule`.

## Дистанционное обслуживание POP

RPOP записи представлены следующими XML элементами:

`rpopRecord`
  Атрибуты:
  `UID`
    уникальный числовой идентификатор записи.
  `host`
    имя домена или IP адрес удалённой почтовой системы.
  `account`
    имя пользователя удалённой почтовой системы.
  `password`
    пароль пользователя в удалённой почтовой системе.
  `leave`
    атрибут существует и имеет значение yes если почтовые сообщения не должны удаляться с удалённой почтовой системы после их получения.
  `TLS`
    атрибут существует и имеет значение yes если с удалённой почтовой системой должно устанавливаться безопасное соединение при помощи протоколов SSL/TLS.
  `APOP`
    атрибут существует и имеет значение yes если для входа на удалённую почтовую системы должен использоваться метод входа APOP.

Клиент может работать с записями о RPOP Источниках Пользователя.

`rpopList`
  Эта операция предписывает Серверу отправить одно сообщение `rpopRecord` для каждой RPOP записи Пользователя.
  Атрибуты:
  отсутствуют
`rpopUpdate`
  Эта операция обновляет набор RPOP записей Пользователя.
  Пользователь должен иметь право изменять RPOP записи.
  Атрибуты:
  отсутствуют
  Тело:
    один или несколько элементов `rpopRecord`. Эти элементы должны иметь дополнительный атрибут:
    `mode`
      если значением этого атрибута является `delete`, то используется только атрибут `UID`. PROP запись с таким атрибутом UID удаляется из набора RPOP записей Пользователя.
      если значением этого атрибута является `add`, то RPOP запись добавляется в набор RPOP записей. Если атрибут `UID` существет, то старая RPOP запись с таким UID удаляется из набора RPOP записей. Если атрибут `UID` отсутствует, то генерируется новый уникальный UID и он добавляется к записи.

Сервер отправляет следующие сообщения данных:

`rpopRecord`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `rpopList`. Смотрите выше формат сообщения `rpopRecord`.

## Управление Приложениями Реального Времени

Клиент может взаимодействовать с Приложениями Реального Времени, запущенными на Сервере или в Кластере CommuniGate Pro.

Сессия XIMSS может взаимодействовать с Задачами, отправляя им События. Задачи воспринимают сессию XIMSS просто как другую Задачу, так что они также могут отправлять обратно События.

Каждая сессия XIMSS обслуживает список Описателей Задач для тех Задач, с которыми она взаимодействует. Каждый описатель в списке связан с строкой taskID. XIMSS клиент использует эти строки taskID для нахождения Задачи в списке.

`taskFindMeeting`
  В этой операции реализована операция FindMeeting. Дополнительную информацию смотрите в разделе CG/PL.
  Атрибуты:
  `meetingSet`
    опционально, имя набора Встречи. Если значение этого параметра опущено или является пустой строкой, то используется Набор Встречи, применяемый по умолчанию.
  `meetingName`
    уникальный идентификатор новой Встречи.
  Если эта операция заканчивается успешно, то Сервер возвращает сообщение `taskMeeting` с обнаруженными данными встречи.
`taskCreateMeeting`
  Эта операция реализует выполнение операции CreateMeeting. Дополнительную информацию смотрите в разделе CG/PL.
  Атрибуты:
  `meetingSet`
    опционально, имя набора Встречи. Если значение этого параметра опущено или является пустой строкой, то используется Набор Встречи, применяемый по умолчанию.
  `meetingName`
    уникальный идентификатор новой Встречи.
  Тело:
    Текст, добавляемым в Событию Встреча в качестве параметра.
`taskRemoveMeeting`, `taskClearMeeting`, `taskActivateMeeting`, `taskDeactivateMeeting`
  В этих операциях реализовано выполнение операций Встречи. Дополнительную информацию смотрите в разделе CG/PL.
  Атрибуты:
  `meetingSet`
    опционально, имя набора Встречи. Если значение этого параметра опущено или является пустой строкой, то используется Набор Встречи, применяемый по умолчанию.
  `meetingName`
    уникальный идентификатор новой Встречи.
`taskSendEvent`
  Эта операция отправляет Задаче Событие.
  Атрибуты:
  `taskRef`
    внутренний taskID Задачи, который отправляется Событие.
  `eventName`
    имя отправляемого События.
  Тело:
    опциональный текст или XML представление объекта данных, которые будут отправлены как параметр События.
`taskStart`
  Эта операция запускает Задачу Приложения Реального Времени.
  Если операция заканчивается успешно, то сервер отправляет сообщение данных `taskCreated`.
  Атрибуты:
  `programName`
    имя приложения.
  `entryName`
    этот опциональный атрибут задаёт имя точки входа в программу; если он не указан, то программа запускается с точки входа `main`.
  Тело:
    набор XML элементов `param`. Текстовые тела этих элементов помещаются в массив `startParameter` Задачи.
`taskClose`
  С каждым внутренним taskID связываются некоторые определённые ресурсы сессии. Если ваш клиент работает со многими задачами, то по завершению взаимодействия с какой-либо Задачей рекомендуется использование операции taskClose, что освобождает все внутренние ресурсы taskID.
  Если та же Задача отправляет в эту сессию Событие или Описатель Задачи был обнаружен другим способов, то в этой сессии этой Задаче присваивается новый taskID.
  Атрибуты:
  `taskRef`
    освобождаемый внутренний taskID.

Сервер отправляет следующие сообщения данных:

`taskMeeting`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `taskFindMeeting`.
  Атрибуты:
  `meetingSet`, `meetingName`
    копия атрибутов запроса `taskFindMeeting`.
  `taskRef`
    опциональный атрибут: внутренний taskID Задачи, который активировал эту Встречу.
  `expires`
    опциональный атрибут с дата и временем (GMT) окончания срока действия Встречи.
  Тело:
    XML представление параметров Встречи.
`taskCreated`
  Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос `taskStart`.
  Атрибуты:
  `taskRef`
    внутренний taskID созданной Задачи.
`taskEvent`
  Это асинхронное сообщение данных отправляется, когда некоторая Задача или сам Сервер отправляет в текущую сессию XIMSS Событие.
  Атрибуты:
  `taskRef`
    внутренний taskID Задачи, отправившей Событие. Если этот атрибут отсутствует, то Событие было создано и отправлено самим Сервером.
  `eventName`
    имя полученного События.
  Тело:
    Текст или XML представление параметров События.

## Directory

Клиент может получать доступ к глобальному Справочнику.

`listDirectory`
  Эта операция получает данные из Справочника.
  Атрибуты:
  `baseDN`
    DN записи справочника, с которой начинается поиск. Если значением атрибута является `$`, то baseDN устанавливается в то поддерево Справочника, в котором содержатся записи для текущего Домена Пользователя.
  `filter`
    этот опциональный атрибут задаёт фильтр поиска в формате RFC2254.
  `scope`
    в этом опциональном атрибуте задаётся тип поиска:
    - `base` - baseDN получаемой записи (атрибут filter игнорируется)
    - `one` (по умолчанию) - поиск осуществляется непосредственно в baseDN поддерева (одноуровневый поиск))
    - `sub` - поиск осуществляется во всём baseDN поддерева (многоуровневый поиск)
  `limit`
    в этом опциональном атрибуте задаётся новый пароль.
  Тело (опционально):
    набор XML элементов `field`. Каждый элемент должен иметь текстовое тело, содержащее имя получаемого атрибута. Если элемент `field` не указан, то возвращаются все неслужебные атрибуты записи Справочника.
    Обратите внимание: если атрибут `mail` указан явно, то Сервер сформирует значение этого атрибута для всех записей объектов CommuniGate Pro, у которых он отсутствует.
  Сервер отправляет сообщение `directoryData` для каждой найденной записи.

Сервер отправляет следующие сообщения данных:

`directoryData`
  Это синхронное сообщение данных отправляется для каждой записи Справочника, возвращаемой в ответ на запрос `listDirectory`.
  Атрибуты:
  `name`
    DN записи.
  Тело:
    XML представление атрибутов Записи.

## Наборы Данных

Клиент может управлять наборами данных Пользователя - например, такими, как набор данных `RepliedAddresses` (авто-отвеченные).

Для доступа к Набору данных другого Пользователя, имя набора набора данных должно быть задано как `~accountName/datasetName` или `~accountName@domainName/datasetName`

`datasetRemove`
  Эта операция удаляет набор данных Пользователя.
  Атрибуты:
  `dataset`
    имя удаляемого набора данных.
  `ifExists`
    если значением этого опционального атрибута является yes и набор данных не существует, то сообщение об ошибке не создаётся.
`datasetAddAddress`
  Эта операция добавляет адрес в набор данных Пользователя.
  Атрибуты:
  `dataset`
    имя набора данных, к которому будет добавлен адрес электронной почты.
  `realName`
    в этом опциональном атрибуте задаётся "настоящее имя" адреса электронной почты.
  Тело:
    Строка с адресом электронной почты.
`datasetList`
  Эта операция получает данные из набора данных Пользователя.
  Атрибуты:
  `dataset`
    имя читаемого набора данных.
  `filterField`, `filter`
    эти опциональные атрибуты задают значение и имя атрибута данных. Если они указаны, то операция возвращает только те данные, у которых указанный атрибут имеет указанное значение.
  Сервер отправляет сообщение `datasetData` для каждой найденной записи.
`datasetSet`
  Эта операция изменяет данных в наборе данных Пользователя.
  Атрибуты:
  `dataset`
    имя изменяемого набора данных.
  Тело:
    Элемент `datasetData`. атрибут `name` задаёт имя данных из набора данных, которые необходимо изменить или создать. Если оно не указано, то для новой записи генерируется случайно имя.
    Телом элемента должно быть XML представление изменяемых атрибутов данных.
`datasetDelete`
  Эта операция удаляет данные из набора данных Пользователя.
  Атрибуты:
  `dataset`
    имя изменяемого набора данных.
  `name`
    имя удаляемых данных из набора данных.

Сервер отправляет следующие сообщения данных:

`datasetData`
  Это синхронное сообщение данных отправляется для каждой записи из набора данных, возвращаемой в ответ на запрос `datasetList`.
  Атрибуты:
  `name`
    имя данных из набора данных.
  Тело:
    XML представление атрибутов данных из набора данных.

## Тарификация

Клиент может работать со средствами на Остатках Пользователя.

`balance`
  Эта операция выполняет операцию Тарификации.
  Атрибуты:
  accountName
    имя требуемого пользователя (опционально). Если не указано, то операция применяется для Пользователя, которому принадлежит данная сессия.
  Тело:
    XML представление словаря. Словарь содержит операцию Тарификации (элемент `op`) и параметры операции.
  Если операция генерирует какой-либо результат, то сервер возвращает сообщение `balanceData`.

Сервер отправляет следующие сообщения данных:

`balanceData`
  Это синхронное сообщение данных отправляется, когда операция `balance` генерирует какой-либо роезультат.
  Атрибуты:
  accountName
    имя целевого пользователя (опционально, аналогично указанному в запросе операции `balance`.
  Тело:
    XML представление словаря с результатами.

## Получение Рекламы

Клиент может задействовать Внешнюю Рекламную Систему.

`bannerRead`
  Эта операция получает рекламную информацию. Если операция генерирует какой-либо результат, то сервер возвращает сообщение `banner`.
  Атрибуты:
  type
    тип получаемой рекламы (зависит от приложения, например prontoEmailTop, myClientLeftBanner).
  Тело:
    (опционально) XML представление параметров объекта из Внешней Рекламной Системы.

Сервер отправляет следующие сообщения данных:

`banner`
  Это синхронное сообщение данных отправляется, когда операция `bannerRead` генерирует какой-либо роезультат.
  Атрибуты:
  type
    имеет то же значение, что и в операции `bannerRead`.
  Тело:
    (опционально) XML представление результирующего объекта из Внешней Рекламной Системы.

## Форматы Данных XML

Элементы данных представляются в XML формате с использованием следующих соглашений.

### `EMail`

Этот XML элемент представляет сообщение электронной почты или его MIME подчасть в соответствии с RFC822.

Тело:
  набор XML элементов, содержащих поля заголовка сообщения электронной почты, такие как `From`, `Date` и т.д., не включая поля MIME, связанные с содержанием (такие как `Content-Type`),
  и (опционально) элемент `MIME` с телом сообщения.

  Типом каждого XML элемента является имя поля:

    `<Subject>Hello, world!</Subject>`
  Категории полей:
  Адреса: `From`, `To`, `Cc`, `Bcc`, `Return-Path`, `Sender`, `Reply-To`, `Disposition-Notification-To`, `Recent-From`, `Recent-To`, `Return-Receipt-To`, `Errors-To`
    Телом элемента является адрес электронной почты в формате `userName@domainName` или в более общем формате `userName`[`%domainA`[`%domainB`]]`@domainName`.
    Эти элементы может содержать атрибут `realName` - MIME декодированный адрес части имени или комментарий.
    Если поле содержит несколько адресов, то создаётся несколько XML элементов, так, что каждый элемент содержит в точности один адрес.
  Отметки о Времени: `Date`, `Resent-Date`
    Эти элементы содержат:
    атрибут `timeShift` - разница в секундах между местным временем указанным в поле и соответствующим GMT временем.
    атрибут `localTime`, указывающий значение времени поля (в формате iCalendar) в часовом поясе, выбранном для текущего пользователя.
    Телом элемента является глобальное значение времени поля (GMT) в формате iCalendar.
  `Pty`
    Телом этих элементов являются строки `High` или `Low`. Эти значения преобразовываются в числовые значения (и из числовых значений) поля заголовка `X-Priority`.
  Phones: `X-Telnum`
    Тело элемента является телефонным номером.
    Эти элементы могут содержать атрибут `type` (`WORK`, `CELL`, `HOME`, `AGENT` и т.п.), указывающий на тип телефонного номера/адреса.
    Если поле содержит несколько телефонных номеров, то создаётся несколько XML элементов, так, что каждый элемент содержит в точности один телефонный номер.
  Unstructured
    Все поля, не перечисленные в предыдущих категориях, относятся к этой категории.
    Тело элемента содержит MIME-декодированное значение поля.

Пример:
From: "Mr. Sender." <user1@example.com>
To: user2@example.com (My Friend),
=?iso-8859-1?Q?=4Eot=20A=20Friend?= <user2@example.com>
Date: Mon, 10 Apr 2006 13:15:48 -0700
Subject: It's 1:15PM now, the meeting has started!

<EMail>
<From realName="Mr. Sender.">user1@example.com</From>
<To realName="My Friend">user2@example.com</To>
<To realName="Not A Friend">user3@example.com</To>
<Bcc>user1@example.com</Bcc>
<Date timeShift="-25200" localTime="20060410T151548">20060410T201548Z</Date>
<Subject>It's 1:15PM now, the meeting has started!</Subject>
</EMail>

### `MIME`

XML элемент представляет тело сообщения или его часть (далее в этом разделе - "часть").

Атрибуты:
`partID`
  эта строка указывает размещение MIME части в сообщении. Она может использоваться для получения части сообщения.
`estmatedSize`
  ориентировочный размер (в байтах) данных части, после декодирования данных части.
`type`
  тип части `Content-Type`, без информации о подтипе.
`subtype`
  подтип части `Content-Type`, если есть.
`charset`
  кодировка части (если отсутствует, то подразумевается UTF-8).
`contentID`
  строка `Content-ID` (не заключённая в угловые скобки).
`disposition`
  строка `Content-Disposition` (без параметров).
`description`
  строка `Content-Description`.
`location`
  строка `Content-Location`.
`class`
  строка `Content-Class` после удаления префиксов `urn:` и `content-classes:`.
`Type-name`
  любой параметр поля Content-Type name и его значение, за исключением параметров `boundary`, `charset` и `format`.
`Disposition-name`
  любой параметр поля Content-Disposition name и его значение.
Тело:
  Тело элемента являетс опциональным. Если оно присутствует, оно содержит данные тела части.
  Если Сервер не смог прочитать данные тела части элемента, то к элементу добавляется атрибут `readError`. Значение атрибута содержит код ошибки чтения.
  Если Сервер не смог разобрать данные тела части элемента, то к элементу добавляется атрибут `parseError`. Значение атрибута содержит код ошибки разбора.
  Формат элемента зависит от части `Content-Type` (символ "*" ниже обозначает любой Content-Type или подтип):
  `multipart/*`
    Ноль или более XML элементов `MIME`, в которых содержатся подчасти сообщения.
  `message/rfc822`
    XML элемент `EMail` для вложенного сообщения.
  `text/rfc822-headers`
    XML элемент `EMail` (не содержащий никакого элемента тела `MIME`).
  `text/directory`, `text/x-vcard`
    Ноль или более XML элементов `vCard`.
  `text/x-vgroup`
    Одни XML элемент `vCardGroup`.
  `text/calendar`
    XML элемент `iCalendar`.
  `message/disposition-notification`, `message/delivery-status`
    XML элемент `MIMEReport`.
  `text/*`
    Декодированный текст сообщения, в котором все символы конца строки заменены на символ Перевода Строки (0x0A).
  Обратите внимание: Когда получается сообщение, запрошенное по операции `folderRead`, тело MIME элемента включается только его его размер плюс размер частей, уже включённых в XML ответ, не превышает атрибута операции `totalSizeLimit`.

Пример:
From: <user1@example.com>
To: user2@example.com
MIME-Version: 1.0
Content-Type: multipart/alternative;boundary="abcd"
Content-Description: Test Message
--abcd
Content-Type: text/plain; charset="iso-8859-1";
format=flowed; paramX="valueX"
Content-Transfer-Encoding: quoted-printable
=46rom where I stay, I can see & hear a lot!
--abcd
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html><body bgcolor=3D"yellow">
<I>From where I stay</I>, I can see &amp; hear a lot!
</body></html>
--abcd--

<EMail>
<From>user1@example.com</From>
<To>user2@example.com</To>
<MIME Type="multipart" subtype="alternative" Description="Test Message">
<MIME type="text" subtype="plain" charset="iso-8859-1" type-paramX="valueX">
From where I stay, I can see &amp; hear a lot!
</MIME>
<MIME type="text" subtype="html" charset="iso-8859-1" type-paramX="valueX">
&lt;html&gt;&lt;body bgcolor=&quot;yellow&quot;&gt;
&lt;I&gt;From where I stay&lt;/I&gt;, I can see &amp;amp; hear a lot!
&lt;/body&gt;&lt;/html&gt;
</MIME>
</MIME>
</EMail>

### `MIMEReport`

Этот XML элемент представляет сообщение с отчётом, таким как Оповещение об Открытии (Disposition Notification) или Отчёт о Доставке.

Атрибуты:
  отсутствуют
Тело:
  набор XML элементов, в которых содержатся поля заголовка отчёта, такие как `Reporting-MTA`, `/Final-Recipient` и т.п.
  а также (опционально) элементы `MIMEReport` для тела отчёта.

Пример:
Subject: Delivery report: TEST - disposition and delivery
From: <MAILER-DAEMON@remote.example.com>
To: <sender@local.example.com>
Date: Wed, 02 May 2007 00:33:13 -0700
Message-ID: <receipt-39457791@remote.example.com>
X-MAPI-Message-Class: REPORT.IPM.Note.DR
MIME-Version: 1.0
Content-Type: multipart/report; report-type="delivery-status"; boundary="_===39457791====remote.example.com===_"
--_===39457791====remote.example.com===_
Content-Type: text/plain; charset="utf-8"
Message delivered to '<recepient@remote.example.com>'
LOCAL module(account recepient) reports:
Delivered to the user mailbox
--_===39457791====remote.example.com===_
Content-Type: message/delivery-status
Reporting-MTA: dns; remote.example.com
Original-Recipient: rfc822;<recepient@remote.example.com>
Final-Recipient: LOCAL;<recepient>
Action: delivered
Status: 2.0.0
--_===39457791====remote.example.com===_
Content-Type: text/rfc822-headers
From: "Sender Name" <sender@local.example.com>
Subject: TEST - disposition and delivery
To: recepient@remote.example.com
X-Mailer: CommuniGate Pro WebUser v5.1.9
Date: Wed, 02 May 2007 00:35:51 -0700
Message-ID: <web-3990004@local.example.com>
MIME-Version: 1.0
Disposition-Notification-To: <sender@local.example.com>
Content-Type: text/plain;charset="utf-8";format="flowed"
Content-Transfer-Encoding: 8bit
--_===39457791====remote.example.com===_--

<EMail>
<Subject>Delivery report: TEST - disposition and delivery</Subject>
<From>MAILER-DAEMON@stalker.com</From>
<To>sender@local.example.com</To>
<Date localTime="20070502T003313" timeShift="-25200">20070502T073313Z</Date>
<Message-ID>&lt;receipt-39457791@remote.example.com&gt;</Message-ID>
<X-MAPI-Message-Class>REPORT.IPM.Note.DR</X-MAPI-Message-Class>
<MIME estimatedSize="1433" subtype="report" type="multipart" Type-report-type="delivery-status">
<MIME charset="utf-8" estimatedSize="120" partID="01" subtype="plain" type="text">Message delivered to &#39;&lt;recepient@remote.example.com&gt;&#39;
LOCAL module(account recepient) reports:
Delivered to the user mailbox
</MIME>
<MIME estimatedSize="158" partID="02" subtype="delivery-status" type="message">
<MIMEReport>
<Reporting-MTA>dns; remote.example.com</Reporting-MTA>
<MIMEReport>
<Original-Recipient>rfc822;&lt;recepient@remote.example.com&gt;</Original-Recipient>
<Final-Recipient>LOCAL;&lt;recepient&gt;</Final-Recipient>
<Action>delivered</Action>
<Status>2.0.0</Status>
</MIMEReport>
</MIMEReport>
</MIME>
<MIME estimatedSize="787" partID="03" subtype="rfc822-headers" type="text">
<EMail>
<From realName="Sender Name">sender@local.example.com</From>
<Subject>TEST - disposition and delivery</Subject>
<To>recepient@remote.example.com</To>
<X-Mailer>CommuniGate Pro WebUser v5.1.9</X-Mailer>
<Date localTime="20070502T003551" timeShift="-25200">20070502T073551Z</Date>
<Message-ID>&lt;web-3990004@local.example.com&gt;</Message-ID>
<Disposition-Notification-To>sender@local.example.com</Disposition-Notification-To>
</EMail>
</MIME>
</MIME>
</EMail>

## HTTP Доступ

Некоторые клиенты могут не поддерживать выполнение через протокол XIMSS всех операций. При создании сессия XIMSS, её идентификатор направляется клиенту обратно с использованием сообщения данных `session`. Сервер обеспечивает доступ к этой сессии через HTTP протокол.

### Получение Части Сообщения

Для получения любой части сообщения, видимого в любом текущем открытом представлении Папки может использоваться следующий URL:

  `/Session/sessionID/MIME/folder/UID-partID-suffix`[`/filename`]

где

sessionID
  идентификатор текущей сессии XIMSS, отправленный с сообщением данных `session`.
folder
  имя целевого Представления папки или Календаря
UID
  UID целевого сообщения в целевом Представлении папки или в Календаре.
partID
  идентификатор затребованной MIME части сообщения. Это строка, сообщаемая XML элементом `MIME` при получении сообщения с использованием операции `folderRead`. Если должно быть получено всё сообщение, то строка partID и следующий за ней символ `-` должны быть опущены.
suffix
  режим получения:
  - `P.txt` - получается полностью недекодированная часть (включая заголовки и тело).
  - `H.txt` - получается часть с заголовками.
  - `B.extension` - получается тело декодированной части. Вы можете использовать любое подходящее расширение имени файла. HTTP ответ получает Content-Type полученной MIME части.
  - `R/cid` - строка cid должна быть URI-кодированной. Её декодированное значение указывает Content-ID MIME части. Сервер ищет все MIME части, "связанные" с текущей и получает тело той части, у которой совпадает Content-ID.
    Эта возможность используется для преобразования URL типа `cid:` в сообщения в формате HTML.
filename
  опциональное имя файла. Оно игнорируется сервером, но помогает браузеру пользователя сохранять файл под правильным именем.

Примеры:
C:GET /Session/1-2xklkdld8-djdkjk/MIME/INBOX/567-01-B.gif HTTP/1.1

C:GET /Session/1-2xklkdld8-djdkjk/MIME/INBOX/567-02-01-B.gif/Logo.gif HTTP/1.1

### Загрузка Файла на Сервер

Следующий URL может использоваться для загрузки файла на сервер в сессию "набора загруженных файлов".

  `/Session/sessionID/UPLOAD/uploadID`

где

sessionID
  идентификатор текущей сессии XIMSS, отправленный с сообщением данных `session`.
uploadID
  строка, идентифицирующая этот файл в "наборе загруженных файлов".

Тело запроса должно содержать оригинальный необработанный файл (в бинарном виде), как элемент тела с именем `fileData`.

Когда загружается на сервер и добавляется к "набору загруженных файлов", Сервер возвращает код ответа 200. Если операция загрузки закончилась неуспешно, Сервер возвращает код ответа 500.

Загруженный файл сохраняется вместе с его значением Content-Type.

Если "загруженный набор файлов" уже содержит файл с заданным значением `uploadID`, то старый файл удаляется.

### Скачивание Файла

Следующий URL может использоваться для скачивания файла с сервера из Хранилища Файлов Пользователя сессии.

  `/Session/sessionID/DOWNLOAD/fileName`

где

sessionID
  идентификатор текущей сессии XIMSS, отправленный с сообщением данных `session`.
fileName
  имя файла в сессии Хранилища Файлов Пользователя.
  Обратите внимание: для того, что бы загрузить файл из "набора загруженных файлов", указывайте fileName как `$UPLOAD$/uploadId`, где uploadId является идентификатором файла в "наборе загруженных файлов".

Руководство CommuniGate® Pro. Copyright © 1998-2009, Stalker Software, Inc.