<!-- Session manager configuration -->
<!-- настройки: менеджер сессий пользователей XMPP-сервера -->
<!-- далее, "ядро XMPP-сервера", пишется как "ядро" -->
<sm>
<!-- Идентификатор модуля, с которым таковой подключается к ядру (default: sm) -->
<id>sm-jabber0.local</id>
<!-- Адрес PID-файла (в нём фиксируется ID процесса) -->
<pidfile>/var/jabberd/pid/sm-jabber0.local.pid</pidfile>
<!-- Настройки подключения к ядру -->
<router>
<ip>127.0.0.1</ip>
<port>5347</port>
<!-- Имя пользователя, от имени которого модуль подключается к ядру, и пароль для аутентификации -->
<user>jabberd</user>
<pass>strongPassword</pass>
<!-- Файл, содержащий SSL-сертификат и закрытый ключ, используемые для шифрования подключения модуля к ядру -->
<pemfile>/usr/local/etc/jabberd/server.pem</pemfile>
<!-- Настройки переподключения модуля к ядру -->
<retry>
<!-- Количество попыток инициирования подключения модуля к ядру (default: 3, без ограничений: -1) -->
<init>-1</init>
<!-- Количество попыток переподключения модуля к ядру в случае потери связи (default: 3, без ограничений: -1) -->
<lost>-1</lost>
<!-- Задержка (в секундах) между попытками подключения и переподключения (default: 2) -->
<sleep>2</sleep>
</retry>
</router>
<!-- Настройки журналирования (поддерживаемые типы: "syslog", "file" или "stdout") -->
<log type='file'>
<file>/var/jabberd/log/sm-jabber0.local.log</file>
</log>
<!-- Настройки сетевых подключений -->
<local>
<!-- Устанавливаем здесь доменное имя нашего XMPP-сервера, то самое, что указано после "собачки" в JID пользователей. Тем самым мы выделяем этот модуль управления сессиями для обслуживания именно этого доменного имени (или нескольких, если они ниже перечислены). Этот идентификатор должен представлять из себя полноценное доменное имя (FQDN) и "резольвится" на доступных DNS-серверах (если этот идентификатор не установлен, то вместо него будет использован идентификатор модуля менеджера сессий). -->
<id>jabber0.local</id>
<!--
<id>alias0.jabber0.local</id>
<id>alias1.jabber0.local</id>
-->
</local>
<!-- Настройки подсистемы доступа к данным окружения пользователей -->
<storage>
<!-- Путь к используемым библиотекам -->
<path>/usr/local/lib/jabberd</path>
<!-- Выбираем модуль доступа к базе данных окружения пользователей XMPP-сервера -->
<driver>mysql</driver>
<!-- Настройки подключения к MySQL, для доступа к окружению пользователей XMPP-сервера -->
<mysql>
<host>localhost</host>
<port>3306</port>
<dbname>jabberd2</dbname>
<user>jabberd2</user>
<pass>strongPassword</pass>
<transactions/>
</mysql>
</storage>
<!-- Настройки контроля доступа, используемые при маршрутизации трафика (Access control information) -->
<aci>
<!-- Перечисляем JID-ы, пользователи которых получат неограниченный доступ ко всему, что только поддерживается функционально, без каких либо ограничений (даже тех, что будут описаны далее) -->
<acl type='all'>
<jid>admin@jabber0.local</jid>
</acl>
</aci>
<!-- Настройки отображения информации о сервисе -->
<discovery>
<!-- Описываем здесь наш сервис, кратко идентифицируя его -->
<identity>
<category>server</category>
<type>im</type>
<name>XMPP (Jabber) IM server</name>
</identity>
<!-- Приводим дополнительную информацию о сервисе, приводя его в соответствие спецификации XEP-0157 -->
<serverinfo>
<admin-addresses>
<value>mailto:admin@jabber0.local</value>
<value>xmpp:admin@jabber0.local</value>
</admin-addresses>
<abuse-addresses>
<value>mailto:abuse@jabber0.local</value>
<value>xmpp:abuse@jabber0.local</value>
</abuse-addresses>
<feedback-addresses>
<value>http://site.jabber0.local/feedback</value>
</feedback-addresses>
<sales-addresses/>
<security-addresses/>
<support-addresses/>
</serverinfo>
</discovery>
<!-- User options -->
<user>
<!-- По умолчанию Jabberd2 без особого указания не создаёт полной структуры окружения пользователя, полагая, что она должна быть описана заранее. Таким образом, аутентифицировав подключающегося клиента, Jabberd2 не создаст полноценной сессии, указывая в журнале событий на отсутствие описания окружения (ростер, статусы и тому подобное). Честно говоря, я не понимаю "сермяжной сути" такого подхода разработчиков; рекомендую сразу раскомментировать эту строку, включающую автоматическое создание окружения пользователя, буде таковое ещё не создано -->
<auto-create/>
<!-- Настройки шаблонизатора. Задаём политику загрузки в "ростер" свежесозданным пользователям информации о контактах из файла-шаблона. -->
<template>
<publish>
<!-- Указываем перезаписывать заданные пользователем имена в его "ростере", полученными из шаблона, в том случае, если они дублируются -->
<override-names/>
</publish>
<!-- Путь к файлу-шаблону -->
<roster>/usr/local/etc/jabberd/templates/roster.xml</roster>
</template>
</user>
<!-- Настройки модуля отложенной доставки сообщений -->
<offline>
<!-- Задаём ограничение на количество сохраняемых для дальнейшей доставки сообщений -->
<userquota>500</userquota>
</offline>
<!--
Отдельная песня - описание настройки используемых менеджером сеансов модулей. Об этом не сейчас и не здесь. Обращаю внимание на то, что блок описания этого функционала я вынес после всех других, специально, чтобы не допустить смешения того, что корректируется и того, что - нет. Просто возьмите этот блок из поставляемого с дистрибутивом сервера Jabberd2 и вставьте его вместо того, что приведён здесь (блок ограничен тегами "<modules>" и "</modules>").
-->
<!--
Module chain configuration
Modules listed in a chain are called in the order specified at
the appropriate time for that chain (assuming that the module
knows how to work with that chain; otherwise it simply ignores
it).
Removing a module from these lists will stop the module being
called, even if its compiled into the server.
Serveral modules have a presence in more than one chain. It is
possible to remove a module from one chain but not others, but
this may cause strange behaviour. Make sure you know what you're
doing.
-->
<modules>
<path>/usr/local/lib/jabberd</path>
<!-- sess-start. The modules in this chain are called when a session
is first started (usually on request by c2s as part of the
authentication process). This is normally used to load
per-session data. -->
<chain id='sess-start'>
<module>status</module> <!-- record status information -->
</chain>
<!-- sess-end. The modules in this chain are called just before a
session is destroyed (after the client has disconnected). -->
<chain id='sess-end'>
<module>status</module> <!-- update status information -->
<module>iq-last</module> <!-- update logout time -->
</chain>
<!-- in-sess. The modules in this chain are called when a packet
arrives from an active user session. Note that this chain is
also responsible for delivering packets to their destinations -
this is usually handled by the "deliver" module. -->
<chain id='in-sess'>
<module>validate</module> <!-- validate packet type -->
<module>status</module> <!-- update status information -->
<module>privacy</module> <!-- manage privacy lists -->
<module>roster</module> <!-- handle roster get/sets and s10ns -->
<module>vacation</module> <!-- manage vacation settings -->
<!-- <module>pep</module> <!- - personal eventing -->
<module>iq-vcard</module> <!-- store and retrieve the user's vcard -->
<module>iq-ping</module> <!-- return the server ping -->
<module>iq-private</module> <!-- manage the user's private data store -->
<module>disco</module> <!-- respond to agents requests from sessions -->
<module>amp</module> <!-- advanced message processing -->
<module>offline</module> <!-- if we're coming online for the first time, deliver queued messages -->
<module>announce</module> <!-- deliver motd -->
<module>presence</module> <!-- process and distribute presence updates -->
<module>deliver</module> <!-- deliver packets with full jids directly -->
</chain>
<!-- out-sess. The modules in this chain are called just before a
packet is delivered to an active user session. -->
<chain id='out-sess'>
<!-- <module>pep</module> <!- - personal eventing -->
</chain>
<!-- in-router. The modules in this chain are called when a packet
arrives from the router (ie another component or s2s), but
before any processing is done. This is a good place to filter
incoming packets. -->
<chain id='in-router'>
<module>session</module> <!-- perform session actions as required by c2s -->
<module>validate</module> <!-- validate packet type -->
<module>presence</module> <!-- drop incoming presence if user not online -->
<module>privacy</module> <!-- filter incoming packets based on privacy rules -->
</chain>
<!-- out-router. The modules in this chain are called just before a
packet is delivered to the router (destined for another
component or s2s). This is a good place to filter outgoing
packets. -->
<chain id='out-router'>
<module>privacy</module> <!-- filter outgoing packets based on privacy rules -->
</chain>
<!-- pkt-sm. The modules in this chain are called when a packet
arrives that is addressed to the session manager itself (ie the
to JID has no node part). This is normally used to provide
session-manager-wide services (like service discovery). -->
<chain id='pkt-sm'>
<module>iq-last</module> <!-- return the server uptime -->
<module>iq-ping</module> <!-- return the server ping -->
<module>iq-time</module> <!-- return the current server time -->
<module>iq-version</module> <!-- return the server name and version -->
<module>amp</module> <!-- advanced message processing -->
<module>disco</module> <!-- build the disco list; respond to disco queries -->
<module>announce</module> <!-- send broadcast messages (announce, motd, etc) -->
<module>help</module> <!-- resend sm messages to administrators -->
<module>echo</module> <!-- echo messages sent to /echo -->
<module>status</module> <!-- track status information -->
<module>presence</module> <!-- proces server presence subscriptions -->
</chain>
<!-- pkt-user. The modules in this chain are called when a packet
arrives that is address to a specific user. Note that this
chain is also responsible for delivering packets to user
sessions as appropriate - this is usually handled by the
"deliver" module. -->
<chain id='pkt-user'>
<module>roster</module> <!-- handle s10n responses -->
<module>presence</module> <!-- process and distribute incoming presence from external entities -->
<module>iq-vcard</module> <!-- grab user vcards -->
<module>amp</module> <!-- advanced message processing -->
<module>deliver</module> <!-- deliver the packet to an active session if we can -->
<module>vacation</module> <!-- send vacation messages -->
<module>offline</module> <!-- save messages and s10ns for later -->
<module>iq-last</module> <!-- return time since last logout -->
</chain>
<!-- pkt-router. The modules in this chain are called when a
special-purpose packet arrives from the router (eg domain
advertisements). -->
<chain id='pkt-router'>
<module>session</module> <!-- take sessions offline if their c2s disappears -->
<module>disco</module> <!-- query new components for service information -->
</chain>
<!-- user-load. The modules in this chain are called to load
per-user data. This will happen before a user can be used (ie
before a session is created). -->
<chain id='user-load'>
<module>active</module> <!-- get active status -->
<module>roster</module> <!-- load the roster and trust list -->
<module>roster-publish</module> <!-- load the published roster -->
<module>privacy</module> <!-- load privacy lists -->
<module>vacation</module> <!-- load vacation settings -->
</chain>
<!-- user-unload. The modules in this chain are called right
after last per-user session is destroyed. -->
<chain id='user-unload'>
</chain>
<!-- user-create. The modules in this chain are called when a user
creation request is received (usually from c2s as part of a
registration request). This initialises any per-user data. -->
<chain id='user-create'>
<module>active</module> <!-- activate new users -->
<module>template-roster</module> <!-- populate roster from template -->
</chain>
<!-- user-delete. The modules in this chain are called when a user
deletion request is received (usually from c2s as part of a
registration removal request). This deletes all data that may
have been previously created for the user during normal
operation. -->
<chain id='user-delete'>
<module>active</module> <!-- deactivate users -->
<module>announce</module> <!-- delete motd data -->
<module>offline</module> <!-- bounce queued messages -->
<module>privacy</module> <!-- delete privacy lists -->
<module>roster</module> <!-- delete roster -->
<module>vacation</module> <!-- delete vacation settings -->
<module>status</module> <!-- delete status information -->
<module>iq-last</module> <!-- delete last logout time -->
<module>iq-private</module> <!-- delete private data -->
<module>iq-vcard</module> <!-- delete vcard -->
</chain>
<!-- disco-extend. The modules in this chain are called when a disco
info request is send to session manager. It implements XEP-0128
Service Discovery Extensions mechanizm to add additional
information to disco#info reply. -->
<chain id='disco-extend'>
<module>iq-version</module> <!-- add XEP-xxxx Software Information -->
<module>help</module> <!-- add XEP-0157 Contact Addresses -->
</chain>
</modules>
</sm>
<!-- настройки: менеджер сессий пользователей XMPP-сервера -->
<!-- далее, "ядро XMPP-сервера", пишется как "ядро" -->
<sm>
<!-- Идентификатор модуля, с которым таковой подключается к ядру (default: sm) -->
<id>sm-jabber0.local</id>
<!-- Адрес PID-файла (в нём фиксируется ID процесса) -->
<pidfile>/var/jabberd/pid/sm-jabber0.local.pid</pidfile>
<!-- Настройки подключения к ядру -->
<router>
<ip>127.0.0.1</ip>
<port>5347</port>
<!-- Имя пользователя, от имени которого модуль подключается к ядру, и пароль для аутентификации -->
<user>jabberd</user>
<pass>strongPassword</pass>
<!-- Файл, содержащий SSL-сертификат и закрытый ключ, используемые для шифрования подключения модуля к ядру -->
<pemfile>/usr/local/etc/jabberd/server.pem</pemfile>
<!-- Настройки переподключения модуля к ядру -->
<retry>
<!-- Количество попыток инициирования подключения модуля к ядру (default: 3, без ограничений: -1) -->
<init>-1</init>
<!-- Количество попыток переподключения модуля к ядру в случае потери связи (default: 3, без ограничений: -1) -->
<lost>-1</lost>
<!-- Задержка (в секундах) между попытками подключения и переподключения (default: 2) -->
<sleep>2</sleep>
</retry>
</router>
<!-- Настройки журналирования (поддерживаемые типы: "syslog", "file" или "stdout") -->
<log type='file'>
<file>/var/jabberd/log/sm-jabber0.local.log</file>
</log>
<!-- Настройки сетевых подключений -->
<local>
<!-- Устанавливаем здесь доменное имя нашего XMPP-сервера, то самое, что указано после "собачки" в JID пользователей. Тем самым мы выделяем этот модуль управления сессиями для обслуживания именно этого доменного имени (или нескольких, если они ниже перечислены). Этот идентификатор должен представлять из себя полноценное доменное имя (FQDN) и "резольвится" на доступных DNS-серверах (если этот идентификатор не установлен, то вместо него будет использован идентификатор модуля менеджера сессий). -->
<id>jabber0.local</id>
<!--
<id>alias0.jabber0.local</id>
<id>alias1.jabber0.local</id>
-->
</local>
<!-- Настройки подсистемы доступа к данным окружения пользователей -->
<storage>
<!-- Путь к используемым библиотекам -->
<path>/usr/local/lib/jabberd</path>
<!-- Выбираем модуль доступа к базе данных окружения пользователей XMPP-сервера -->
<driver>mysql</driver>
<!-- Настройки подключения к MySQL, для доступа к окружению пользователей XMPP-сервера -->
<mysql>
<host>localhost</host>
<port>3306</port>
<dbname>jabberd2</dbname>
<user>jabberd2</user>
<pass>strongPassword</pass>
<transactions/>
</mysql>
</storage>
<!-- Настройки контроля доступа, используемые при маршрутизации трафика (Access control information) -->
<aci>
<!-- Перечисляем JID-ы, пользователи которых получат неограниченный доступ ко всему, что только поддерживается функционально, без каких либо ограничений (даже тех, что будут описаны далее) -->
<acl type='all'>
<jid>admin@jabber0.local</jid>
</acl>
</aci>
<!-- Настройки отображения информации о сервисе -->
<discovery>
<!-- Описываем здесь наш сервис, кратко идентифицируя его -->
<identity>
<category>server</category>
<type>im</type>
<name>XMPP (Jabber) IM server</name>
</identity>
<!-- Приводим дополнительную информацию о сервисе, приводя его в соответствие спецификации XEP-0157 -->
<serverinfo>
<admin-addresses>
<value>mailto:admin@jabber0.local</value>
<value>xmpp:admin@jabber0.local</value>
</admin-addresses>
<abuse-addresses>
<value>mailto:abuse@jabber0.local</value>
<value>xmpp:abuse@jabber0.local</value>
</abuse-addresses>
<feedback-addresses>
<value>http://site.jabber0.local/feedback</value>
</feedback-addresses>
<sales-addresses/>
<security-addresses/>
<support-addresses/>
</serverinfo>
</discovery>
<!-- User options -->
<user>
<!-- По умолчанию Jabberd2 без особого указания не создаёт полной структуры окружения пользователя, полагая, что она должна быть описана заранее. Таким образом, аутентифицировав подключающегося клиента, Jabberd2 не создаст полноценной сессии, указывая в журнале событий на отсутствие описания окружения (ростер, статусы и тому подобное). Честно говоря, я не понимаю "сермяжной сути" такого подхода разработчиков; рекомендую сразу раскомментировать эту строку, включающую автоматическое создание окружения пользователя, буде таковое ещё не создано -->
<auto-create/>
<!-- Настройки шаблонизатора. Задаём политику загрузки в "ростер" свежесозданным пользователям информации о контактах из файла-шаблона. -->
<template>
<publish>
<!-- Указываем перезаписывать заданные пользователем имена в его "ростере", полученными из шаблона, в том случае, если они дублируются -->
<override-names/>
</publish>
<!-- Путь к файлу-шаблону -->
<roster>/usr/local/etc/jabberd/templates/roster.xml</roster>
</template>
</user>
<!-- Настройки модуля отложенной доставки сообщений -->
<offline>
<!-- Задаём ограничение на количество сохраняемых для дальнейшей доставки сообщений -->
<userquota>500</userquota>
</offline>
<!--
Отдельная песня - описание настройки используемых менеджером сеансов модулей. Об этом не сейчас и не здесь. Обращаю внимание на то, что блок описания этого функционала я вынес после всех других, специально, чтобы не допустить смешения того, что корректируется и того, что - нет. Просто возьмите этот блок из поставляемого с дистрибутивом сервера Jabberd2 и вставьте его вместо того, что приведён здесь (блок ограничен тегами "<modules>" и "</modules>").
-->
<!--
Module chain configuration
Modules listed in a chain are called in the order specified at
the appropriate time for that chain (assuming that the module
knows how to work with that chain; otherwise it simply ignores
it).
Removing a module from these lists will stop the module being
called, even if its compiled into the server.
Serveral modules have a presence in more than one chain. It is
possible to remove a module from one chain but not others, but
this may cause strange behaviour. Make sure you know what you're
doing.
-->
<modules>
<path>/usr/local/lib/jabberd</path>
<!-- sess-start. The modules in this chain are called when a session
is first started (usually on request by c2s as part of the
authentication process). This is normally used to load
per-session data. -->
<chain id='sess-start'>
<module>status</module> <!-- record status information -->
</chain>
<!-- sess-end. The modules in this chain are called just before a
session is destroyed (after the client has disconnected). -->
<chain id='sess-end'>
<module>status</module> <!-- update status information -->
<module>iq-last</module> <!-- update logout time -->
</chain>
<!-- in-sess. The modules in this chain are called when a packet
arrives from an active user session. Note that this chain is
also responsible for delivering packets to their destinations -
this is usually handled by the "deliver" module. -->
<chain id='in-sess'>
<module>validate</module> <!-- validate packet type -->
<module>status</module> <!-- update status information -->
<module>privacy</module> <!-- manage privacy lists -->
<module>roster</module> <!-- handle roster get/sets and s10ns -->
<module>vacation</module> <!-- manage vacation settings -->
<!-- <module>pep</module> <!- - personal eventing -->
<module>iq-vcard</module> <!-- store and retrieve the user's vcard -->
<module>iq-ping</module> <!-- return the server ping -->
<module>iq-private</module> <!-- manage the user's private data store -->
<module>disco</module> <!-- respond to agents requests from sessions -->
<module>amp</module> <!-- advanced message processing -->
<module>offline</module> <!-- if we're coming online for the first time, deliver queued messages -->
<module>announce</module> <!-- deliver motd -->
<module>presence</module> <!-- process and distribute presence updates -->
<module>deliver</module> <!-- deliver packets with full jids directly -->
</chain>
<!-- out-sess. The modules in this chain are called just before a
packet is delivered to an active user session. -->
<chain id='out-sess'>
<!-- <module>pep</module> <!- - personal eventing -->
</chain>
<!-- in-router. The modules in this chain are called when a packet
arrives from the router (ie another component or s2s), but
before any processing is done. This is a good place to filter
incoming packets. -->
<chain id='in-router'>
<module>session</module> <!-- perform session actions as required by c2s -->
<module>validate</module> <!-- validate packet type -->
<module>presence</module> <!-- drop incoming presence if user not online -->
<module>privacy</module> <!-- filter incoming packets based on privacy rules -->
</chain>
<!-- out-router. The modules in this chain are called just before a
packet is delivered to the router (destined for another
component or s2s). This is a good place to filter outgoing
packets. -->
<chain id='out-router'>
<module>privacy</module> <!-- filter outgoing packets based on privacy rules -->
</chain>
<!-- pkt-sm. The modules in this chain are called when a packet
arrives that is addressed to the session manager itself (ie the
to JID has no node part). This is normally used to provide
session-manager-wide services (like service discovery). -->
<chain id='pkt-sm'>
<module>iq-last</module> <!-- return the server uptime -->
<module>iq-ping</module> <!-- return the server ping -->
<module>iq-time</module> <!-- return the current server time -->
<module>iq-version</module> <!-- return the server name and version -->
<module>amp</module> <!-- advanced message processing -->
<module>disco</module> <!-- build the disco list; respond to disco queries -->
<module>announce</module> <!-- send broadcast messages (announce, motd, etc) -->
<module>help</module> <!-- resend sm messages to administrators -->
<module>echo</module> <!-- echo messages sent to /echo -->
<module>status</module> <!-- track status information -->
<module>presence</module> <!-- proces server presence subscriptions -->
</chain>
<!-- pkt-user. The modules in this chain are called when a packet
arrives that is address to a specific user. Note that this
chain is also responsible for delivering packets to user
sessions as appropriate - this is usually handled by the
"deliver" module. -->
<chain id='pkt-user'>
<module>roster</module> <!-- handle s10n responses -->
<module>presence</module> <!-- process and distribute incoming presence from external entities -->
<module>iq-vcard</module> <!-- grab user vcards -->
<module>amp</module> <!-- advanced message processing -->
<module>deliver</module> <!-- deliver the packet to an active session if we can -->
<module>vacation</module> <!-- send vacation messages -->
<module>offline</module> <!-- save messages and s10ns for later -->
<module>iq-last</module> <!-- return time since last logout -->
</chain>
<!-- pkt-router. The modules in this chain are called when a
special-purpose packet arrives from the router (eg domain
advertisements). -->
<chain id='pkt-router'>
<module>session</module> <!-- take sessions offline if their c2s disappears -->
<module>disco</module> <!-- query new components for service information -->
</chain>
<!-- user-load. The modules in this chain are called to load
per-user data. This will happen before a user can be used (ie
before a session is created). -->
<chain id='user-load'>
<module>active</module> <!-- get active status -->
<module>roster</module> <!-- load the roster and trust list -->
<module>roster-publish</module> <!-- load the published roster -->
<module>privacy</module> <!-- load privacy lists -->
<module>vacation</module> <!-- load vacation settings -->
</chain>
<!-- user-unload. The modules in this chain are called right
after last per-user session is destroyed. -->
<chain id='user-unload'>
</chain>
<!-- user-create. The modules in this chain are called when a user
creation request is received (usually from c2s as part of a
registration request). This initialises any per-user data. -->
<chain id='user-create'>
<module>active</module> <!-- activate new users -->
<module>template-roster</module> <!-- populate roster from template -->
</chain>
<!-- user-delete. The modules in this chain are called when a user
deletion request is received (usually from c2s as part of a
registration removal request). This deletes all data that may
have been previously created for the user during normal
operation. -->
<chain id='user-delete'>
<module>active</module> <!-- deactivate users -->
<module>announce</module> <!-- delete motd data -->
<module>offline</module> <!-- bounce queued messages -->
<module>privacy</module> <!-- delete privacy lists -->
<module>roster</module> <!-- delete roster -->
<module>vacation</module> <!-- delete vacation settings -->
<module>status</module> <!-- delete status information -->
<module>iq-last</module> <!-- delete last logout time -->
<module>iq-private</module> <!-- delete private data -->
<module>iq-vcard</module> <!-- delete vcard -->
</chain>
<!-- disco-extend. The modules in this chain are called when a disco
info request is send to session manager. It implements XEP-0128
Service Discovery Extensions mechanizm to add additional
information to disco#info reply. -->
<chain id='disco-extend'>
<module>iq-version</module> <!-- add XEP-xxxx Software Information -->
<module>help</module> <!-- add XEP-0157 Contact Addresses -->
</chain>
</modules>
</sm>