Editing XMPP Core

{{stub}}
{{RealTitle|Основы XMPP}}

Основы протокола [[XMPP]] изложены в документе RFC 3920: "Extensible Messaging and Presence Protocol (XMPP): Core".

Этот документ описывает обощённую архитектуру, схему адресации, термины "XML поток" и "XML [[станс]]", правила использования [[XML]], требования к совместимым реализациям протокола, а также соображения по поводу интернациональности и безопасности.

== Обобщённая архитектура сети ==

=== Обзор ===
Хотя XMPP и не привязан к конкретной сетевой архитектуре, обычно он реализуется с архитектурой "клиент-сервер", где клиент соединяется с сервером по протоколу TCP, и соединения между серверами тоже производятся по протоколу TCP.

[[Image:Xmpp_core_network.PNG|Примерная структура сети]]

Примерная структура сети XMPP включает в себя [[Сервер|сервера]], к которым подключаются [[Клиент|клиенты]]. На схеме также показан транспорт в другую [[IM]] сеть. Синим цветом выделены соединения XMPP, черным - соединения сторонней сети.

=== Сервер ===
[[Сервер]] действует как уровень абстракции для соединений XMPP. Его основные обязанности:
* управлять соединениями(сессиями) других [[Сущность|сущностей]], в форме XML потоков от/для авторизованных клиентов, других серверов и прочих сущностей.
* маршрутизировать корректно адресованные XML [[Станс|стансы]] между указанными сущностями посредством XML потоков.

Большинство XMPP-совместимых серверов также выполняют обязанности по хранению данных клиентов (например, их [[Ростер|контакт-листов]] в случае базирующихся на XMPP [[IM]]-приложений). В этом случае данные XML обрабатываются самим сервером, и никуда не перенаправляются.

