Network Working Group           J. Miller 
Internet-Draft                  P. Saint-Andre 
Expires: December 20, 2002      Jabber Software Foundation 
                                June 21, 2002 
 
Обмен сообщениями через XMPP (XMPP Instant Messaging)
draft-miller-xmpp-im-00


Статус этого документа
Этот документ является рабочим документом (Internet-Draft) и полностью соответствует всем требованиям главы 10 RFC2026.
Internet-Drafts - это рабочие документы Internet Engineering Task Force (IETF), их подразделений и групп разработчиков. Другие группы также могут распространять свои рабочие документы в виде Internet-Draft.
Internet-Drafts являются черновыми набросками и действительны максимум шесть месяцев, они могут быть обновлены, заменены или опровергнуты другими документами в любой момент. Не стоит рассматривать Internet-Drafts в качестве справочного пособия или ссылаться на них, иначе как на "рабочие документы".

Этот рабочий документ потеряет силу 20 декабря 2002г.


Авторские права
Copyright (C) The Internet Society (2002). All Rights Reserved.

Краткий обзор
Данный документ описывает специфичные расширения протокола XMPP (eXtensible Messaging and Presence Protocol),
необходимые при создании приложения для обмена сообщениями и определения доступности
абонента (точнее: приложения, совместимого со свободно распространяемой системой
обмена сообщениями Jabber (Jabber instant messaging system).

Оглавление

1. Введение
1.1 Общий обзор
1.2 Терминология
1.3 Требования
1.4 Соглашения, использующиеся в документе
1.5 Обсуждение документа
1.6 Замечания об интеллектуальной собственности
2. Регистрация
2.1 Поток данных при регистрации
2.2 Поток данных при отмене регистрации
2.3 Определение пространства имен jabber:iq:register 
2.3.1 Дочерние секции
2.3.2 DTD
2.3.3 Schema
3. Аутентификация
3.1 Аутентификация с использованием SASL
3.2 Аутентификация с использованием jabber:iq:auth
3.3 Определение пространства имен jabber:iq:auth
3.3.1 Дочерние секции
3.3.2 DTD
3.3.3 Schema
4. Обмен сообщениями
4.1 Указание получателя
4.2 Указание отправителя
4.3 Указание типа сообщения
4.4 Задание темы сообщения
4.5 Задание цепочки сообщений (thread)
4.6 Задание тела сообщения
4.7 Задание дополнительной информации
4.8 Ошибки при обмене сообщениями
5. Обмен информацией о доступности абонента
5.1 Ответственность узла и хоста
5.2 Объявление о доступности
5.3 Указание статуса доступности
5.4 Задание детализированной информации о статусе
5.5 Проверка доступности
5.6 Объявление о недоступности
6. Управление подпиской
6.1 Запрос на подписку
6.2 Обработка запроса на подписку
6.3 Прекращение подписки другого участника
6.4 Отписывание от информации о доступности абонента
7. Управление ростером
7.1 Получение ростера при входе в систему
7.2 Добавление объекта в ростер
7.3 Удаление объекта из ростера
7.4 Определение пространства имен jabber:iq:roster
7.4.1 Дочерние секции
7.4.2 DTD
7.4.3 Schema
8. Указания по маршритизации и доставке
9. Анализ безопасности
9.1 Надежная идентификация и шифрование
9.2 Соединения узла
* Справочная информация
* Связь с авторами
* Авторское право


1. Введение
1.1 Общий обзор
Базовые свойства протокола XMPP (XMPP Core[2]) предоставляют "строительные блоки"
для различных приложений, работающих в режиме "почти реального" времени. Этот
документ описывает специфичные расширения и применения базовых компонентов XMPP,
которые используются для реализации общей функциональности, ожидаемой от
системы обмена сообщениями и определения доступности абонента (главным образом,
в приложениях, совместимых со свободно распространяемой системой обмена сообщениями
Jabber). Большая часть этой функциональности обеспечивается использованием
расширений, задаваемых секциями со своими пространствами имен, помещаемых
в базовые секции, определенные в XMPP Core.


1.2 Терминология
Данный документ наследует терминологию, принятуюв XMPP Core[2].


1.3 Требования
В этом документе мы ставим задачу обеспечить узел следующей базовой
функциональностью для передачи сообщений и определения доступности абонента:
  Регистрация учетной записи на хосте
  Аутентификация хостом
  Обмен сообщениями с другими узлами
  Обмен информацией о доступности с другими узлами
  Управление подпиской на доступность другим узлам и от них
  Управление объектами в ростере (контакт-листе) узла


1.4 Соглашения, использующиеся в документе
Ключевые слова НЕОБХОДИМО (MUST), НЕДОПУСТИМО (MUST NOT), ТРЕБУЕТСЯ (REQUIRED),
СЛЕДУЕТ (SHOULD), НЕ СЛЕДУЕТ (SHOULD NOT), РЕКОМЕНДУЕТСЯ (RECOMMENDED),
МОЖЕТ (MAY), и НЕОБЯЗАТЕЛЬНО (OPTIONAL) в данном документе используются
в соответствии с описанным в  RFC2119[1].


1.5 Обсуждение документа
Авторы приглашают к обсуждению тем, представленных в этом документе, в список
рассылки jabber-ietf@jabber.org (архивы и информация о подписке доступна
на http://www.jabber.org/cgi-bin/mailman/listinfo/jabber-ietf/).


1.6 Замечания об интеллектуальной собственности
Данный документ полностью совместим со всеми положениями главы 10 RFC 2026. 
В этом изложении встречается термин "jabber" для идентификации схем URI, пространств
имен и другого синтаксиса протокола. Jabber[tm] является торговой маркой Jabber, Inc.
Если IETF примет этот документ (или его более новую редакцию) в качестве стандарта,
то Jabber, Inc предоставит разрешение на использование торговой марки "Jabber"
в соответствии с такой спецификацией.


2. Регистрация
Регистрация хостом необходима узлу для получения доступа к желаемой функциональности.
Разумеется, регистрация МОЖЕТ происходить вне контекста приложения для обмена
сообщениями и определения доступности (и, зачастую, так оно и происходит).
Однако, XMPP дает возможность узлу регистрироваться хостом и в контексте системы
обмена сообщениями. Эта функциональность обеспечивается посылкой и получением
блоков IQ в режиме запрос-ответ, где блоки IQ содержат секции <query/> в
пространстве имен jabber:iq:register.


2.1 Поток данных при регистрации

Шаг 1: Узел запрашивает хост о необходимой для регистрации информации:

<iq type="get" 
    to="capulet.com"
    id="reg_1">
  <query xmlns="jabber:iq:register"/>
</iq>
          
Шаг 2: Хост сообщает о полях, необходимых для регистрации:

<iq type="result" 
    from="capulet.com" 
    id="reg_1">
  <query xmlns="jabber:iq:register">
    <instructions>
      Choose a username and password to register with this service.
    </instructions>
    <email/>
    <password/>
    <username/>
  </query>
</iq>
          
Примечание: Узлу ТРЕБУЕТСЯ предоставить информацию для всех полей (исключая <instructions/>),
содержащихся в IQ ответе. (Блок XML, показанный выше, не содержит атрибута 'to',
поскольку запрашивающий еще не имеет учетной записи.)

Шаг 3: Узел предоставляет требующуюся информацию:

<iq type="set" 
    to="capulet.com" 
    id="reg_2">
  <query xmlns="jabber:iq:register">
    <email>juliet@capulet.com</email>
    <password>R0m30</password>
    <username>juliet</username>
  </query>
</iq>
          
Шаг 4: Хост информирует узел об успешной регистрации: 

<iq 
    type="result" 
    from="capulet.com" 
    id="reg_2"/>
            
Шаг 4 (альтернативный): Хост сообщает узлу о неудачной регистрации: 

<iq 
    type="error" 
    from="capulet.com" 
    id="reg_2"/>
  <error code="406">Not Acceptable</error>
</iq>


2.2 Поток данных при отмене регистрации
Пространство имен jabber:iq:register также позволяет пользователю отменить
регистрацию хостом посылкой секции <remove/>, как показано ниже.

Шаг 1: Узел посылает запрос на отмену регистрации: 

<iq type="set" 
    to="capulet.com" 
    id="unreg_1">
  <query xmlns="jabber:iq:register">
    <remove/>
  </query>
</iq>
          
Шаг 2: Хост информирует узел об успешной отмене регистрации: 

<iq 
    type="result" 
    from="capulet.com" 
    id="unreg_1"/>


2.3 Определение пространства имен jabber:iq:register 
2.3.1 Дочерние секции
Несмотря на то, что в в пространство имен jabber:iq:register можно поместить
множество различных полей, только следующие поля (исключая <instructions/>),
посланные хостом в IQ ответе, ТРЕБУЮТСЯ для регистрации. Официально
распознаваемые поля, доступные для использования:

  instructions 
  username 
  password 
  name 
  email 
  address 
  city 
  state 
  zip 
  phone 
  url 
  date 
  misc 
  text 
  remove - запрос на отмену регистрации (посылается только в IQ с type='set') 


2.3.2 DTD

<!ELEMENT query ((instructions? | username? | 
    password? | name? | email? | address? | 
    city? | state? | zip? | phone? | url? | 
    date? | misc? | text? | remove?)*)>

<!ELEMENT instructions (#PCDATA)>
<!ELEMENT username (#PCDATA)>
<!ELEMENT password (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT address (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT zip (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT misc (#PCDATA)>
<!ELEMENT text (#PCDATA)>
<!ELEMENT remove EMPTY>


2.3.3 Schema

<?xml version='1.0' encoding='UTF-8'?>
<xsd:schema
    xmlns:xsd='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://www.jabber.org/protocol'
    xmlns='http://www.jabber.org/protocol'
    elementFormDefault='qualified'>

  <xsd:element name='query'>
    <xsd:complexType>
      <xsd:choice minOccurs='0' maxOccurs='unbounded'>
        <xsd:element ref='instructions'/>
        <xsd:element ref='username'/>
        <xsd:element ref='password'/>
        <xsd:element ref='name'/>
        <xsd:element ref='email'/>
        <xsd:element ref='address'/>
        <xsd:element ref='city'/>
        <xsd:element ref='state'/>
        <xsd:element ref='zip'/>
        <xsd:element ref='phone'/>
        <xsd:element ref='url'/>
        <xsd:element ref='date'/>
        <xsd:element ref='misc'/>
        <xsd:element ref='text'/>
        <xsd:element ref='remove'/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name='instructions' type='xsd:string'/>
  <xsd:element name='username' type='xsd:string'/>
  <xsd:element name='password' type='xsd:string'/>
  <xsd:element name='name' type='xsd:string'/>
  <xsd:element name='email' type='xsd:string'/>
  <xsd:element name='address' type='xsd:string'/>
  <xsd:element name='city' type='xsd:string'/>
  <xsd:element name='state' type='xsd:string'/>
  <xsd:element name='zip' type='xsd:string'/>
  <xsd:element name='phone' type='xsd:string'/>
  <xsd:element name='url' type='xsd:string'/>
  <xsd:element name='date' type='xsd:string'/>
  <xsd:element name='misc' type='xsd:string'/>
  <xsd:element name='text' type='xsd:string'/>
  <xsd:element name='remove'/>

</xsd:schema>


3. Аутентификация
Для получения доступа к сети XMPP-совместимых приложений и, таким образом,
получения желаемой функциональности обмена сообщениями и определения доступности
абонента, узел должен быть аутентифицирован хостом. В качестве метода аутентификации
выделен SASL. Аутентификация, использующая старый метод jabber:iq:auth НЕОБЯЗАТЕЛЬНА,
но МОЖЕТ быть использована, если узел не поддерживает SASL.


3.1 Аутентификация с использованием SASL
Если узел поддерживает SASL, ему НЕОБХОДИМО использовать пространство имен SASL
в секции открытия <stream:stream/> при инициализации обмена с хостом.

За описанием протокола, как узел должен аутентифицироваться хостом, обращайтесь
к XMPP Core[2]. 

После аутентификации потока узла хостом, НЕОБХОДИМО предоставить ресурс, связанный
с этим соединением. Это достигается использованием пространства имен jabber:iq:auth.
Протокол для этого показан ниже.

Шаг 1: Узел запрашивает хост об информации, требуемой для начала сессии: 

<iq type="get" id="auth_1">
  <query xmlns="jabber:iq:auth">
    <username>juliet</username>
  </query>
</iq>
        
Шаг 2: Хост сообщает о необходимых полях (в данном случае, только имя пользователя
       и ресурс): 

<iq type="result" id="auth_1">
  <query xmlns="jabber:iq:auth">
    <username>juliet</username>
    <resource/>
  </query>
</iq>
        
Шаг 3: Узел посылает информацию о ресурсе: 

<iq type="set" id="auth_2">
  <query xmlns="jabber:iq:auth">
    <username>juliet</username>
    <resource>balcony</resource>
  </query>
</iq>
        
Шаг 4: Хост информирует узел об успешном начале сессии: 

<iq type="result" id="auth_2"/>


3.2 Аутентификация с использованием jabber:iq:auth
Ранние версии XMPP содержат клиент-серверный протокол аутентификации, который
применяется после установления потока. Этот протокол, использующий пространство
имен jabber:iq:auth, описывается в данной главе.

Пространство имен jabber:iq:auth служит двум целям: (1) простой способ
аутентификации узла хостом и (2) способ создания ресурса, представляющего конкретное
соединение (или сессию), ассоциированное с узлом.

Ниже показан поток данных, дающий полный пример аутентификации узла хостом.

Шаг 1: Узел запрашивает хост об информации, требуемой для аутентификации: 

<iq type="get" id="auth_1">
  <query xmlns="jabber:iq:auth">
    <username>juliet</username>
  </query>
</iq>
        
Шаг 2: Хост сообщает о необходимых для аутентификации полях:

<iq type="result" id="auth_1">
  <query xmlns="jabber:iq:auth">
    <username>juliet</username>
    <digest/>
    <resource/>
  </query>
</iq>
        
Шаг 3: Узел посылает аутентификационную информацию (зашифрованный пароль): 

<iq type="set" id="auth_2">
  <query xmlns="jabber:iq:auth">
    <username>juliet</username>
    <digest>64d60e40febe09264c52bc9cbddd5dd1147fae97</digest>
    <resource>balcony</resource>
  </query>
</iq>
        
Шаг 4: Хост информирует об успешной аутентификации: 

<iq type="result" id="auth_2"/>
        
Шаг 4 (альтернативный): Хост информирует о неудачной аутентификации: 

<iq 
    type="error" 
    from="capulet.com" 
    id="auth_2"/>
  <error code="401">Unauthorized</error>
</iq>


3.3 Определение пространства имен jabber:iq:auth
3.3.1 Дочерние секции
  username - уникальное имя пользователя для узла (обычно имя пользователя системы).
  password - секретный ключ или идентификационная фраза для доступа узла к хосту.
  digest - объединение id потока и пароля, зашифрованное в соответствии с
           SHA1 Secure Hash Algorithm[3] и представленное в виде шестнадцатиричного
           числа (буквы должны быть строчными)
  resource - уникальное значение для представления текущего соединения.


3.3.2 DTD

<!ELEMENT query ((username? | (password | digest)? | resource)*)>

<!ELEMENT username (#PCDATA)>
<!ELEMENT password (#PCDATA)>
<!ELEMENT digest (#PCDATA)>
<!ELEMENT resource (#PCDATA)>


3.3.3 Schema

<?xml version='1.0' encoding='UTF-8'?>
<xsd:schema
    xmlns:xsd='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://www.jabber.org/protocol'
    xmlns='http://www.jabber.org/protocol'
    elementFormDefault='qualified'>

  <xsd:element name='query'>
    <xsd:complexType>
      <xsd:choice minOccurs='0' maxOccurs='unbounded'>
        <xsd:element ref='username'/>
        <xsd:choice minOccurs='0' maxOccurs='1'>
          <xsd:element ref='password'/>
          <xsd:element ref='digest'/>
        </xsd:choice>
        <xsd:element ref='resource'/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name='username' type='xsd:string'/>
  <xsd:element name='password' type='xsd:string'/>
  <xsd:element name='digest' type='xsd:string'/>
  <xsd:element name='resource' type='xsd:string'/>

</xsd:schema>


4. Обмен сообщениями
Обмен сообщениями в XMPP очень прост: используя секцию данных <message/>, узел
может послать сообщение другому узлу (или, в общем случае, любому участнику).


4.1 Указание получателя
Узел МОЖЕТ указать получателя сообщения присвоением соответствующего JID атрибуту
'to' секции <message/>. Обычно, значение атрибута 'to' определяет участника,
отличного от посылающего (исключение см. в следующем параграфе). Желаемым
получателем МОЖЕТ быть любой разрешенный JID (например, узел на том же хосте,
узел на другом хосте, свой хост или другой хост).

Если адрес в 'to' не определен, то подразумевается, что сообщение адресовано
самому отправляющему узлу; кроме того, сообщение явно или неявно адресованное
отправляющему узлу, обрабатывается хостом от имени этого узла. Сообщение, адресованное
конкретному подключенному ресурсу, связанному с посылающим узлом, доставляется
этому node@host/resource (который МОЖЕТ отличаться от ресурса, создавшего это сообщение).


4.2 Указание отправителя
Узел МОЖЕТ указать адрес отправителя, включив атрибут 'from' в блок сообщения,
и МОЖЕТ указать любой ресурс или полный JID в этом атрибуте. Однако, хосту
НЕОБХОДИМО проверить, что данные атрибута 'from' соответствуют node@host/resource
подключенного ресурса, создавшего этот блок сообщения. Если атрибута 'from' нет,
хосту СЛЕДУЕТ добавить правильный и аутентифицированный адрес подключенного
ресурса, посылающего блок (т.е. node@host/resource).


4.3 Указание типа сообщения
Как указано в XMPP Core[2], имеется несколько предопределенных типов сообщений
(определяемых атрибутом 'type' в секции <message/>). В контексте приложения
для обмена сообщениями, узел МОЖЕТ задать тип для указания диалогового
контекста; давая, таким образом, подсказку относительно оформления (например,
в GUI). Если тип не задан, или установлен в значение, отличное от описанных здесь,
хосту СЛЕДУЕТ установить его значение в "normal".
Атрибут 'type' СЛЕДУЕТ устанавливать в одно из следующих значений:
  normal - Одиночное сообщение
  chat - Сообщение отправляется в контексте двустороннего общения (chat) между двумя участниками
  groupchat - Сообщение отправляется в контексте групповой конференции среди нескольких пользователей
  headline - Сообщение, содержащие один из элементов списка (например, аннонсы
             новостей, списки объявления)
  error - Сообщение, возвращаемое отправителю, и определяющее ошибку, ассоциированную
          с ранее отправленным узлом сообщением (за полным списком сообщений
          об ошибках, обратитесь к XMPP Core[2]).


4.4 Задание темы сообщения
Блок сообщения МОЖЕТ содержать дочернюю секцию, определяющую тему сообщения (subject).
Тема НЕ МОЖЕТ содержать дочерних секций.

Сообщение с темой:

<message to="romeo@montague.net" from="juliet@capulet.com/balcony">
  <subject>Imploring</subject>
  <body>Wherefore art thou, Romeo?</body>
</message>


4.5 Задание цепочки сообщений (thread)
Блок сообщения МОЖЕТ содержать дочернюю секцию, определяющую цепочку, к которой
принадлежит сообщение, в целях отслеживания цепочки беседы. Содержимое секции
<thread/> - это случайная строка, генерирумая отправителем; эта строка МОЖЕТ
быть возвращена отправителю в последующих ответах. Секции <thread/>, если она есть,
НЕДОПУСТИМО иметь атрибуты и она НЕ МОЖЕТ содержать дочерние секции.

Простой обмен сообщениями с цепочками:

<message 
    to="romeo@montague.net/orchard" 
    from="juliet@capulet.com/balcony" 
    type="chat">
  <body>Art thou not Romeo, and a Montague?</body>
  <thread>283461923759234</thread>
</message>

<message 
    to="juliet@capulet.com/balcony" 
    from="romeo@montague.net/orchard" 
    type="chat">
  <body>Neither, fair saint, if either thee dislike.</body>
  <thread>283461923759234</thread>
</message>

<message 
    to="romeo@montague.net/orchard" 
    from="juliet@capulet.com/balcony" 
    type="chat">
  <body>How cam'st thou hither, tell me, and wherefore?</body>
  <thread>283461923759234</thread>
</message>


4.6 Задание тела сообщения
Блок сообщения МОЖЕТ содержать (и обычно содержит) дочернюю секцию, определяющую
тело сообщения (body). Тело сообщения НЕ МОЖЕТ содержать дочерних секций. Если
требуется посылать сообщение в альтернативной форме (например, зашифрованное,
используя инфраструктуру с открытым ключом или использовать XHTML), то ему
СЛЕДУЕТ находиться в дочерней секции от <message/>, имеющей соответстующее
пространство имен, а не в секции <body/>.


4.7 Задание дополнительной информации
Секция <message/> МОЖЕТ содержать дочерние секции с данными, расширяющие значение
сообщения (например, зашифрованное тело сообщения). Обычно, это секция <x/>,
но это МОЖЕТ быть и другая секция. Дочерняя секция должна иметь объявление
пространства имен 'xmlns' (кроме определенных для потоков XML), определяющее
все секции, содержащиеся внутри дочерней.


4.8 Ошибки при обмене сообщениями
Если сообщение, посланное отправителем, не может быть доставлено, хосту СЛЕДУЕТ
возвратить его отправителю в сообщении с типом 'error' и соответствующим
сообщением об ошибке (за списком сообщений об ошибках, обратитесь к XMPP Core[2]).

Ошибка при обмене сообщениями:

<message 
    to="romeo@montague.net" 
    from="juliet@capulet.com">
  <body>Sleep dwell upon thine eyes</body>
</message>

<message
    to="juliet@capulet.com"
    from="romeo@montague.net"
    type="error">
  <body>Sleep dwell upon thine eyes</body>
  <error code="404">Not Found</error>
</message>

5. Обмен информацией о доступности абонента
Обмен информацией о доступности абонента достаточно прост в XMPP, используя
секцию данных <presence/>. Однако, существует отличие от обработки сообщений:
несмотря на то, что узел МОЖЕТ посылать информацию о доступности напрямую другому
участнику, обычно информация о доступности посылается узлом хосту, а затем
рассылается хостом всем участникам, подписанным на получение доступности данного
участника.


5.1 Ответственность узла и хоста
Когда узел соединяется с хостом, он посылает секцию <presence/> хосту для
объявления доступности по-умолчанию.

По получении доступности узла, хост посылает запросы о доступности всем участникам,
подписанным на получение информации о доступности этого узла (как указано в ростере
узла) для определения их доступности. (Удаленный хост отвечает на запрос о доступности
только когда: (1) проверяемый участник разрешает проверку своей доступности,
например, через правила на сервере или подписку пользователя, и (2) проверяемый
участник доступен; хост проверяемого участника информирует проверяющего о
доступности проверяемого, для всех ресурсов проверяемого участника.) 
Затем хост посылает объявление о доступности узла всем подписанным участникам,
которые доступны.

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

В заключение, хосту НЕОБХОДИМО оповещать всех подписанных и доступных участников,
когда подключенный ресурс становится недоступен.


5.2 Объявление о доступности
Будучи аутентифицированным, узлу СЛЕДУЕТ послать объявление о доступности своему
хосту, сообщая ему о доступности обмена с подключенным ресурсом.

Объявление о доступности, посылаемое узлом хосту:

<presence/>


5.3 Указание статуса доступности
Узел МОЖЕТ предоставлять дополнительную информацию о своем статусе доступности
используя секцию <show/>. Распознаваемые значения для этой секции - это
"away", "chat", "xa", и "dnd".

Статус доступности:

<presence>
  <show>away</show>
</presence>


5.4 Задание детализированной информации о статусе
Совместно с секцией <show/>, узел МОЖЕТ предоставлять детализированную
информацию, используя секцию <status/>. Содержимое этой секции - описание
на естественном языке текущего статуса доступности узла.

Детализированная информация о статусе:

<presence>
  <show>dnd</show>
  <status>Busy fighting the Romans</status>
</presence>


5.5 Проверка доступности
Узел или хост МОГУТ проверять текущую доступность другого участника. Узлу, для
проверки доступности другого узла НЕОБХОДИМО иметь на это разрешение.

Проверка доступности:

<presence type="probe" to="romeo@montague.net"/>


5.6 Объявление о недоступности
При завершении сессии с хостом узлу СЛЕДУЕТ отправить блок объявления
о недоступности с типом unavailable.

Объявление о недоступности:

<presence type="unavailable"/>


6. Управление подпиской
Для защиты конфиденциальности пользователей системы обмена сообщениями и других
участников, информация о доступности предоставляется только участникам, которым
пользователь это разрешил. Если пользователь разрешает другому участнику получение
информации о его доступности, то участнику разрешается подписка на получение таковой.
Примечание: подписка остается от сессии к сессии; она остается до тех пор, пока
подписчик не отпишется или объект подписки не отменит разрешенную ранее подписку.
Подписка осуществляется в XMPP посылкой блока доступности, содержащего специально
определенные атрибуты секции <presence/>.


6.1 Запрос на подписку
Запрос на подписку о доступности другого участника осуществляется посылкой
блока доступности с type="subscribe".

Посылка запроса на подписку:

<presence 
    to="juliet@capulet.com" 
    from="romeo@montague.net" 
    type="subscribe"/>


6.2 Обработка запроса на подписку
Когда узел получает запрос на подписку от другого участника, он МОЖЕТ принять
его, послав блок доступности с type="subscribed" или отклонить запрос посылкой
блока с type="unsubscribed".

Принятие запроса на подписку:

<presence 
    to="romeo@montague.net" 
    from="juliet@capulet.com" 
    type="subscribed"/>
        
Отклонение запроса на подписку: 

<presence 
    to="romeo@montague.net" 
    from="juliet@capulet.com" 
    type="unsubscribed"/>


6.3 Прекращение подписки другого участника
Если узел желает отменить разрешенную ранее подписку, он посылает блок доступности
с type="unsubscribed". 

Прекращение разрешенной ранее подписки:

<presence 
    to="romeo@montague.net" 
    from="juliet@capulet.com" 
    type="unsubscribed"/>


6.4 Отписывание от информации о доступности абонента
Если узел хочет отписаться от получения информации о доступности другого участника,
он посылает блок доступности с type="unsubscribe".

Отписывание от информации о доступности:

<presence 
    to="juliet@capulet.com" 
    from="romeo@montague.net" 
    type="unsubscribe"/>


7. Управление ростером
Список контактов пользователя называется "ростер" (roster). Ростер хранится
хостом; таким образом, пользователь может получать информацию из своего ростера
с любого подключенного ресурса.


7.1 Получение ростера при входе в систему
При соединении с хостом, узлу СЛЕДУЕТ запросить свой ростер (однако, получение
ростера может быть нежелательным, например, при низкой пропускающей способности
канала, запрос ростера узлом является НЕОБЯЗАТЕЛЬНЫМ).

Узел запрашивает ростер у хоста:

<iq id="roster_1" type="get">
  <query xmlns="jabber:iq:roster"/>
</iq>

Узел получает ростер с хоста:

<iq id="roster_1" type="result">
  <query xmlns="jabber:iq:roster>
    <item 
        jid="romeo@montague.net" 
        name="Romeo" 
        subscription="both"/>
    <item 
        jid="mercutio@montague.net" 
        name="Mercutio" 
        subscription="both">
      <group>Friends</group>
    </item> 
    <item 
        jid="benvolio@montague.net" 
        name="Benvolio" 
        subscription="both">
      <group>Friends</group>
    </item> 
  </query>
</iq>


7.2 Добавление объекта в ростер
В любое время узел МОЖЕТ добавить объект в свой ростер.

Узел добавляет новый объект:

<iq type="set" id="roster_2">
  <query xmlns="jabber:iq:roster">  
    <item 
        name="Nurse" 
        jid="nurse@capulet.com">
      <group>Servants</group>
    </item>
</iq>

Хост ответственнен за обновление информации ростера в постоянной памяти, а также
за отсылку этих изменений всем подключенным ресурсам узла, используя секцию iq
с type="set". Это позволяет всем подключенным ресурсам оставаться синхронизированными
с хранящейся на хосте информацией ростера.

Хост возвращает результирующую IQ пославшему ресурсу и отсылает измененную
информацию ростера всем подключенным ресурсам:

<iq type="result" id="roster_2"/>
<iq type="set" id="roster_3" to="juliet@capulet.com/balcony"/>
  <query xmlns="jabber:iq:roster">  
    <item 
        name="Nurse" 
        jid="nurse@capulet.com">
      <group>Servants</group>
    </item>
</iq>
<iq type="set" id="roster_3" to="juliet@capulet.com/chamber"/>
  <query xmlns="jabber:iq:roster">  
    <item 
        name="Nurse" 
        jid="nurse@capulet.com"
        subscription="none">
      <group>Servants</group>
    </item>
</iq>


7.3 Удаление объекта из ростера
В любое время узел МОЖЕТ удалить объект из своего ростера.

Узел удаляет объект:

<iq type="set" id="roster_2">
  <query xmlns="jabber:iq:roster">  
    <item 
        name="Nurse" 
        jid="nurse@capulet.com"
        subscription="remove">
      <group>Servants</group>
    </item>
</iq>

Замечание: как и при добавлении объекта в ростер, при удалении объекта хост
ответственнен за обновление информации ростера в постоянной памяти, а также
за отсылку этих изменений всем подключенным ресурсам узла, используя секцию iq
с type="set".


7.4 Определение пространства имен jabber:iq:roster
7.4.1 Дочерние секции
Секция <query/> в пространстве имен jabber:iq:roster МОЖЕТ содержать ноль или
более секций <item/>. Секция item МОЖЕТ включать следующие атрибуты:

  jid - ТРЕБУЕМЫЙ атрибут, содержащий полный JID контакта, который представлен
        данным объектом
  name - НЕОБЯЗАТЕЛЬНЫЙ атрибут, содержащий название контакта на естественном языке
  subscription - Текущий статус подписки, связанный с этим объектом. Должен
                 иметь одно из следующих значений (другие значения игнорируются):
    none - нет подписки.
    from - этот участник имеет подписку на контакт.
    to - контакт имеет подписку на этого участника.
    both - подписка to и from.
    remove - объект будет уделен.

  ask - НЕОБЯЗАТЕЛЬНЫЙ атрибут, определяющий текущий статус запроса этому контакту.
        Должен иметь одно из следующих значений (другие значения игнорируются):
    subscribe - участник запрашивает подписку на доступность контакта.
    unsubscribe - участник запрашивает отписку от доступности контакта.

Секция <item/> МОЖЕТ содержать ноль или более экземпляров следующей секции:
  group - Задаваемое пользователем название группы (для организации контактов
          в группы) на естественном языке.


7.4.2 DTD

<!ELEMENT query ((item)*)>

<!ELEMENT item ((group)*)>
<!ATTLIST item
    jid CDATA #REQUIRED
    name CDATA #IMPLIED
    subscription ( to | from | both | none | remove ) #IMPLIED
    ask ( subscribe | unsubscribe ) #IMPLIED
    >
<!ELEMENT group (#PCDATA)>


7.4.3 Schema

<?xml version='1.0' encoding='UTF-8'?>
<xsd:schema
    xmlns:xsd='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://www.jabber.org/protocol'
    xmlns='http://www.jabber.org/protocol'
    elementFormDefault='qualified'>

  <xsd:element name='query'>
    <xsd:complexType>
      <xsd:sequence minOccurs='0' maxOccurs='unbounded'>
        <xsd:element ref='item'/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name='item'>
    <xsd:complexType>
      <xsd:sequence minOccurs='0' maxOccurs='unbounded'>
        <xsd:element ref='group'/>
      </xsd:sequence>
      <xsd:attribute name='jid' type='xsd:string' use='required'/>
      <xsd:attribute name='name' type='xsd:string' use='optional'/>
      <xsd:attribute name='subscription' use='optional'>
        <xsd:simpleType>
          <xsd:restriction base='xsd:string'>
            <xsd:enumeration value='to'/>
            <xsd:enumeration value='from'/>
            <xsd:enumeration value='both'/>
            <xsd:enumeration value='none'/>
            <xsd:enumeration value='remove'/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:attribute>
      <xsd:attribute name='ask' use='optional'>
        <xsd:simpleType>
          <xsd:restriction base='xsd:string'>
            <xsd:enumeration value='subscribe'/>
            <xsd:enumeration value='unsubscribe'/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:attribute>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name='group' type='xsd:string'/>

</xsd:schema>


8. Указания по маршритизации и доставке
Блоки XML, не обрабатываемые напрямую хостом (например, для сохранения или
широковещательной рассылки), маршрутизируются или доставляются соответствующему
получателю блока, с указанным в атрибуте 'to' JID. Выполняются следующие правила:
  Если JID содержит идентификатор ресурса (to="node@host/resource"), то сначала
    производится попытка доставить блок ресурсу, полностью совпадающему с указанным,
    потом - ресурсу, частично совпадающему с указанным (например, ресурс "foo"
    частично совпадает с идентификатором ресурса "foobar").
  Если JID содержит идентификатор ресурса и подходящий ресурс не обнаружен, но
    есть другие ресурсы, связанные с этим узлом, то блок message обрабатывается
    так, как если бы ресурс указан не был (см. ниже). Для всех остальных блоков
    хост должен вернуть их отправителю с type="error" и соответствующим кодом
    ошибки (503) и сообщением.
  Если JID содержит только node@host и есть хотя бы один подключенный ресурс
    для этого узла, хост должен отправить блок соответствующему ресурсу,
    исходя из статуса доступности, приоритета и времени соединения подключенного
    ресурса(ов). (Существующие реализации XMPP содержат некоторые жесткие правила,
    основанные на <priority/> и последнем времени подключения, для маршрутизации
    таких блоков. Желательны более гибкие подходы для маршрутизации.)
  Если JID содержит только node@host и подключенных ресурсов для узла нет (например,
    пользователь offline), то хост МОЖЕТ сохранить блок (обычно только блоки
    сообщений и запросы на подписку) от имени узла и доставить его позже, когда
    появится доступный ресурс для этого узла.


9. Анализ безопасности
За общим анализом безопасности обращайтесь к соответствующей главе XMPP Core[2].


9.1 Надежная идентификация и шифрование
Узлы МОГУТ дополнительно поддерживать подписывание или шифрование сообщения и
информацию о доступности, используя инфраструктуру с открытым ключом (например,
PGP/GnuPG). Зашифрованные или подписанные данные посылаются в секции
<x/> в пространстве имен jabber:x:encrypted или jabber:x:signed. (Эти информационные
протоколы одобрены Jabber Software Foundation и не рассматриваются в этом документе.)

Реализации МОГУТ предлагать основанные на MIME средства проверки целостности
сообщения и обеспечения конфиденциальности, такие как OpenPGP[4] или S/MIME[5].


9.2 Соединения узла
НЕДОПУСТИМО предоставление хостом информации об IP адресе или методе доступа
узла кому-либо. И не должно требоваться никаких соединений, кроме обычного
соединения с хостом. Это защищает хост узла от прямых атак или
идентификации третьими сторонами.


* Справочная информация

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 
[2] Miller, J. and P. Saint-Andre, "XMPP Core (draft-miller-jabber-xmpp-core-00, work in progress)", June 2002. 
[3] World Wide Web Consortium, "Secure Hash Algorithm - Version 1.0", October 1997. 
[4] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. 
[5] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. 
[6] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol - Version 3.0", November 1996. 
[7] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. 
[8] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for Presence and Instant Messaging", RFC 2779, February 2000. 


* Связь с авторами

  Jeremie Miller 
  Jabber Software Foundation 
  1899 Wynkoop Street, Suite 600 
  Denver, CO 80202 
  US 
EMail:  jeremie@jabber.org 
URI:  http://www.jabber.org/ 
    
  Peter Saint-Andre 
  Jabber Software Foundation 
  1899 Wynkoop Street, Suite 600 
  Denver, CO 80202 
  US 
EMail:  stpeter@jabber.org 
URI:  http://www.jabber.org/ 


* Авторское право (без перевода)

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.