=== Клиент ===
Большинство клиентов подключаются напрямую к серверам через {{w|TCP}}-соединения, и используют XMPP для получения доступа к возможностям [[Сервер|сервера]] и связанных с ним [[Сервис|сервисов]]. Одновременно могут быть подключены несколько [[Ресурс|ресурсов]] (например, обозначающих устройства или местоположения) одного клиента. Каждый ресурс должен иметь уникальный идентификатор ресурса (см. [[XMPP Core#Схема адресации]]).

Рекомендуется для [[C2S|клиент-серверных соединений]] использовать порт 5222.

=== Транспорт ===
Транспорт - специальный сервис, работающий на стороне сервера, чья основная функция - обеспечивать перевод [[XMPP]] в протокол сторонней (не XMPP) [[IM]] сети и обратно. Примерами могут являться [[SMTP|e-mail]], [[IRC|Internet Relay Chat]], [[SIMPLE]], [[SMS]], а также коммерческие IM-сети, такие как [[AIM]], [[ICQ]], [[MSN]] и [[Yahoo! Messenger|Yahoo! IM]]. Коммуникации между транспортами и XMPP-серверами, а также между транспортами и сторонними серверами не описываются в этом документе.

=== Сеть ===
Поскольку каждый сервер идентифицируется его сетевым адресом, и поскольку [[S2S|сервер-серверные коммуникации]] являются прямым расширением [[C2S|клиент-серверного протокола]], фактически система состоит из набора взаимодействующих серверов. Таким образом, &lt;juliet@example.com&gt; может обмениваться сообщениями, информацией о присутствии и др. с &lt;romeo@example.net&gt;. Этот шаблорн знаком по протоколам вроде {{w|SMTP}}, которые пользуются стандартами сетевой адресации. Взаимодействие между серверами НЕОБЯЗАТЕЛЬНО. Если оно доступно, оно должно производиться посредством XML потоков через TCP соединения. Рекомендуемый порт для межсерверного взаимодействия 5269.

== Схема адресации ==

=== Обзор ===
Сущность - что-то, что может быть воспринято как конечная точка сети и может обмениваться данными по протоколу XMPP. 
Все сущности имеют уникальный адрес, соотвествующий RFC 2396. По историческим причинам, идентификатор называется Jabber Identifier или [[JID]].
Корректный JID состоит из идентификатора домена (domain), идентификатора узла(node) и идентификатора ресурса(resource).

Синтакс JID в форме Бэкуса-Наура:

      jid             = [ node "@" ] domain [ "/" resource ]
      domain          = fqdn / address-literal
      fqdn            = (sub-domain 1*("." sub-domain))
      sub-domain      = (internationalized domain label)
      address-literal = IPv4address / IPv6address

Все JID'ы строятся по указанной схеме. 
Наиболее частое её применение - идентификация пользователя IM, сервера, к которому пользователь подключен, и ресурса пользователя в форме <tt>user@server/resource</tt>.

Тем не менее, могут существовать узлы, не являющиеся пользователями. Например, конкретная конференция на [[MUC|сервере конференций]] может быть адресована как <tt>room@server</tt>, а её участник может быть адресован как <tt>room@server/nick</tt>.

Каждая допустимая часть JID'а по длине не должна превышать 1023 байта. Таким образом, полная длина JID с учетом символов "@" и "/" не может превышать 3071 байт.

== XML потоки ==

== Использование TLS ==

== Использование SASL ==

== Назначение ресурса ==

== Server Dialback ==

== XML стансы ==

== Правила обработки XML стансов на сервере ==

== Использование XML в протоколе XMPP ==

== Требования к совместимости с Основами ==

== Соображения по поводу интернациональности ==

== Соображения по поводу безопасности ==

== Соображения {{w|IANA}} ==

== Примечания ==

== Различия между Основами [[Jabber]] и [[XMPP]] ==

== Ссылки ==
* [http://tools.ietf.org/html/rfc3920 RFC 3920 на сайте ietf.org] (англ.)
@@ Line 5: / Line 5: @@
 Этот документ описывает обощённую архитектуру, схему адресации, термины "XML поток" и "XML [[станс]]", правила использования [[XML]], требования к совместимым реализациям протокола, а также соображения по поводу интернациональности и безопасности.
-== Введение ==
-Extensible Messaging and Presence Protocol (XMPP) &mdash; открытый, основанный на XML протокол для обмена в почти реальном времени сообщениями, передачи информации о пристуствии и сервисов вида "запрос-ответ".
-Базовый синтаксис и семантика были разработаны в сообществе Jabber, большей частью в 1999 году.
-В 2002, рабочая группа XMPP занялась разработкой адаптации протокола Jabber, которая была бы пригодна в качестве технологии IETF для обмена сообщениями и информацией о присутствии.
-Как результат этой работы, данный текст описывает основные возможности XMPP 1.0; расширения, необходимые для обмена сообщениями и информацией о присутствии, определенные в RFC 2779, определены в Extensible Messaging and Presence Protocol
-(XMPP): [[Instant Messaging and Presence|XMPP IM]].
 == Обобщённая архитектура сети ==
@@ Line 30: / Line 23: @@
 === Клиент ===
-Большинство клиентов подключаются напрямую к серверам через {{w|TCP}}-соединения, и используют XMPP для получения доступа к возможностям [[Сервер|сервера]] и связанных с ним [[Сервис|сервисов]]. Одновременно могут быть подключены несколько [[Ресурс|ресурсов]] (например, обозначающих устройства или местоположения) одного клиента. Каждый ресурс должен иметь уникальный идентификатор ресурса (см. [[XMPP Core#Схема адресации|Схема адресации]]).
+Большинство клиентов подключаются напрямую к серверам через {{w|TCP}}-соединения, и используют XMPP для получения доступа к возможностям [[Сервер|сервера]] и связанных с ним [[Сервис|сервисов]]. Одновременно могут быть подключены несколько [[Ресурс|ресурсов]] (например, обозначающих устройства или местоположения) одного клиента. Каждый ресурс должен иметь уникальный идентификатор ресурса (см. [[XMPP Core#Схема адресации]]).
 Рекомендуется для [[C2S|клиент-серверных соединений]] использовать порт 5222.
 === Транспорт ===
-Транспорт - специальный сервис, работающий на стороне сервера, чья основная функция - обеспечивать перевод [[XMPP]] в протокол сторонней (не XMPP) [[IM]] сети и обратно. Примерами могут являться [[Gateway:SMTP|e-mail]], [[Gateway:IRC|Internet Relay Chat]], [[SIMPLE]], [[Gateway:SMS|SMS]], а также коммерческие IM-сети, такие как [[Gateway:AIM|AIM]], [[Gateway:ICQ|ICQ]], [[Gateway:MSN|MSN]] и [[Gateway:Yahoo|Yahoo! IM]]. Коммуникации между транспортами и XMPP-серверами, а также между транспортами и сторонними серверами не описываются в этом документе.
+Транспорт - специальный сервис, работающий на стороне сервера, чья основная функция - обеспечивать перевод [[XMPP]] в протокол сторонней (не XMPP) [[IM]] сети и обратно. Примерами могут являться [[SMTP|e-mail]], [[IRC|Internet Relay Chat]], [[SIMPLE]], [[SMS]], а также коммерческие IM-сети, такие как [[AIM]], [[ICQ]], [[MSN]] и [[Yahoo! Messenger|Yahoo! IM]]. Коммуникации между транспортами и XMPP-серверами, а также между транспортами и сторонними серверами не описываются в этом документе.
 === Сеть ===
-Поскольку каждый сервер идентифицируется его сетевым адресом, и поскольку [[S2S|сервер-серверные коммуникации]] являются прямым расширением [[C2S|клиент-серверного протокола]], фактически система состоит из набора взаимодействующих серверов. Таким образом, &lt;juliet@example.com&gt; может обмениваться сообщениями, информацией о присутствии и др. с &lt;romeo@example.net&gt;. Этот шаблон знаком по протоколам вроде {{w|SMTP}}, которые пользуются стандартами сетевой адресации. Взаимодействие между серверами НЕОБЯЗАТЕЛЬНО. Если оно доступно, оно должно производиться посредством XML потоков через TCP соединения. Рекомендуемый порт для межсерверного взаимодействия 5269.
+Поскольку каждый сервер идентифицируется его сетевым адресом, и поскольку [[S2S|сервер-серверные коммуникации]] являются прямым расширением [[C2S|клиент-серверного протокола]], фактически система состоит из набора взаимодействующих серверов. Таким образом, &lt;juliet@example.com&gt; может обмениваться сообщениями, информацией о присутствии и др. с &lt;romeo@example.net&gt;. Этот шаблорн знаком по протоколам вроде {{w|SMTP}}, которые пользуются стандартами сетевой адресации. Взаимодействие между серверами НЕОБЯЗАТЕЛЬНО. Если оно доступно, оно должно производиться посредством XML потоков через TCP соединения. Рекомендуемый порт для межсерверного взаимодействия 5269.
 == Схема адресации ==
@@ Line 47: / Line 40: @@
 Корректный JID состоит из идентификатора домена (domain), идентификатора узла(node) и идентификатора ресурса(resource).
-Синтакс JID в [[w:Форма Бэкуса — Наура|форме Бэкуса—Наура]]:
+Синтакс JID в форме Бэкуса-Наура:
        jid             = [ node "@" ] domain [ "/" resource ]
@@ Line 62: / Line 55: @@
 Каждая допустимая часть JID'а по длине не должна превышать 1023 байта. Таким образом, полная длина JID с учетом символов "@" и "/" не может превышать 3071 байт.
-== XML-потоки ==
+== XML потоки ==
-=== Обзор ===
-Две фундаментальные концепции делают возможным быстрый асинхронный обмен сравнительно маленькими порциями структурированной информации между сущностями: [[XML-поток|XML-потоки]] и [[Станс|XML-стансы]].
-Эти термины определяются следующим образом:
-'''XML-поток''' - это контейнер для обмена XML-элементами между любыми двумя сущностями в сети.
-Начало XML-потока однозначно обозначается открывающим XML-тегом <tt>&lt;stream&gt;</tt> (с необходимыми атрибутами и указанием пространства имён), а конец XML-потока однозначно обозначается закрывающим тегом <tt>&lt;/stream&gt;</tt>.
-В течение жизни потока сущность, создавшая поток, может посылать неограниченное количество XML-элементов через поток, включая как элементы для создания потока (например, предложить использовать [[TLS]] (Секция 5) или [[SASL]] (Секция 6)), так и [[Станс|XML-стансы]] (элементы <tt>&lt;message/&gt;</tt>, <tt>&lt;presence/&gt;</tt> и <tt>&lt;iq/&gt;</tt>, с пространством имён по умолчанию).
-"Начальный поток" предлагается инициирующей сущностью (обычно клиентом или сервером) принимающей сущности (обычно серверу), и может рассматриваться как соответствующая инициатору потока "сессия".
-"Начальный поток" позволяет производить односторонюю передачу информации от инициатора к получателю; для передачи в обратном направлении принимающая сущность ДОЛЖНА предложить поток инициатору ("ответный поток").
-'''XML-станс''' - дискретная семантическая единица структурированной информации, переcылаемая от одной сущности к другой посредством XML-потока.
-XML-станс существует как непосредственный потомок корневого элемента <tt>&lt;stream/&gt;</tt>.
-{{todo|An XML stanza exists at the direct child level of the root <stream/> element and is said to be well-balanced if it matches the production [http://tools.ietf.org/html/rfc3920#ref-43 43] content of [http://tools.ietf.org/html/rfc3920#ref-XML XML].}}
-Начало любого XML-станса однозначно обозначается открывающим тегом на глубине 1 в XML-потоке (например, <tt>&lt;presence&gt;</tt>), и конец однозначно обозначается соответствующим закрывающим тегом на глубине 1 (например, <tt>&lt;/presence&gt;</tt>).
-XML-станс МОЖЕТ содержать дочерние элементы (с соответствующими атрибутами, дочерними элементами и символьными данными), если это необходимо для передачи желаемой информации.
-Единственные XML-стансы, определенные здесь - элементы <tt>&lt;message/&gt;</tt>, <tt>&lt;presence/&gt;</tt> и <tt>&lt;iq/&gt;</tt>, с пространством имён по умолчанию, как описано в Секции 9; XML элементы, необходимые для инициации [[TLS]] (Секция 5), [[SASL]] (Секция 6), или Server Dialback (Секция 8) не являются XML-стансами.
-В качестве примера рассмотрим сессию клиента с сервером.
-Для подключения к серверу клиент ДОЛЖЕН инициировать XML-поток, послав серверу открывающий тег <tt>&lt;stream&gt;</tt>, возможно, предварив его текстовым описанием версии XML и используемой кодировки (см. Изменения в текстовом описании (Секция 11.4) и Кодировка символов (Секция 11.5)).
-В зависимости от локальных правил и характеристик сервиса, серверу СЛЕДУЕТ ответить клиенту вторым XML-потоком, возможно, предварив его текстовым описанием.
-Как только клиент завершил приветствие SASL, он МОЖЕТ посылать неограниченное число XML-станс через поток любому получателю в сети.
-Когда клиент хочет закрыть поток, он просто посылает закрывающий тег <tt>&lt;/stream&gt;</tt> (в другом варианте, поток может быть закрыть сервером), после чего клиенту и серверу СЛЕДУЕТ также прервать нижележащее соединение (обычно TCP).
-Те, кто привык думать об XML как о документе, могут рассматривать сессию клиента с сервером как два незакрытых XML документа: один от клиента к серверу, и один от сервера к клиенту.
-С этой точки зрения, корневой элемент <tt>&lt;stream/&gt;</tt>, может рассматриваться как основная сущность для обоих "документов", и оба этих "документа" строятся за счет аккумулирования XML-станс, присланных по соответствующему потоку.
-Тем не менее, такая точка зрения - не более чем соглашение; XMPP имеет дело не с документами, а с потоками и стансами.
-В сущности, XML-поток действует как конверт для всех переданных XML-станс. Упрощенно его можно представить так:
-<pre>
-   |--------------------|
-   | <stream>           |
-   |--------------------|
-   | <presence>         |
-   |   <show/>          |
-   | </presence>        |
-   |--------------------|
-   | <message to='foo'> |
-   |   <body/>          |
-   | </message>         |
-   |--------------------|
-   | <iq to='bar'>      |
-   |   <query/>         |
-   | </iq>              |
-   |--------------------|
-   | ...                |
-   |--------------------|
-   | </stream>          |
-   |--------------------|
-</pre>
-=== Привязка к TCP ===
-Хотя нет необходимости передавать XML поток  через [TCP] соединение (например, две сущности могут подключаться друг к другу через другой механизм такой как [HTTP] туннелирование), данная спецификация определяет привязку XMPP только к TCP. В контексте клиент-серверного взаимодействия, сервер ДОЛЖЕН разрешать клиенту использование одного TCP соединения для отправки XML стансов от клиента к серверу и от сервера к клиенту. При взаимодействии сервер-сервер сервер ДОЛЖЕН использовать одно TCP соединение для стансов, посылаемых сервером пиру и другое TCP соединение (инициированное пиром) для стансов от пира к серверу, всего два TCP соединения.
-=== Безопасность потока ===
-=== Атрибуты потока ===
-==== Поддержка версий ====
-=== Указание пространства имён ===
-=== Возможности потока ===
-=== Ошибки потока ===
-==== Правила ====
-==== Синтаксис ====
-==== Предпоределенные условия ====
-==== Специфические условия приложения ====
-=== Упрощенные примеры потоков ===
 == Использование TLS ==
@@ Line 166: / Line 84: @@
 == Ссылки ==
-* [http://book.itep.ru/4/45/xmpp.htm Частичный перевод на русский]
 * [http://tools.ietf.org/html/rfc3920 RFC 3920 на сайте ietf.org] (англ.)