mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 07:08:51 -05:00
2800 lines
138 KiB
XML
2800 lines
138 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!-- TODO: Add sequence diagrams. -->
|
|
<!-- TODO: Add schema for <message> and <iq>. -->
|
|
<!-- TODO: Intermittent connections and reconnection to previous EXI session, reutilizing options, string tables, etc. -->
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Efficient XML Interchange (EXI) Format</title>
|
|
<abstract>This specification describes how EXI compression can be used in XMPP networks.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0322</number>
|
|
<status>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0001</spec>
|
|
<spec>XEP-0138</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>exi</shortname>
|
|
&peterwaher;
|
|
<author>
|
|
<firstname>Yusuke</firstname>
|
|
<surname>DOI</surname>
|
|
<email>yusuke.doi@toshiba.co.jp</email>
|
|
<jid>yusuke.doi@gmail.com</jid>
|
|
<uri>http://www.linkedin.com/in/yusukedoi</uri>
|
|
</author>
|
|
<revision>
|
|
<version>0.5.1</version>
|
|
<date>2016-11-02</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<p>Formatting and XML fixes.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.5</version>
|
|
<date>2015-11-09</date>
|
|
<initials>pw</initials>
|
|
<remark>
|
|
<p>Updated contact information.</p>
|
|
<p>Updated example JIDs to example.org</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.4</version>
|
|
<date>2014-03-10</date>
|
|
<initials>pw</initials>
|
|
<remark>
|
|
<p>XMPP Schema namespaces, byte sizes and hashes have been updated</p>
|
|
<p>A section with links for more information has been added.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.3</version>
|
|
<date>2013-07-19</date>
|
|
<initials>pw, yd</initials>
|
|
<remark>
|
|
<p>Added examples of communication in alternate bindings.</p>
|
|
<p>Default parameter, canonical namespace, and reserved schemaId of EXI encoding are revised.</p>
|
|
<p>Added clarifications on use of streamStart, streamEnd elements with namespace prefix mappings.</p>
|
|
<p>EXI options are now described in the context of use in XMPP communication.</p>
|
|
<p>A bug in setupResponse element type definition is fixed.</p>
|
|
<p>Changed domanname schemavault.se used in schema download examples to schemavault.example.org to clarify this is an example.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2013-06-27</date>
|
|
<initials>pw, yd</initials>
|
|
<remark>
|
|
<p>Added support for a binary binding.</p>
|
|
<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
|
|
<p>Added streamStart and streamEnd elements.</p>
|
|
<p>Added central XMPP schemas used for XMPP communication.</p>
|
|
<p>Added references to core XMPP schemas in examples.</p>
|
|
<p>
|
|
Added quick setup attributes: <strong>configurationId</strong>, <strong>configurationLocation</strong>.
|
|
</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2013-04-16</date>
|
|
<initials>psa</initials>
|
|
<remark>
|
|
<p>Initial published version approved by the XMPP Council.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.4</version>
|
|
<date>2013-03-19</date>
|
|
<initials>pw</initials>
|
|
<remark>
|
|
<p>Added support for uploading EXI-compressed schema files.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.3</version>
|
|
<date>2013-03-15</date>
|
|
<initials>pw</initials>
|
|
<remark>
|
|
<p>Added definition: EXI body.</p>
|
|
<p>Added note regarding preserverance of namespace prefixes.</p>
|
|
<p>Corrected the language.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.2</version>
|
|
<date>2013-03-13</date>
|
|
<initials>pw</initials>
|
|
<remark>
|
|
<p>Added support for session-wide buffers and string tables.</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2013-03-12</date>
|
|
<initials>pw</initials>
|
|
<remark>
|
|
<p>First draft.</p>
|
|
</remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
The Efficient XML Interchange (EXI) Format <note>
|
|
Efficient XML Interchange (EXI) Format <<link url='http://www.w3.org/TR/exi/'>http://www.w3.org/TR/exi/</link>>.
|
|
</note> is an
|
|
efficient way to compress XML documents and XML fragments. This document provides information on how EXI can be used in XMPP streams to efficiently compress data transmitted between
|
|
the server and the client. For certain applications (like applications in sensor networks) EXI is a vital component, decreasing packet size enabling sensors with limited memory to
|
|
communicate efficiently. The strong support in EXI for generating efficient stubcodes is also vital to build efficient code in constrained devices.
|
|
</p>
|
|
<p>
|
|
Activating EXI compression requires a handshake to take place prior, where the server and client agree on a set of parameters. Some of these parameters may increase the compression ratio,
|
|
at the cost of processing power and readability. These parameters include:
|
|
</p>
|
|
<ul>
|
|
<li>Schemas to use.</li>
|
|
<li>EXI version number.</li>
|
|
<li>Data alignment (bit-packed, byte-alignment, pre-compression).</li>
|
|
<li>If EXI-compressed data should be further compressed using additional compression.</li>
|
|
<li>Strict or loose adherence to schemas.</li>
|
|
<li>If comments, processing instructions, dtd:s, prefixes, lexical values, etc. should be preserved.</li>
|
|
<li>If self-contained elements should be allowed.</li>
|
|
<li>Alternate data type representations for types values.</li>
|
|
<li>Block size for EXI compression.</li>
|
|
<li>Maximum string length of value content items in string tables.</li>
|
|
<li>Value partition capacity.</li>
|
|
</ul>
|
|
<p>
|
|
These parameters will be discussed in greater depth in the following sections. There are also default values that can be used to commence evaluating EXI compression.
|
|
</p>
|
|
<p>
|
|
The single most important property to agree on however, is the set of schemas to use during EXI compression. EXI compresses XML much more efficiently if schemas exist
|
|
describing the format of the expected XML. Since the server is not supposed to know all possible XML schemas, a mechanism is provided in this document whereby schemas can be
|
|
interchanged, so that the server can adapt its compression to the needs of the client.
|
|
</p>
|
|
<p>
|
|
EXI can be used through two bindings:
|
|
</p>
|
|
<ul>
|
|
<li>Normal XMPP Port</li>
|
|
<li>Dedicated Binary EXI Port</li>
|
|
</ul>
|
|
<p>
|
|
Both will be described in turn, in the following sections.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<!-- TODO: [YD] can we have a summary section to desribe the use case? a short proposal is as follows
|
|
The section title of "Detecting support of EXI" is also modified to aligned with overall structure
|
|
-->
|
|
<section2 topic="Two approaches to use EXI">
|
|
<p>
|
|
There are two ways to use EXI to make efficient XMPP communication. The first method describes how to activate EXI-compression using &xep0138; (XEP-0138).
|
|
The second method describes an alternative binding. This method does not use Stream compression as defined in
|
|
<link url="http://xmpp.org/extensions/xep-0138.html">XEP-0138</link>, rather it allows clients to connect
|
|
to the server and start using EXI directly from the beginning.
|
|
</p>
|
|
</section2>
|
|
<section2 topic="Stream Compression" anchor="streamcompression">
|
|
<p>
|
|
The following sections assume the client connects through the normal XMPP port, and starts communicating with the server using uncompressed XML fragments.
|
|
When the client connects to the XMPP Server, it will receive a list of features supported by the server:
|
|
</p>
|
|
<example caption='Search Features'><![CDATA[
|
|
<stream:features>
|
|
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
|
|
<compression xmlns='http://jabber.org/features/compress'>
|
|
<method>zlib</method>
|
|
<method>lzw</method>
|
|
<method>exi</method>
|
|
<method>exi:54321</method>
|
|
</compression>
|
|
</stream:features>]]></example>
|
|
<p>
|
|
Support for EXI compression through the normal XMPP port is detected by the existence of the <strong>exi</strong> compression method in the <strong>features</strong> stanza.
|
|
If a port (static or dynamic) is available for a dedicated binary EXI/XMPP binding, this can be detected by the existence of the <strong>exi:PORT</strong> compression method,
|
|
where PORT is replaced by the port number used. More information about this alternative method is available in the <link url='#alttrans'>Alternative Bindings</link> section.
|
|
</p>
|
|
<p>
|
|
<strong>Note:</strong> If the client already knows the port number of the dedicated binary EXI/XMPP binding, it can connect there directly, without the need to check the
|
|
server features using the normal XMPP port.
|
|
</p>
|
|
<p>
|
|
Following is a list of use cases displaying how the client can configure and activate EXI compression on the current binding.
|
|
</p>
|
|
<section3 topic='Invalid setup'>
|
|
<p>
|
|
If the client attempts to activate an EXI stream at this point, before the negotiation of EXI properties has been performed, the server must respond with a
|
|
<strong>setup-failed</strong> response.
|
|
</p>
|
|
<example caption='Invalid setup'><![CDATA[
|
|
<compress xmlns='http://jabber.org/protocol/compress'>
|
|
<method>exi</method>
|
|
</compress>
|
|
|
|
<failure xmlns='http://jabber.org/protocol/compress'>
|
|
<setup-failed/>
|
|
</failure>]]></example>
|
|
</section3>
|
|
<section3 topic='Proposing compression parameters' anchor='setup'>
|
|
<p>
|
|
When the client decides to activate EXI compression, it sends a <strong>setup</strong> stanza containing parameter proposals to the server as follows:
|
|
</p>
|
|
<example caption='Proposing compression parameters'><![CDATA[
|
|
<setup xmlns='http://jabber.org/protocol/compress/exi' version='1' strict='true' blockSize='1024'
|
|
valueMaxLength='32' valuePartitionCapacity='100'>
|
|
<schema ns='http://www.w3.org/XML/1998/namespace' bytes='4726' md5Hash='2e2cf9072dc058dcda41b7ee77a5cb54'/>
|
|
<schema ns='http://etherx.jabber.org/streams' bytes='3450' md5Hash='68719b98725477c46a70958d1ea7c781'/>
|
|
<schema ns='jabber:client' bytes='6968' md5Hash='5e2d5cbf0506e3f16336d295093d66c4'/>
|
|
<schema ns='jabber:server' bytes='6948' md5Hash='dd95bd3055dfdd69984ed427cd6356e0'/>
|
|
<schema ns='jabber:x:roster' bytes='1077' md5Hash='00cb233dee83919067559c5dcee04f3d'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-sasl' bytes='2769' md5Hash='fd9a83f5c75628486ce18c0eb3a35995'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-streams' bytes='3315' md5Hash='75cd95aecb9f1fd66110c3ddcf00c9b8'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-tls' bytes='688' md5Hash='dc18bc4da35bc1be7a6c52aa43330825'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-stanzas' bytes='3133' md5Hash='1a8d21588424f9134dc497de64b10c3f'/>
|
|
<schema ns='http://jabber.org/protocol/compress/exi' bytes='15094' md5Hash='8b8f91b95d9101f0781e0ba9b4e106be'/>
|
|
<schema ns='urn:xmpp:iot:control' bytes='6293' md5Hash='74dcea52300e8c8df8c4de2c9e90495b'/>
|
|
<schema ns='urn:xmpp:iot:sensordata' bytes='8092' md5Hash='49b101e7deea39ccc31340a3c7871c43'/>
|
|
<schema ns='urn:xmpp:iot:interoperability' bytes='1275' md5Hash='5d39845a0082715ff8807691698353bb'/>
|
|
<schema ns='urn:xmpp:iot:provisioning' bytes='6303' md5Hash='3ed5360bc17eadb2a8949498c9af3f0c'/>
|
|
</setup>]]></example>
|
|
<p>
|
|
<strong>Note:</strong> Schema files are identified using three properties: Its <strong>target namespace</strong>, its <strong>byte size</strong> and its
|
|
<strong>MD5 hash</strong>. The <strong>MD5 hash</strong> provides a way to detect small changes in the file, even if the byte size and namespace are the same.
|
|
</p>
|
|
<p>
|
|
It is important that the client specify not only application specific namespaces in this request, but also the versions of the schemas for the
|
|
core XMPP protocol namespaces and the schema for the XML namespace, containing XML attributes.
|
|
</p>
|
|
<p>
|
|
<strong>Note:</strong> Hash values and byte sizes of known schemas at the time of writing, can be found <link url='#knownhashes'>here</link>.
|
|
However, these values are informational only. It is recommended that the developer makes sure exactly what version of the schema to use, and
|
|
calculate the hash for it correspondingly. Also, some changes to some schemas might be necessary, which will affect the hash values. For more
|
|
information about this, see the inforamtion about <link url='#knownproblems'>known problems</link>.
|
|
</p>
|
|
<p>
|
|
After receiving the request, the server responds with a <strong>setupResponse</strong> stanza containing the parameters it can accept, based
|
|
on the initial values provided by the client. Any buffer sizes, etc., may have been changed, but only lowered, never raised.
|
|
</p>
|
|
<example caption='Unable to accommodate parameters'><![CDATA[
|
|
<setupResponse xmlns='http://jabber.org/protocol/compress/exi' version='1' strict='true'
|
|
blockSize='1024' valueMaxLength='32' valuePartitionCapacity='100'>
|
|
<schema ns='http://www.w3.org/XML/1998/namespace' bytes='4726' md5Hash='2e2cf9072dc058dcda41b7ee77a5cb54'/>
|
|
<schema ns='http://etherx.jabber.org/streams' bytes='3450' md5Hash='68719b98725477c46a70958d1ea7c781'/>
|
|
<schema ns='jabber:client' bytes='6968' md5Hash='5e2d5cbf0506e3f16336d295093d66c4'/>
|
|
<schema ns='jabber:server' bytes='6948' md5Hash='dd95bd3055dfdd69984ed427cd6356e0'/>
|
|
<schema ns='jabber:x:roster' bytes='1077' md5Hash='00cb233dee83919067559c5dcee04f3d'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-sasl' bytes='2769' md5Hash='fd9a83f5c75628486ce18c0eb3a35995'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-streams' bytes='3315' md5Hash='75cd95aecb9f1fd66110c3ddcf00c9b8'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-tls' bytes='688' md5Hash='dc18bc4da35bc1be7a6c52aa43330825'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-stanzas' bytes='3133' md5Hash='1a8d21588424f9134dc497de64b10c3f'/>
|
|
<schema ns='http://jabber.org/protocol/compress/exi' bytes='15094' md5Hash='8b8f91b95d9101f0781e0ba9b4e106be'/>
|
|
<schema ns='urn:xmpp:iot:control' bytes='6293' md5Hash='74dcea52300e8c8df8c4de2c9e90495b'/>
|
|
<schema ns='urn:xmpp:iot:sensordata' bytes='8092' md5Hash='49b101e7deea39ccc31340a3c7871c43'/>
|
|
<schema ns='urn:xmpp:iot:interoperability' bytes='1275' md5Hash='5d39845a0082715ff8807691698353bb'/>
|
|
<missingSchema ns='urn:xmpp:iot:provisioning' bytes='6303' md5Hash='3ed5360bc17eadb2a8949498c9af3f0c'/>
|
|
</setupResponse>]]></example>
|
|
<p>
|
|
Schema files that the server does not have (based on namespace, byte size and MD5 hash) are marked with the <strong>missingSchema</strong> element instead of the
|
|
normal <strong>schema</strong> element.
|
|
</p>
|
|
<p>
|
|
At this point the client can choose to abort the EXI enablement sequence if it cannot accommodate itself with the proposed parameter settings provided by the server.
|
|
The XMPP session will continue to work in its current state. Aborting does not require taking further action from the client.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Uploading new schema files'>
|
|
<p>
|
|
If the server lacks information about a schema file, it is specified in the response through the <strong>missingSchema</strong> elements. At this point, the client can
|
|
either choose to accept that these schema files are not available, making compression less efficient, or choose to upload the missing schema files to the server. Of course,
|
|
uploading schema files would require the device to have sufficient buffers and memory to store and upload the schema files in the first place. (If it is not possible to upload the
|
|
schema files, consideration should be given to installing the schema files manually at the server.)
|
|
</p>
|
|
<p>
|
|
To upload a schema file, the client simply sends the schema file using an <strong>uploadSchema</strong> element, as follows:
|
|
</p>
|
|
<example caption='Uploading schema file'><![CDATA[
|
|
<uploadSchema xmlns='http://jabber.org/protocol/compress/exi' contentType='Text'>
|
|
PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4NCjx4czpzY2hlbWENCiAgICB4
|
|
bWxuczp4cz0naHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEnDQogICAgdGFyZ2V0TmFt
|
|
ZXNwYWNlPSd1cm46eG1wcDpzbjpwcm92aXNpb25pbmcnDQogICAgeG1sbnM9J3Vybjp4bXBwOnNu
|
|
|
|
…
|
|
|
|
dmlsZWdlJz4NCgkJPHhzOmF0dHJpYnV0ZSBuYW1lPSdpZCcgdHlwZT0nUHJpdmlsZWdlSWQnIHVz
|
|
ZT0ncmVxdWlyZWQnLz4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KIA0KPC94czpzY2hlbWE+DQo=
|
|
</uploadSchema>]]></example>
|
|
<p>
|
|
The schema itself is sent using base64 encoding to the server. This is to make sure a binary exact copy is transferred, maintaining encoding, processing instructions, etc. The
|
|
server then computes the <strong>target namespace</strong>, <strong>byte size</strong> and <strong>MD5 Hash</strong> from the sent schema file.
|
|
</p>
|
|
<p>
|
|
If the client desires, it can test the EXI setup again. This is optional, but can be used to test that uploading the schema files, and any new property values
|
|
are accepted by the server.
|
|
</p>
|
|
<example caption='Testing newly uploaded schema files'><![CDATA[
|
|
<setup xmlns='http://jabber.org/protocol/compress/exi' version='1' strict='true' blockSize='1024'
|
|
valueMaxLength='32' valuePartitionCapacity='100'>
|
|
<schema ns='http://www.w3.org/XML/1998/namespace' bytes='4726' md5Hash='2e2cf9072dc058dcda41b7ee77a5cb54'/>
|
|
<schema ns='http://etherx.jabber.org/streams' bytes='3450' md5Hash='68719b98725477c46a70958d1ea7c781'/>
|
|
<schema ns='jabber:client' bytes='6968' md5Hash='5e2d5cbf0506e3f16336d295093d66c4'/>
|
|
<schema ns='jabber:server' bytes='6948' md5Hash='dd95bd3055dfdd69984ed427cd6356e0'/>
|
|
<schema ns='jabber:x:roster' bytes='1077' md5Hash='00cb233dee83919067559c5dcee04f3d'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-sasl' bytes='2769' md5Hash='fd9a83f5c75628486ce18c0eb3a35995'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-streams' bytes='3315' md5Hash='75cd95aecb9f1fd66110c3ddcf00c9b8'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-tls' bytes='688' md5Hash='dc18bc4da35bc1be7a6c52aa43330825'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-stanzas' bytes='3133' md5Hash='1a8d21588424f9134dc497de64b10c3f'/>
|
|
<schema ns='http://jabber.org/protocol/compress/exi' bytes='15094' md5Hash='8b8f91b95d9101f0781e0ba9b4e106be'/>
|
|
<schema ns='urn:xmpp:iot:control' bytes='6293' md5Hash='74dcea52300e8c8df8c4de2c9e90495b'/>
|
|
<schema ns='urn:xmpp:iot:sensordata' bytes='8092' md5Hash='49b101e7deea39ccc31340a3c7871c43'/>
|
|
<schema ns='urn:xmpp:iot:interoperability' bytes='1275' md5Hash='5d39845a0082715ff8807691698353bb'/>
|
|
<schema ns='urn:xmpp:iot:provisioning' bytes='6303' md5Hash='3ed5360bc17eadb2a8949498c9af3f0c'/>
|
|
</setup>]]></example>
|
|
<p>
|
|
And the server should then respond:
|
|
</p>
|
|
<example caption='Agreement between client and server'><![CDATA[
|
|
<setupResponse xmlns='http://jabber.org/protocol/compress/exi' version='1' strict='true'
|
|
blockSize='1024' valueMaxLength='32' valuePartitionCapacity='100' agreement='true'
|
|
configurationId='c76ab4ec-4993-4285-8c7a-098060581bb8'>
|
|
<schema ns='http://www.w3.org/XML/1998/namespace' bytes='4726' md5Hash='2e2cf9072dc058dcda41b7ee77a5cb54'/>
|
|
<schema ns='http://etherx.jabber.org/streams' bytes='3450' md5Hash='68719b98725477c46a70958d1ea7c781'/>
|
|
<schema ns='jabber:client' bytes='6968' md5Hash='5e2d5cbf0506e3f16336d295093d66c4'/>
|
|
<schema ns='jabber:server' bytes='6948' md5Hash='dd95bd3055dfdd69984ed427cd6356e0'/>
|
|
<schema ns='jabber:x:roster' bytes='1077' md5Hash='00cb233dee83919067559c5dcee04f3d'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-sasl' bytes='2769' md5Hash='fd9a83f5c75628486ce18c0eb3a35995'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-streams' bytes='3315' md5Hash='75cd95aecb9f1fd66110c3ddcf00c9b8'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-tls' bytes='688' md5Hash='dc18bc4da35bc1be7a6c52aa43330825'/>
|
|
<schema ns='urn:ietf:params:xml:ns:xmpp-stanzas' bytes='3133' md5Hash='1a8d21588424f9134dc497de64b10c3f'/>
|
|
<schema ns='http://jabber.org/protocol/compress/exi' bytes='15094' md5Hash='8b8f91b95d9101f0781e0ba9b4e106be'/>
|
|
<schema ns='urn:xmpp:iot:control' bytes='6293' md5Hash='74dcea52300e8c8df8c4de2c9e90495b'/>
|
|
<schema ns='urn:xmpp:iot:sensordata' bytes='8092' md5Hash='49b101e7deea39ccc31340a3c7871c43'/>
|
|
<schema ns='urn:xmpp:iot:interoperability' bytes='1275' md5Hash='5d39845a0082715ff8807691698353bb'/>
|
|
<missingSchema ns='urn:xmpp:iot:provisioning' bytes='6303' md5Hash='3ed5360bc17eadb2a8949498c9af3f0c'/>
|
|
</setupResponse>]]></example>
|
|
<p>
|
|
Note the <strong>agreement</strong> attribute in the response this time. The server must set this attribute to true if it agrees with the proposal from the client.
|
|
The client in turn can check this attribute as a quick way to check if agreement exists. When the server is in agreement it must also return a Configuration ID
|
|
in the <strong>configurationId</strong> attribute. This Configuration ID can be used later to quicker enter into EXI compressed mode.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Uploading compressed schema files'>
|
|
<p>
|
|
The <strong>uploadSchema</strong> command has an optional attribute called <strong>contentType</strong> that can be used to send different types of documents
|
|
to the server. This is not a MIME content type, but an enumeration with the following options:
|
|
</p>
|
|
<table caption='contentType values'>
|
|
<tr>
|
|
<th>Value</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
<tr>
|
|
<td>Text</td>
|
|
<td>
|
|
The schema is sent as plain text, albeit base-64 encoded. If no encoding is provided in the XML header of the schema file,
|
|
UTF-8 encoding is assumed. This is the default value.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>ExiBody</td>
|
|
<td>The schema file is sent as an EXI compressed file, but only the body is sent. *</td>
|
|
</tr>
|
|
<tr>
|
|
<td>ExiDocument</td>
|
|
<td>The schema file is sent as an EXI compressed file. The entire file, including Exi header is provided. *</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
(*) These options assume the following set of default EXI options are used. It is assumed the XMPP server has more capabilities than the client, so the following
|
|
set of options must be supported by the XMPP server. The schema files can be precompressed and stored as binary files on the client for easier transmission.
|
|
</p>
|
|
<table caption='Default EXI options'>
|
|
<tr>
|
|
<th>Option</th>
|
|
<th>Default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>Version</td>
|
|
<td>1</td>
|
|
</tr>
|
|
<tr>
|
|
<td>alignment</td>
|
|
<td>bit-packed</td>
|
|
</tr>
|
|
<tr>
|
|
<td>compression</td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>strict</td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>fragment</td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>preserve</td>
|
|
<td>all false, except preserve prefixes that must be true or schema negotation may fail.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>selfContained</td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>schemaId</td>
|
|
<td>
|
|
The Schema of schemas: http://www.w3.org/2001/XMLSchema.xsd.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>datatypeRepresentationMap</td>
|
|
<td>No map</td>
|
|
</tr>
|
|
<tr>
|
|
<td>blockSize</td>
|
|
<td>N/A</td>
|
|
</tr>
|
|
<tr>
|
|
<td>valueMaxLength</td>
|
|
<td>unbounded</td>
|
|
</tr>
|
|
<tr>
|
|
<td>valuePartitionCapacity</td>
|
|
<td>unbounded</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
Since EXI compression does not perserve the extact binary representation of the schema file (for instance it doesn't preserve white space), the server
|
|
cannot correctly compute byte size and an MD5 hash for the file. Therefore, the client needs to provide this information in the <strong>uploadSchema</strong>
|
|
command using the <strong>bytes</strong> and <strong>md5Hash</strong> attributes. They are mandatory in case EXI compressed schema files are uploaded to the
|
|
server. Also note that the byte length and MD5 Hash should be computed on the original XML Schema file, not the compressed or decompressed version.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Downloading new schema files on server'>
|
|
<p>
|
|
As an alternative to uploading a schema file to the server, the client can ask the server to download a schema file by itself. This is done using the <strong>downloadSchema</strong>
|
|
command, as follows:
|
|
</p>
|
|
<example caption='Downloading a new XML schema file on server'><![CDATA[
|
|
<downloadSchema xmlns='http://jabber.org/protocol/compress/exi' url='http://schemavault.example.org/compress/sn/provisioning.xsd'/>
|
|
]]></example>
|
|
<p>
|
|
The server tries to download the schema by itself, and then computes the <strong>target namespace</strong>, <strong>byte size</strong> and <strong>MD5 Hash</strong>
|
|
from the downloaded schema.
|
|
</p>
|
|
<p>
|
|
When the schema has been downloaded, the following successful download response is returned:
|
|
</p>
|
|
<example caption='Schema successfully downloaded'><![CDATA[
|
|
<downloadSchemaResponse xmlns='http://jabber.org/protocol/compress/exi' url='http://schemavault.example.org/compress/sn/provisioning.xsd' result='true'/>
|
|
]]></example>
|
|
<p>
|
|
If an HTTP error occurred while trying to download the schema, a response as follows is returned:
|
|
</p>
|
|
<example caption='HTTP Error'><![CDATA[
|
|
<downloadSchemaResponse xmlns='http://jabber.org/protocol/compress/exi' url='http://schemavault.example.org/compress/sn/provisioning.xsd' result='false'>
|
|
<httpError code='404' message='NotFound'/>
|
|
</downloadSchemaResponse>]]></example>
|
|
<p>
|
|
If the URL could not be resolved, the following response is returned:
|
|
</p>
|
|
<example caption='Invalid URL'><![CDATA[
|
|
<downloadSchemaResponse xmlns='http://jabber.org/protocol/compress/exi' url='urk://example.org/schema.xsd' result='false'>
|
|
<invalidUrl message='Unrecognized schema.'/>
|
|
</downloadSchemaResponse>]]></example>
|
|
<p>
|
|
If a timeout occurred during the download attempt, the following response is returned:
|
|
</p>
|
|
<example caption='Timeout'><![CDATA[
|
|
<downloadSchemaResponse xmlns='http://jabber.org/protocol/compress/exi' url='http://schemavault.example.org/compress/sn/provisioning.xsd' result='false'>
|
|
<timeout message='No response returned.'/>
|
|
</downloadSchemaResponse>]]></example>
|
|
<p>
|
|
If the url points to something that is not a schema, the following response is returned:
|
|
</p>
|
|
<example caption='Invalid Content Type'><![CDATA[
|
|
<downloadSchemaResponse xmlns='http://jabber.org/protocol/compress/exi' url='http://schemavault.example.org/compress/sn/provisioning.xsd' result='false'>
|
|
<invalidContentType contentTypeReturned='text/html'/>
|
|
</downloadSchemaResponse>]]></example>
|
|
<p>
|
|
If an error occurs that is unforeseen by this specification, the server can simply respond with a generic error message, as follows:
|
|
</p>
|
|
<example caption='Other types of errors'><![CDATA[
|
|
<downloadSchemaResponse xmlns='http://jabber.org/protocol/compress/exi' url='http://schemavault.example.org/compress/sn/provisioning.xsd' result='false'>
|
|
<error message='No free space left.'/>
|
|
</downloadSchemaResponse>]]></example>
|
|
<p>
|
|
<strong>Note:</strong> Downloading a schema, might download a version which does not correspond to the desired version
|
|
of the schema. It might for instance have been updated. This means the <strong>bytes</strong> and <strong>md5Hash</strong> values
|
|
corresponding to the downloaded file will not match the values expected by the client. Therefore, it's in this case important the client
|
|
checks that the server actually downloaded the version of the schema required by the client so it doesn't assume the server uses
|
|
the same version of the schema when in actuality it doesn't.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Accessing quick configurations'>
|
|
<p>
|
|
Once an EXI setup has been accepted by the server, and agreement is reched, the server will provide the client with a quick Configuration ID
|
|
through the <strong>configurationId</strong> attribute. This Configuration ID can be used by the client during successive connections to the server,
|
|
to skip the larger part of the handshake, as is shown in the following example:
|
|
</p>
|
|
<example caption='Accessing quick configurations'><![CDATA[
|
|
<setup xmlns='http://jabber.org/protocol/compress/exi' configurationId='c76ab4ec-4993-4285-8c7a-098060581bb8'/>
|
|
]]></example>
|
|
<p>
|
|
<strong>Note:</strong> the quick configuration includes all accepted schemas and all EXI options agreed upon during the
|
|
session when the configuration ID was returned. The <strong>configurationId</strong> attribute MUST NOT be used together
|
|
with other option attributes or schema definitions in the setup request.
|
|
</p>
|
|
<p>
|
|
If the configuration is still available on the server, the server responds:
|
|
</p>
|
|
<example caption='Quick configuration accepted'><![CDATA[
|
|
<setupResponse xmlns='http://jabber.org/protocol/compress/exi' agreement='true' configurationId='c76ab4ec-4993-4285-8c7a-098060581bb8'/>
|
|
]]></example>
|
|
<p>
|
|
Note that schemas or options are not mentioned explicitly when using this quick setup approach.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Quick configuration failure'>
|
|
<p>
|
|
If the server for some reason does not remember the specific configuration requested by the client (the client might have been disconnected for
|
|
a long time), it responds in the following manner:
|
|
</p>
|
|
<example caption='Quick configuration failure'><![CDATA[
|
|
<setupResponse xmlns='http://jabber.org/protocol/compress/exi' agreement='false' configurationId='c76ab4ec-4993-4285-8c7a-098060581bb8'/>
|
|
]]></example>
|
|
<p>
|
|
The agreement attribute is optional, with a default value of false. So, if the attribute is omitted, the client must consider the
|
|
agreement to be nonexistent. When no agreement is reached using the quick configuration approach, the client must restart the handshake
|
|
and <link url='#setup'>propose new compression parameters</link>.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Start compression'>
|
|
<p>
|
|
When EXI option negotiation has been completed, the client can tell the server that it is ready to start compression. It does this using the normal <strong>compress</strong>
|
|
stanza, as follows:
|
|
</p>
|
|
<example><![CDATA[
|
|
<compress xmlns='http://jabber.org/protocol/compress'>
|
|
<method>exi</method>
|
|
</compress>]]></example>
|
|
<p>
|
|
The server now has the necessary knowledge on how the EXI engine should be configured for the current session and it responds as follows:
|
|
</p>
|
|
<example caption='Compression accepted'><![CDATA[
|
|
<compressed xmlns='http://jabber.org/protocol/compress'/>
|
|
]]></example>
|
|
<p>
|
|
When the client receives acknowledgement that the compression method has been accepted, it restarts the stream, as explained in
|
|
<link url='http://xmpp.org/extensions/xep-0138.html#usecase'>XEP 0138</link>, except that it <strong>must not</strong> resend the <strong><stream></strong>
|
|
start element sequence. Similarly, the client must not send a <strong></stream></strong> element when closing the session.
|
|
Instead, special <link url='#streamStart'>streamStart</link> and <link url='#streamEnd'>streamEnd</link> elements are sent. More information
|
|
about that later.
|
|
</p>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="EXI-specific stream elements">
|
|
<p>
|
|
Becuase EXI engines need to close all open XML elements before decompressing, it cannot start the stream by sending only an open <stream> element,
|
|
and close the stream by sending a closing </stream> element. Instead separate <strong>streamStart</strong> and <strong>streamEnd</strong> elements
|
|
have to be sent, allowing for similar semantics on the EXI-compressed channel, as described in the following subsections.
|
|
</p>
|
|
<p>
|
|
For clarity, examples in this section are displayed in XML for readability. But it is understood that the elements are sent using EXI compression and
|
|
using the options defined during setup.
|
|
</p>
|
|
<section3 topic="streamStart" anchor="startStream">
|
|
<p>
|
|
The first thing the client needs to do, once it opens the new EXI-compressed connection, whether it be through the normal XMPP connection or through
|
|
the alternative EXI-only binding, is to send a <strong>streamStart</strong> element. This element replaces the start stream tag normally sent.
|
|
</p>
|
|
<example caption='Start of EXI-compressed stream'>
|
|
<![CDATA[
|
|
<exi:streamStart from='client@im.example.org'
|
|
to='im.example.org'
|
|
version='1.0'
|
|
xml:lang='en'
|
|
xmlns:exi='http://jabber.org/protocol/compress/exi'>
|
|
<exi:xmlns prefix='' namespace='jabber:client'/>
|
|
<exi:xmlns prefix='streams' namespace='http://etherx.jabber.org/streams'/>
|
|
<exi:xmlns prefix='exi' namespace='http://jabber.org/protocol/compress/exi'/>
|
|
</exi:streamStart>]]>
|
|
</example>
|
|
<p>
|
|
There's a semantic difference between only writing an open XML element, and sending a closed XML element separately, and that is in the definition
|
|
of XML namespaces. XML namespaces and their corresponding prefixes defined in the normal <streams:stream> element will be available to all
|
|
child elements following in a normal XMPP stream. However, to be able to do the same in an EXP-compressed XMPP stream, you need to define the
|
|
namespaces and prefixes separately. Furthermore, the EXI/XMPP layer needs to make these namespace and prefix-definitions available to all following
|
|
elements sent on the stream. The empty prefix is synonymous with the default namespace to use.
|
|
</p>
|
|
</section3>
|
|
<section3 topic="streamEnd" anchor="streamEnd">
|
|
<p>
|
|
Before closing the connection, the client needs to send a <strong>streamEnd</strong> element. This element replaces the closing stream tag send normally.
|
|
</p>
|
|
<example caption='End of EXI-compressed stream'>
|
|
<![CDATA[
|
|
<exi:streamEnd xmlns:exi='http://jabber.org/protocol/compress/exi'/>]]>
|
|
</example>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic='Alternative Transport Binding for EXI/XMPP over TCP' anchor='alttrans'>
|
|
<!-- [YD] merged from yd's proposal 2013-04-16 -->
|
|
<!-- TODO: [PW] Revise use of MUST, SHOULD, COULD, etc. It seems SHOULD and SHOULD NOT is used when MUST/MUST NOT should be used. RECOMMENDED should be SHOULD. -->
|
|
<p>
|
|
Alternative binding for EXI/XMPP is suitable for use cases such as factory automation, smart grid appliances, and other
|
|
embedded use of communications. It works best if clients are constrained and does not update its specification frequently.
|
|
In addition, the network should allow clients and servers to use not well-known port because this commeunication involves
|
|
alternative TCP port.
|
|
</p>
|
|
<p>
|
|
Typical steps of communication is as follows (based on &rfc6120;).
|
|
</p>
|
|
<!-- TODO: [PW] Perhaps a bit more descriptive with references and links for more info? It is an XMPP specification, but one cannot assume readers are familiar with details of DHCP, etc. -->
|
|
<!-- TODO: [PW] A flow chart would be great. I can embed it inline. -->
|
|
<!-- TODO: [PW] Links & notes with references to RFC's. -->
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
(Optional)
|
|
A client (foo@example.net) try to resolve a server with alternative binding for EXI/XMPP with DNS SRV lookup (ex. _xmpp-bclient._tcp.example.net. IN SRV)
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
(Optional)
|
|
A DNS server tells a set of DNS RR to notify a server accepts EXI/XMPP binding (ex. SRV 10 10 15222 srv.example.net.) (Optional: the DNS server may tell the version of the default schema supported by the server. Currently there is only one version and has no effect. For further discussion, see <link url="http://tools.ietf.org/html/draft-doi-exi-messaging-requirements-01">draft-doi-exi-messaging-requirement</link>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>The client connects to srv.example.net. 15222 with TCP and the server accepts the connection.</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The client sends out 'EXI Cookie' (e.g. '$EXI') and starts EXI stream with an EXI Header without any option document (implies <link url="#defaultParam">default encoding parameters</link>). It sends out EXI events corresponds to start tag of <stream:stream>. Following shows XML Equivalent and EXI events <!-- TBD: shall be fixed after schema fix. -->
|
|
</p>
|
|
<example caption="XML equivalent of stream start element (Client to Server)">
|
|
<!-- samples/C2S/001-start.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:streamStart xmlns:exi='http://jabber.org/protocol/compress/exi' version="1.0" to="jabber.example.org" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >
|
|
<exi:xmlns prefix="stream" namespace="http://etherx.jabber.org/streams" />
|
|
<exi:xmlns prefix="" namespace="jabber:client" />
|
|
<exi:xmlns prefix="xml" namespace="http://www.w3.org/XML/1998/namespace" />
|
|
</exi:streamStart>
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream with EXI Header">
|
|
<!-- samples/exi-C2S-normal/base/001-base-start-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 8a 40 8c ad c0 28 d4 c2 c4 c4 ca e4 5c ca f0 c2
|
|
0000020 da e0 d8 ca 5c de e4 ce 00 20 04 89 a1 d1 d1 c0
|
|
0000040 e8 bc bd 95 d1 a1 95 c9 e0 b9 a9 85 89 89 95 c8
|
|
0000060 b9 bd c9 9c bd cd d1 c9 95 85 b5 cc 21 cd d1 c9
|
|
0000100 95 85 b4 07 b5 30 b1 31 32 b9 1d 31 b6 34 b2 b7
|
|
0000120 3a 01 02 66 87 47 47 03 a2 f2 f7 77 77 72 e7 73
|
|
0000140 32 e6 f7 26 72 f5 84 d4 c2 f3 13 93 93 82 f6 e6
|
|
0000160 16 d6 57 37 06 16 36 50 57 86 d6 ca
|
|
0000174
|
|
]]>
|
|
</example>
|
|
</li>
|
|
<li>
|
|
<p>The server responds with EXI stream, with EXI cookie, without EXI option, and with appropriate events for stream tag.</p>
|
|
<example caption="XML equivalent of stream start element (Server to Client)">
|
|
<!-- samples/S2C/001-base-start.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:streamStart xmlns:exi='http://jabber.org/protocol/compress/exi' version="1.0" from="jabber.example.org" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >
|
|
<exi:xmlns prefix="stream" namespace="http://etherx.jabber.org/streams" />
|
|
<exi:xmlns prefix="" namespace="jabber:client" />
|
|
<exi:xmlns prefix="xml" namespace="http://www.w3.org/XML/1998/namespace" />
|
|
</exi:streamStart>
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream with EXI Header">
|
|
<!-- samples/exi-S2C-normal/base/001-base-start-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 8a 02 8d 4c 2c 4c 4c ae 45 cc af 0c 2d ae 0d 8c
|
|
0000020 a5 cd ee 4c e2 08 ca dc 20 10 02 44 d0 e8 e8 e0
|
|
0000040 74 5e 5e ca e8 d0 ca e4 f0 5c d4 c2 c4 c4 ca e4
|
|
0000060 5c de e4 ce 5e e6 e8 e4 ca c2 da e6 10 e6 e8 e4
|
|
0000100 ca c2 da 03 da 98 58 98 99 5c 8e 98 db 1a 59 5b
|
|
0000120 9d 00 81 33 43 a3 a3 81 d1 79 7b bb bb b9 73 b9
|
|
0000140 99 73 7b 93 39 7a c2 6a 61 79 89 c9 c9 c1 7b 73
|
|
0000160 0b 6b 2b 9b 83 0b 1b 28 2b c3 6b 65
|
|
0000174
|
|
]]>
|
|
|
|
</example>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
If client needs TLS or SASL negotiation, it should be done at this step. As specified in <link url="http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-restart">Section 4.3.3 of RFC6120</link>, both parties MUST not send events corresponds to </stream:stream> tag. (e.g. exi:streamEnd element)
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
If client needs to use different encoding option or schema than the default encoding options or <link url="#defaultSchema">the default schema</link>, then the client shall start <link url="#schemaHandling">schema negotiation</link>. The streams with alternate options/schemas SHOULD NOT have an EXI Options document to indicate the parameter is negotiated via previous XMPP stream.
|
|
</p>
|
|
<p>
|
|
For example, the client want to use MUC option (<link url="http://xmpp.org/extensions/xep-0045.html">XEP-0045</link>), the following communication will occur. First, client try to renegotiate XML schema used in the communication.
|
|
</p>
|
|
<example caption="XML equivalent of setup element (Client to Server)">
|
|
<!-- samples/C2S/002-base-setup.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:setup xmlns:exi='http://jabber.org/protocol/compress/exi'>
|
|
<exi:schema ns="http://jabber.org/protocol/muc" bytes="1322" md5Hash="853ad555f102bb2b71da9a2f2787f4f9" />
|
|
<exi:schema ns="http://jabber.org/protocol/muc#owner" bytes="1284" md5Hash="6e4e2257c1a4ba937fbdf71664a7e793" />
|
|
</exi:setup>
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream">
|
|
<!-- samples/exi-C2S-normal/base/002-base-setup-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 7b 0a a0 a2 24 14 6a 69 4a 57 84 02 5a c4 b3 85
|
|
0000020 aa 4a 84 f1 1d 07 79 1e 92 06 87 47 47 03 a2 f2
|
|
0000040 f6 a6 16 26 26 57 22 e6 f7 26 72 f7 07 26 f7 46
|
|
0000060 f6 36 f6 c2 f6 d7 56 32 10 28 88 ce 23 84 22 9d
|
|
0000100 81 51 16 a4 8c ef 5b 5e 70 98 c4 51 dc 74 8c 99
|
|
0000120 a1 d1 d1 c0 e8 bc bd a9 85 89 89 95 c8 b9 bd c9
|
|
0000140 9c bd c1 c9 bd d1 bd 8d bd b0 bd b5 d5 8c 8d bd
|
|
0000160 dd b9 95 ca
|
|
0000164
|
|
]]>
|
|
</example>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
In the response the server accepts schema change.
|
|
</p>
|
|
<example caption="XML equivalent of setup element (Server to Client)">
|
|
<!-- samples/S2C/002-base-sestupResponse.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:setupResponse xmlns:exi='http://jabber.org/protocol/compress/exi' agreement="true" configurationId="a83b19b31e016409d3001331d9f084fc">
|
|
<exi:schema ns="http://jabber.org/protocol/muc" bytes="1322" md5Hash="853ad555f102bb2b71da9a2f2787f4f9" />
|
|
<exi:schema ns="http://jabber.org/protocol/muc#owner" bytes="1284" md5Hash="6e4e2257c1a4ba937fbdf71664a7e793" />
|
|
</exi:setupResponse>
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream">
|
|
<!-- samples/exi-S2C-normal/base/002-base-setupResponse-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 7c 08 c9 8d cd 8c 58 58 58 98 cc 0b 58 4c 8d 4d
|
|
0000020 4b 4d 18 8e 58 8b 4e 0e 58 4c 4b 4d 18 d8 8e 0d
|
|
0000040 4e 4d 4d 4e 4d 8e 4c 72 a8 28 89 05 1a 9a 52 95
|
|
0000060 e1 00 96 b1 2c e1 6a 92 a1 3c 47 41 de 47 a4 81
|
|
0000100 a1 d1 d1 c0 e8 bc bd a9 85 89 89 95 c8 b9 bd c9
|
|
0000120 9c bd c1 c9 bd d1 bd 8d bd b0 bd b5 d5 8c 84 0a
|
|
0000140 22 33 88 e1 08 a7 60 54 45 a9 23 3b d6 d7 9c 26
|
|
0000160 31 14 77 1d 23 26 68 74 74 70 3a 2f 2f 6a 61 62
|
|
0000200 62 65 72 2e 6f 72 67 2f 70 72 6f 74 6f 63 6f 6c
|
|
0000220 2f 6d 75 63 23 6f 77 6e 65 72 c0
|
|
0000233
|
|
]]>
|
|
</example>
|
|
<p>
|
|
Note that the server may deny the negotiation with agreement="false" setupResponse (example omitted).
|
|
</p>
|
|
</li>
|
|
<li>
|
|
|
|
<p>Just after receiving the setupResponse, client re-opens the stream. The new stream should have EXI header and may have EXI option header with updated options.</p>
|
|
<example caption="XML equivalent of stream start element (Client to Server)">
|
|
<!-- samples/C2S/010-base+muc-restart.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:streamStart xmlns:exi='http://jabber.org/protocol/compress/exi' version="1.0" to="jabber.example.org" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace">
|
|
<exi:xmlns prefix="stream" namespace="http://etherx.jabber.org/streams" />
|
|
<exi:xmlns prefix="" namespace="jabber:client" />
|
|
<exi:xmlns prefix="xml" namespace="http://www.w3.org/XML/1998/namespace" />
|
|
</exi:streamStart>
|
|
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream">
|
|
<!-- samples/exi-C2S-normal/base+muc/ -->
|
|
<![CDATA[
|
|
0000000 98 40 8c ad c0 28 d4 c2 c4 c4 ca e4 5c ca f0 c2
|
|
0000020 da e0 d8 ca 5c de e4 ce 00 20 04 89 a1 d1 d1 c0
|
|
0000040 e8 bc bd 95 d1 a1 95 c9 e0 b9 a9 85 89 89 95 c8
|
|
0000060 b9 bd c9 9c bd cd d1 c9 95 85 b5 cc 21 cd d1 c9
|
|
0000100 95 85 b4 07 b5 30 b1 31 32 b9 1d 31 b6 34 b2 b7
|
|
0000120 3a 01 02 66 87 47 47 03 a2 f2 f7 77 77 72 e7 73
|
|
0000140 32 e6 f7 26 72 f5 84 d4 c2 f3 13 93 93 82 f6 e6
|
|
0000160 16 d6 57 37 06 16 36 50 57 86 d6 ca
|
|
0000174
|
|
]]>
|
|
</example>
|
|
</li>
|
|
<li>
|
|
<p>In response, server re-opens the stream with exi:streamStart tag.</p>
|
|
<example caption="XML equivalent of stream start element (Server to Client)">
|
|
<!-- samples/S2C/010-base+muc-restart.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<!-- configuration id 761aabc0-a255-4b9b-89a1-4cb859559691 -->
|
|
<exi:streamStart xmlns:exi='http://jabber.org/protocol/compress/exi' version="1.0" to="jabber.example.org" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >
|
|
<exi:xmlns prefix="stream" namespace="http://etherx.jabber.org/streams" />
|
|
<exi:xmlns prefix="" namespace="jabber:client" />
|
|
<exi:xmlns prefix="xml" namespace="http://www.w3.org/XML/1998/namespace" />
|
|
</exi:streamStart>
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream">
|
|
<!-- samples/exi-S2C-normal/base+muc/010-base+muc-restart-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 98 02 8d 4c 2c 4c 4c ae 45 cc af 0c 2d ae 0d 8c
|
|
0000020 a5 cd ee 4c e2 08 ca dc 20 10 02 44 d0 e8 e8 e0
|
|
0000040 74 5e 5e ca e8 d0 ca e4 f0 5c d4 c2 c4 c4 ca e4
|
|
0000060 5c de e4 ce 5e e6 e8 e4 ca c2 da e6 10 e6 e8 e4
|
|
0000100 ca c2 da 03 da 98 58 98 99 5c 8e 98 db 1a 59 5b
|
|
0000120 9d 00 81 33 43 a3 a3 81 d1 79 7b bb bb b9 73 b9
|
|
0000140 99 73 7b 93 39 7a c2 6a 61 79 89 c9 c9 c1 7b 73
|
|
0000160 0b 6b 2b 9b 83 0b 1b 28 2b c3 6b 65
|
|
0000174
|
|
]]>
|
|
</example>
|
|
</li>
|
|
<li>
|
|
<p>After an exi:streamStart from the server to the client, they can communicate with EXI stream. The first level element in conventional XMPP is encoded as root element of EXI message. For example, a client may send MUC query with EXI.</p>
|
|
<example caption="XML equivalent of MUC chat message (Client to Server)">
|
|
<!-- samples/C2S/050-base+muc-muc-iq.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<iq xmlns="jabber:client" type="set" to="sensors@conference.example.org" id="ab26a" >
|
|
<query xmlns="http://jabber.org/protocol/muc#owner">
|
|
<x xmlns="jabber:x:data" type="submit" />
|
|
</query>
|
|
</iq>
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream with EXI Header">
|
|
<!-- samples/exi-S2C-normal/base+muc/050-base+muc-00-iq-response-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 42 20 73 65 6e 73 6f 72 73 40 63 6f 6e 66 65 72
|
|
0000020 65 6e 63 65 2e 65 78 61 6d 70 6c 65 2e 6f 72 67
|
|
0000040 07 61 62 32 36 61 47 d9 5e 1a 50 1a 98 58 98 99
|
|
0000060 5c 8b 99 5e 18 5b 5c 1b 19 4b 9b dc 99 cb dc d9
|
|
0000100 5b 9c db dc a8
|
|
0000105
|
|
]]>
|
|
</example>
|
|
<p>
|
|
This message has a query element under muc#owner namespace. This is performed efficiently because
|
|
this series of messages from the last streamStart element has been encoded with the set of schemas and the set inclues schemas for MUC.
|
|
Otherwise, the encoding will become 'built-in grammar' even if the encoder and the decoder uses non-strict schema-informed grammar.
|
|
This is not possible if either encoder or decoder does not support built-in grammar or the stream uses strict schema-informed grammar.
|
|
In such cases, the whole message that contains undefined element or attribute SHOULD be dropped. <!-- [YD] IS THIS OKAY? -->
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>The client and the server may end the stream with exi:streamEnd tag anytime.</p>
|
|
<example caption="XML equivalent of stream end element (Client to Server)" >
|
|
<!-- samples/C2S/099-base+muc-end.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<streamEnd xmlns='http://jabber.org/protocol/compress/exi' />
|
|
]]>
|
|
</example>
|
|
<example caption="Actual EXI Stream">
|
|
<!-- samples/exi-C2S-normal/base+muc/099-base+muc-end-N-SIs.dump -->
|
|
<![CDATA[
|
|
0000000 96
|
|
0000001
|
|
]]>
|
|
</example>
|
|
<p>
|
|
Exactly same message should be sent from the server to the client to close the opposite way of the stream (example omitted).
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The client now can start a preconfigured EXI/XMPP stream with explicit EXI option with the encoding option and canoinc schema used in the previous negotiated session (<link url="#shortcutAltBind">shortcut setup</link>)
|
|
</p>
|
|
<example caption="EXI Option Document used for Shortcut Setup (Client to Server)">
|
|
<!-- samples/quick-setup-header.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<header xmlns="http://www.w3.org/2009/exi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
|
<common>
|
|
<schemaId>c:761aabc0-a255-4b9b-89a1-4cb859559691</schemaId>
|
|
</common>
|
|
</header>
|
|
]]>
|
|
</example>
|
|
<example caption="XML Equivalent of streamStart">
|
|
<!-- samples/C2S/010-base+muc-restart.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:streamStart xmlns:exi='http://jabber.org/protocol/compress/exi' version="1.0" to="jabber.example.org" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace">
|
|
<exi:xmlns prefix="stream" namespace="http://etherx.jabber.org/streams" />
|
|
<exi:xmlns prefix="" namespace="jabber:client" />
|
|
<exi:xmlns prefix="xml" namespace="http://www.w3.org/XML/1998/namespace" />
|
|
</exi:streamStart>
|
|
]]>
|
|
</example>
|
|
<!--
|
|
<example caption="Actual EXI Stream with EXI option document">
|
|
FIXME: needs some development
|
|
</example>
|
|
-->
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The server may respond with the given configuration ID. This can skip the configuration setup and the communication can continue with preconfigured schemas.
|
|
</p>
|
|
|
|
<example caption="EXI Option Document used for Shortcut Setup (Server to Client)">
|
|
<!-- samples/quick-setup-header.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<header xmlns="http://www.w3.org/2009/exi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
|
<common>
|
|
<schemaId>c:761aabc0-a255-4b9b-89a1-4cb859559691</schemaId>
|
|
</common>
|
|
</header>
|
|
]]>
|
|
</example>
|
|
<example caption="XML Equivalent of streamStart in response">
|
|
<!-- samples/S2C/010-base+muc-restart.xml -->
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<exi:streamStart xmlns:exi='http://jabber.org/protocol/compress/exi' version="1.0" from="jabber.example.org" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >
|
|
<exi:xmlns prefix="stream" namespace="http://etherx.jabber.org/streams" />
|
|
<exi:xmlns prefix="" namespace="jabber:client" />
|
|
<exi:xmlns prefix="xml" namespace="http://www.w3.org/XML/1998/namespace" />
|
|
</exi:streamStart>
|
|
]]>
|
|
</example>
|
|
<!--
|
|
<example caption="Actual EXI Stream with EXI option document">
|
|
FIXME: needs some development
|
|
</example>
|
|
-->
|
|
<p>
|
|
Or server may deny to start the new communication by just sending streamEnd tag with default encoding.
|
|
</p>
|
|
<example caption="XML Equivalent of streamEnd to deny the configuration">
|
|
<![CDATA[
|
|
<?xml version="1.0"?>
|
|
<streamEnd xmlns='http://jabber.org/protocol/compress/exi' />
|
|
]]>
|
|
</example>
|
|
<!--
|
|
<example caption="Actual EXI Stream with EXI option document">
|
|
FIXME
|
|
</example>
|
|
-->
|
|
</li>
|
|
</ol>
|
|
<section3 topic="DNS SRV lookup" anchor="srv">
|
|
<p>
|
|
Just same with section 3.2.1 of RFC6120. The service name MUST be
|
|
'xmpp-bclient' (for binary client-to-server connections) or
|
|
'xmpp-bserver' (for binary server-to-server connections).
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Fallback Process' anchor='fallback'>
|
|
<p>
|
|
Fallback to well-known XMPP ports (5222, 5269) without doing SRV
|
|
lookup is allowed. In this case, an initiating entity SHOULD give up
|
|
connection if it receives non-EXI data (e.g. no EXI cookie and no
|
|
distinguishing bit is set) and SHOULD NOT do automatic retry.
|
|
</p>
|
|
<p>
|
|
When an initiating entity tries to communicate with an XMPP server
|
|
with EXI, it SHOULD start the stream with an EXI cookie
|
|
('$EXI') to avoid ambiguity.
|
|
</p>
|
|
<p>
|
|
Note: this expects an XMPP server shall return some error in plain
|
|
XML if the server receives EXI.
|
|
</p>
|
|
</section3>
|
|
<section3 topic="Default Payload Encoding Options for EXI/XMPP" anchor="defaultParam">
|
|
<!-- [YD]
|
|
TODO: requires discussion for merge
|
|
numerical parameter shall be defined by some more experiments and
|
|
analysis of actual traffics. [YD]
|
|
-->
|
|
<p>
|
|
When no EXI encoding option is given, or not specified by given EXI encoding option while negotiation, followings are the default
|
|
encoding options for EXI/XMPP messages.
|
|
</p>
|
|
<ul>
|
|
<li>alignment: bit-packed</li>
|
|
<li>compression: false</li>
|
|
<li>strict: true</li>
|
|
<li>fragment: false</li>
|
|
<li>preserve: all false</li>
|
|
<li>selfContained: false</li>
|
|
<li>schemaId: "urn:xmpp:exi:default"</li>
|
|
<!-- [YD] FIXME modified. Is this ok? -->
|
|
<li>datatypeReresentationMap: not exist</li>
|
|
<li>blockSize: N/A</li>
|
|
<li>valueMaxLength: 64</li>
|
|
<li>valuePartitionCapacity: 64</li>
|
|
</ul>
|
|
<!-- [YD] agreed 2013-07-12:
|
|
// 4K RAM for value partitions - is this enough small?
|
|
// valueMaxLength should be something like 95% percentile of JID
|
|
// sorted by the length
|
|
-->
|
|
<p>
|
|
In addition, local value learning mechanism is disabled by
|
|
default as described in section 4 of <link url="https://www.w3.org/TR/exi-profile/">EXI Profile</link>.
|
|
<!-- FIXME: [YD] add reference to available implementations -->
|
|
</p>
|
|
<ul>
|
|
<li>localValuePartitions: 0</li>
|
|
<li>maximumNumberOfBuiltInElementGrammars: 0 (means no grammar learning)</li>
|
|
<li>maximumNumberOfBuiltInProductions: 0 (means no production learning)</li>
|
|
</ul>
|
|
<p>
|
|
Corresponding parameter for EXI Profile is as follows:
|
|
</p>
|
|
<code>
|
|
<p xmlns="http://www.w3.org/2009/exi"
|
|
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
|
|
xsi:type="xsd:decimal">1.1</p>
|
|
</code>
|
|
</section3>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Implementation Notes' anchor='impl'>
|
|
<section2 topic='EXI Encoding Preprocessing and Postprocessing'>
|
|
<!-- [YD] added to provide 'common view' on implementation. This can be introductionaly and I placed as the first section of implementation notes. Please move this section to somewhere else to improve readability -->
|
|
<p>
|
|
This section describes a common view on programming model between EXI/XMPP servers and clients. This is just an example and an implementation may do it in different ways. However, messages exchanged as a result should be identical.
|
|
</p>
|
|
<p>
|
|
As shown in this document, XMPP documents represented by EXI is slightly different from documents represented in XML.
|
|
For example, each stanzas and first level elements under <stream:stream> tags must be encoded as a standalone EXI
|
|
body (document). If namespace prefixes are declared in the root element of XML process (<stream:stream> tag),
|
|
the prefix should be recovered on decoded XML on the receiver side (EXI may or may not preserve prefix).
|
|
Therefore, some preprocessing and postprocessing is required to make current XMPP implementations work properly over
|
|
EXI/XMPP channel. An example of the configuration is described in the following figure.
|
|
</p>
|
|
<example caption='Example configuration of communication channels.'>
|
|
<![CDATA[
|
|
+-------------------------+ +-----------------------+
|
|
| +----+ | | +----+ |
|
|
| | | <------------------ Plain XMPP Channel ----------------> | | |
|
|
| |XMPP| | | |XMPP| |
|
|
| | | <-[Proc]-[EXI]<------- EXI Channel ------>[EXI]-[Proc]-> | | |
|
|
| +----+ | | +----+ |
|
|
+-------------------------+ +-----------------------+
|
|
]]>
|
|
</example>
|
|
<p>
|
|
In the example, the box XMPP is conventional XMPP process. [EXI] represents EXI processor (encoder and decoder). [Proc] means preprocessor and postprocessor.
|
|
Following pre-process must be applied to XML streams from XMPP process before giving the stream to EXI processors.
|
|
</p>
|
|
<ol>
|
|
<li><stream:stream> start tag must be converted to standalone <exi:streamStart> element. All attributes defined in the input XML except namespace declarations should be copied as is. Namespace declarations and prefixes must be converted to exi:xmlns element under exi:streamStart element.</li>
|
|
<li>All first level elements under the root <stream:stream> element must be converted to standalone (root) element of corresponding stanza elements. If there are missing namespace declarations in the element, appropriate prefix declarations should be added to the element before giving the element to the EXI encoder as a document. Contents of the elements should not be modified.</li>
|
|
<li></stream:stream> end tag must be converted to standalone <exi:streamEnd> element.</li>
|
|
</ol>
|
|
|
|
<p>
|
|
Following post-process must be applied to XML streams from EXI processors before giving the stream to XMPP process.
|
|
</p>
|
|
<ol>
|
|
<li>Received <exi:streamStart> element must be converted to <stream:stream> start tag with appropriate attributes and namespace declarations. Prefixies defined in the <exi:streamStart> content must be saved under the current connection context of postprocessor.</li>
|
|
<li>Received EXI messages must be reproduced as elements under <stream:stream> root element. In addition, the namespace declarations in the element must be replaced to prefixes given in the streamStart tag content if there is a corresponding namespace declaration.</li>
|
|
<li><exi:streamEnd> element must be converted to </stream:stream> end tag. The context created under the connection may be released.</li>
|
|
</ol>
|
|
</section2>
|
|
<section2 topic='EXI options'>
|
|
<!-- [YD] FIXME: agreed: change this description as simple list of options and reference to the EXI spec. XMPP-dependent description may be added. -->
|
|
<!-- [YD] FIXME: add some numbers according to examples to show effects (in size) -->
|
|
<!-- DATA URI Scheme can be used to add figures (memo) -->
|
|
<p>
|
|
There are many <link url='http://www.w3.org/TR/exi/#options'>EXI options</link> in EXI Format. Followings are brief description for use in XMPP.
|
|
</p>
|
|
<p>
|
|
The <strong>alignment option</strong> is to control how the values are encoded. The default option 'bit-packed' fits most of communication use cases. If TLS compression is used at the same time, pre-compression will make the best result.
|
|
</p>
|
|
<p>
|
|
The <strong>compression option</strong> is a Boolean to specify additional entropy-based compression is performed over EXI encoding. This option works best for larger documents. Usual use cases expected in XMPP/EXI may not give much additional compactness to messages.
|
|
</p>
|
|
<p>
|
|
The <strong>strict option</strong> is a Boolean to let EXI grammars (schema-informed grammars) work more strictly. With a strict schema-informed grammar, only valid data with the schema is allowed in streams. This makes best compactness of a grammar and messages without additional entropy-based compression. With nonstrict schema-informed grammar, derived elements and attributes could be encoded in the built-in grammar. The built-in grammar is a dynamic, self-learning grammar model that gives full flexibility, with larger message size.
|
|
</p>
|
|
<p>
|
|
The <strong>preserve option</strong> is a set of Booleans to alter some production of events. Usually, all false (no preservation of comments, processing instructions, DTDs, namespace declarations and its prefixes, and lexical values) makes no problem on XMPP communication. However, uploading a binary schema may require the schema encoded with preserved namespace prefixes. The prefixes are used in type definitions, and without prefix preservation binding between type definition references and actual definitions will be lost.
|
|
</p>
|
|
<p>
|
|
The <strong>selfContained option</strong> is a Boolean to enable self contained encoding of elements. Self contained element has no dependency to context (string table state in EXI processors) and can be copied to other context with the same grammar. However, self contained elements cannot use external string tables in EXI processors and may result larger size.
|
|
</p>
|
|
<p>
|
|
The <strong>datatypeRepresentationMap option</strong> can be used to modify how types encoded in EXI. If encoders and decoders have special encoding, it can be specified here. In most use cases in XMPP/EXI, this option will not be used.
|
|
</p>
|
|
<p>
|
|
The <strong>blockSize option</strong> specifies the block size used for EXI compression. It has no effect if compression is not used.
|
|
</p>
|
|
<p>
|
|
The <strong>valueMaxLength option</strong> specifies the maximum length of re-used string in a stream. Larger value makes more strings captured in string tables in EXI processors. This means more memory needs to be allocated to process a stream. Because some use cases, such as Internet of Things, expects constrained nodes in the network, default value specified in ths XEP is very small (64 characters).
|
|
</p>
|
|
<p>
|
|
The <strong>valuePartitionCapacity option</strong> specifies how many strings should be kept in a string table in a time. Default value of this is also small in this XEP (64 strings).
|
|
</p>
|
|
<!-- [YD] This option should not be considered as EXI option. I added a note at the beginning of the paragraph. -->
|
|
<p>
|
|
To control buffer and string table life time, this XEP adds a new option: <strong>sessionWideBuffers</strong>.
|
|
If set to true, all buffers, string tables, etc. will be maintained during the entire session.
|
|
This may improve performance during time since strings can be omitted in the compressed binary stream, but it might also in some cases degrade performance since more options are
|
|
available in the tables, requiring more bits to encode strings. The default value is false, meaning that buffers, string tables, etc., are cleared between each stanza. (This option
|
|
is EXI/XMPP specific.)
|
|
</p>
|
|
<section3 topic='Evaluations of Options'>
|
|
<p>
|
|
This section describes effects in message size for some options.
|
|
</p>
|
|
<p>
|
|
The option <strong>sessionWideBuffers</strong> must have large effect in XMPP communication, because many XIDs are re-used many time within a XMPP stream.
|
|
If sessionWideBuffers option is enabled, most of XIDs can be encoded in short identifiers as it appears in some previous messages. Followings are
|
|
preliminary evaluation of message size of XML (plain old XML), EXI with sessionWideBuffers=false, and EXI with sessionWideBuffers=true.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<!-- % for x in C2S/*.xml S2C/*.xml; do xmlindent -i 0 -l 10000 $x|grep -v '^<?xml'|tr -d '\n'; done|wc -c -->
|
|
<strong>Plain Old XML (without XML declaration, whitespaces)</strong>: 5011 bytes in 22 messages
|
|
</li>
|
|
<li>
|
|
<!-- % cat samples/exi-{C2S,S2C}-normal/{base,base+muc}/*.exi|wc -c -->
|
|
<strong>EXI without sessionWideBuffers</strong>: 1614 bytes in 22 messages
|
|
</li>
|
|
<li>
|
|
<!-- % cat samples/exi-{C2S,S2C}-persistent/{base,base+muc}/*.exi|wc -c -->
|
|
<strong>EXI with sessionWideBuffers</strong>: 1458 bytes in 22 messages <!-- [YD] effect is lower than expected...? -->
|
|
</li>
|
|
</ul>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic='Transmission of EXI bodies and Session-wide Buffers'>
|
|
<p>
|
|
The transmission of EXI-compressed stanzas takes the form of a sequence of EXI bodies. In order for the recipient to be able to correctly interpret these incoming
|
|
EXI bodies, the sender is required to flush any pending bits at the end of the last End Document (ED) event for each stanza and then send any pending bytes available
|
|
in the output buffer. Since this makes sure each EXI body starts at an even byte boundary, it permits the recipient to decompress the body into an XML stanza.
|
|
</p>
|
|
<p>
|
|
Therefore, each stanza sent on the stream, must be compressed separately, reusing the same options as used by the stream.
|
|
(Options are not sent on the stream, only the generated EXI bodies).
|
|
</p>
|
|
<p>
|
|
Compression of the stanza must be done in document mode, not fragment mode, including the Start Document (SD) and End Document (ED) events.
|
|
If there are unwritten bits pending after the last End Document (ED) event (after the end of the stanza), Zero-bits are written until a byte boundary is created.
|
|
The receptor must ignore bits in the last byte after the last End Document event has been received.
|
|
</p>
|
|
<p>
|
|
During setup of the EXI compression engine, the client can choose if buffers are to be reused between stanzas, or cleared between each stanza. This is done
|
|
using the EXI over XMPP specific option <strong>sessionWideBuffers</strong>, which is false by default, meaning buffers and string tables are cleared between
|
|
each stanza.
|
|
</p>
|
|
<p>
|
|
There may be cases where maintaining buffers and string tables throughout the session is preferrable. Since strings are already available in the buffers,
|
|
they don't need to be output in the stream the first time they appear in a stanza. However, the number of strings in tables increase, and so does the number of bits required to
|
|
encode them. Depending on what type of communication is performed, this option might give better results one way or another. If the same type of message is always
|
|
sent, maintaining string buffers may be more efficient. But if the client sends many many different types of messages, clearing buffers may be more efficient.
|
|
</p>
|
|
<p>
|
|
Note that the stream of EXI bodies is indefinite. It only stops when the session is closed, i.e. when the socket connection is dropped. Therefore, the buffers can grow
|
|
indefinitely unless control is maintained on what types of messages are sent, their contents (specifically string values), and to whom they are sent (JIDs being strings).
|
|
All string tables and buffers must be cleared when a connection is lost.
|
|
</p>
|
|
<p>
|
|
Note also that if you want the option to enter a session in the middle of the flow to listen to the communication, you need to clear tables and buffers between each
|
|
stanza, or you will not be able to decode the binary stream appropriately.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Preserving prefixes'>
|
|
<p>
|
|
Normally, prefixes are not preserved during EXI compression and decompression. If the communicating parties (sending client, XMPP server(s) and receiving clients)
|
|
interpret incoming stanzas and content according to namespace, this should be sufficient. However, some implementations do not check namespaces, but prefix names used.
|
|
In such cases, all communicating parties are required to enable the preserve prefixes option during negotionating.
|
|
</p>
|
|
<p>
|
|
<strong>Note:</strong> It is not sufficient that one party enable this option. Both sender and received are required to enable this option, or prefix names will be
|
|
lost in the transmission.
|
|
</p>
|
|
<p>
|
|
Note also, that preserving prefix names result in less efficient compression. Therefore, all clients implementing EXI compression should strive to parse incoming
|
|
XML based on namespace, not prefix name.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Networks containing clients having limited memory'>
|
|
<p>
|
|
To successfully implement a network with clients having limited memory, such as sensor networks, care should be taken to make sure necessary schema files are
|
|
preinstalled on the server, to avoid the necessity to upload schema files from the clients. Clients with limited memory might be unable to perform this task.
|
|
</p>
|
|
<p>
|
|
An alternative may be to install a richer client, that can upload the schema files to the server dynamically, and installing it into the network. Any client uploading
|
|
a schema file, will make that schema file available for EXI compression to any other client in the network.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Caching schema files'>
|
|
<p>
|
|
Schema files uploaded to the server should be cached on the server in some kind of schema repository. If memory is limited on the server, schema files should be
|
|
sorted by last access. Schema files with the oldest last access timestamp could be removed to maintain the cache within an approved cache size.
|
|
</p>
|
|
<p>
|
|
Note that schema files have three keys: <strong>Target namespace</strong>, <strong>byte size</strong> and <strong>MD5 Hash</strong>. Multiple versions of a schema file
|
|
may exist (that is, with the same target namespace but different byte sizes or MD5 hash codes). Note also, that for any practical purpose, schema files can be stored
|
|
using only the MD5 hash as a key, since it is highly improbable that two different schema files will have the same MD5 hash (unless consciously created that way). MD5 hash
|
|
values are always in <strong>lower case</strong>.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Uploading vs. Downloading schemas'>
|
|
<p>
|
|
When the server lacks information about a given XML schema, the client has two options for updating the server. Either it uploads the schema, or it asks the server to
|
|
download one.
|
|
</p>
|
|
<p>
|
|
Uploading a schema has the advantage, that the client knows exactly the version that the server requires. It has the disadvantage, that the client needs to store the schema
|
|
and send a possible large schema to the server. If EXI is used because the device has limited memory, uploading a schema might not be an option.
|
|
</p>
|
|
<p>
|
|
Downloading a schema has the advantage, that size of schema does not matter. The disadvantage is that asynchronous errors might occur, so the client needs to pay attention
|
|
to the responses returned by the server when downloading schemas. Also, downloading a schema, might download a version which does not correspond to the desired version
|
|
of the schema. So, it's more important in this case that the client checks that the server actually has the version of the schema required by the client.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Server decompression and recompression vs. binary forwarding'>
|
|
<p>
|
|
If two XMPP clients communicate with each other through an XMPP server, and both clients use EXI compression, the server must only forward
|
|
binary packets if both EXI compressed channels have exactly the same setup. If any parameter is different, the server MUST always recompress
|
|
packets sent through it.
|
|
</p>
|
|
<p>
|
|
Since the server always needs to decompress incoming EXI compressed packets to decode headers, omitting the compression part might save the server
|
|
some processing power, but not all. Note that, in some networks it might be common using similar compression settings, while in others different compression
|
|
settings are most common.
|
|
</p>
|
|
<p>
|
|
Also note that binary forwarding is only possible if session-wide buffers are not used.
|
|
</p>
|
|
</section2>
|
|
<section2 topic="Snapshot Repository for Well-known Schemas" anchor='wellknown'>
|
|
<!-- [YD] -->
|
|
<!-- TODO: Should be in section Implementation Notes. This section is for the protocol schema, not the schemas used for compression. -->
|
|
<p>
|
|
Errata and other updates may happen to well-known schemas. Slightest
|
|
modification to XML schemas may break interoperability of EXI
|
|
nodes. However, negotiating everything is not efficient. Well-known
|
|
and aged schemas that referred from the schema for EXI/XMPP shall be
|
|
snapshoted for use in EXI processors.
|
|
|
|
<!-- TODO: [PW] Why not efficient? In terms of total amount of communication performed during a device's lifetime, its a very very small fraction (insignificant).
|
|
This is a subjective opinion, termed in absolute phraseology. -->
|
|
</p>
|
|
<p>
|
|
Actual snapshot is located in (TBD-URL).
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Generation of Canonic Schemas'>
|
|
<p>
|
|
The interface between the XMPP engine, whether in the client or the server, and the EXI compression engine is required to provide the engine
|
|
with ONE XML Schema to use during the compression. The <link url='http://www.w3.org/TR/exi/'>Efficient XML Interchange (EXI) Format</link>
|
|
also specifies the use of Schema IDs identifying the schema to use.
|
|
</p>
|
|
<p>
|
|
However, in the XMPP case, the schema to provide to the EXI compression engine must be created dynamically based on the handshake provided during
|
|
setup of the connection. Since this generation must be done both on the server side as well as the client side, it is important that the schemas be
|
|
created semantically equivalent. This section describes how to create such schemas, henceforth called <strong>Canonical Schemas</strong> is described
|
|
in this section.
|
|
</p>
|
|
<p>
|
|
A canonical schema is simply a wrapper importing each of the schemas negotiated for the connection. The schemas MUST be imported in ascending namespace
|
|
order.
|
|
</p>
|
|
<p>
|
|
After generating the canonical schema, it's a good idea to create a corresponding Configuration ID. The Configuration ID however, includes not only
|
|
the schemas imported into the canonical schema, but also the EXI options to use during compression/decompression. The canonical schema should be
|
|
persisted for simple reuse when quick setup is used.
|
|
</p>
|
|
<p>
|
|
The target namespace of the canonical schema MUST be <strong>urn:xmpp:exi:cs</strong>.
|
|
</p>
|
|
<p>
|
|
The Schema ID to use is irrelevant in the XMPP layer of communiction. Therefore, the server and client can create their own Schema IDs, according to some
|
|
algorithm. It is not important if the Schema IDs match, since they are not used in data transmitted between the client and server.
|
|
</p>
|
|
</section2>
|
|
<section2 topic="Using EXI Option Documents for Shortcut Setup" anchor="shortcut">
|
|
<p>
|
|
The <strong>configurationId</strong> attribute has a similar attribute called <strong>configurationLocation</strong>. This attribute provides
|
|
a mechanism to setup an EXI connection rapidly using option documents installed as files on the server or available on the network accessible
|
|
through an URL.
|
|
</p>
|
|
<p>
|
|
A client may specify a configurationId or configurationLocation on exi:setup element. If the server has corresponding setup configuration, the server may respond with an exi:setupResponse with <strong>agreement="true"</strong>. If the server does not know the configurationId or does not be able to use the given configurationLocation, the server shall respond with an exi:setupResponse with <strong>agreement="false"</strong>.
|
|
</p>
|
|
<p>
|
|
This specification does not define the format of this Configuration Location attribute, and so it is server specific, or if it is supported.
|
|
If used on a server not supporting this attribute, or if the contents of the attribute is invalid, the server returns an <strong>agreement=false</strong>
|
|
response. Otherwise the semantics of the <strong>configurationLocation</strong> attribute is the same as for the <strong>configurationId</strong>
|
|
attribute, except it provide a mechism for static configurations, while the <strong>configurationId</strong> provides a mechanism for
|
|
dynamic configurations.
|
|
</p>
|
|
<p>
|
|
The format for these opton documents or locations is beyond the scope of this specification.
|
|
</p>
|
|
<p>
|
|
The format for these opton documents or locations is beyond the scope of this specification.
|
|
</p>
|
|
<section3 topic="Shortcut Setup for Alternative Transport Binding" anchor="shortcutAltBind">
|
|
<p>With alternative transport bind, following rule for shortcut may be used, assuming a server and a client have common shared configuration with configurationId="01234" as an example.</p>
|
|
<ul>
|
|
<li>
|
|
Client can start configured stream with a <strong>exi:streamStart</strong> element encoded in the configuration given in configurationId="01234". To indicate configurationId, a schemaId corresponds to the configurationId prefixed by "c:" SHALL be used. In this example, schemaId is "c:01234". EXI option in EXI option header other than the schemaId SHOULD NOT be specified.
|
|
</li>
|
|
<li>
|
|
If the server accepts the configuration, the server SHOULD respond with a <strong>exi:streamStart</strong> element encoded in the configuration given in the configurationId. The server SHALL put the schemaId in the EXI header of the response. No EXI options other than the schemaId SHOULD NOT be specified in the response EXI header. The EXI header is the indication of configuration agreement and SHALL NOT be omitted.
|
|
</li>
|
|
<li>
|
|
If the server does not accept the configuration, the server SHALL respond with a <strong>exi:streamEnd</strong> element encoded in the <link url="#defaultSchema">default schema</link> and the EXI header option SHOULD be empty.
|
|
</li>
|
|
<li>
|
|
The client can continue pre-configured stream if and only if it receives <strong>exi:streamStart</strong> element encoded in the configurationId with EXI option header that contains the identical schemaId. Otherwise, the client SHOULD start a new <strong>exi:streamStart</strong> with a new TCP connection an empty EXI option header (e.g. default schema). Current TCP connection SHOULD NOT be used for re-negotiation (configuration setup).
|
|
</li>
|
|
</ul>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="XMPP Schema files and their hash values" anchor="knownhashes">
|
|
<p>
|
|
The following table lists XMPP schemas at the time of writing, and their corresponding bytes sizes and MD5 Hash values.
|
|
</p>
|
|
<table>
|
|
<tr>
|
|
<th>Namespace</th>
|
|
<th>Schema</th>
|
|
<th>Bytes</th>
|
|
<th>MD5 hash</th>
|
|
</tr>
|
|
<tr>
|
|
<td>http://etherx.jabber.org/streams</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/streams.xsd">streams.xsd</link>
|
|
</td>
|
|
<td>3450</td>
|
|
<td>68719b98725477c46a70958d1ea7c781</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/features/amp</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/amp-feature.xsd">amp-feature.xsd</link>
|
|
</td>
|
|
<td>635</td>
|
|
<td>cb4f48c999c1cce15df4f3129e55f381</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/features/compress</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/compress-feature.xsd">compress-feature.xsd</link>
|
|
</td>
|
|
<td>670</td>
|
|
<td>8ff631b7aaf9a196470ec57897251f7c</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/activity</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/activity.xsd">activity.xsd</link>
|
|
</td>
|
|
<td>5043</td>
|
|
<td>b6168aac76260aed41071fbe5c930279</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/address</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/address.xsd">address.xsd</link>
|
|
</td>
|
|
<td>1915</td>
|
|
<td>8770419083d7f4044ee4b55e39e3c6e3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/amp</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/amp.xsd">amp.xsd</link>
|
|
</td>
|
|
<td>1858</td>
|
|
<td>b929b5024af92ccb2f21af944e1caa6b</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/amp#errors</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/amp-errors.xsd">amp-errors.xsd</link>
|
|
</td>
|
|
<td>963</td>
|
|
<td>7a366c21bbf2060f2658e9118bfc32e9</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/bytestreams</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/bytestreams.xsd">bytestreams.xsd</link>
|
|
</td>
|
|
<td>2343</td>
|
|
<td>83211fe7c25510d9254a9aa6cf31b1e0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/caps</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/caps.xsd">caps.xsd</link>
|
|
</td>
|
|
<td>1072</td>
|
|
<td>ed68bc908f301556d1cf9ad111c34184</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/chatstates</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/chatstates.xsd">chatstates.xsd</link>
|
|
</td>
|
|
<td>827</td>
|
|
<td>c00838d97b9c2a37ac098130a27b1b4c</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/commands</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/commands.xsd">commands.xsd</link>
|
|
</td>
|
|
<td>3551</td>
|
|
<td>98b0e90b35e00b04b2253af26faaab6f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/compress</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/compress.xsd">compress.xsd</link>
|
|
</td>
|
|
<td>1505</td>
|
|
<td>7ac2a9dc7472af2796be239dbc7097ac</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/compress/exi</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/exi.xsd">exi.xsd</link>
|
|
</td>
|
|
<td>15339</td>
|
|
<td>4c33b8ac3b902582f50e25233dc0737c</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/disco#info</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/disco-info.xsd">disco-info.xsd</link>
|
|
</td>
|
|
<td>1783</td>
|
|
<td>d5e696ad7aa800cba7f54740b0e2a6c8</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/disco#items</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/disco-items.xsd">disco-items.xsd</link>
|
|
</td>
|
|
<td>1482</td>
|
|
<td>6010e2e5dafd587fc1609987805c7295</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/feature-neg</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/feature-neg.xsd">feature-neg.xsd</link>
|
|
</td>
|
|
<td>766</td>
|
|
<td>a154eeb514f8acbe0291c48d4e7335a5</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/geoloc</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/geoloc.xsd">geoloc.xsd</link>
|
|
</td>
|
|
<td>2322</td>
|
|
<td>90b0df99a0e6ee77929955b63b384656</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/http-auth</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/http-auth.xsd">http-auth.xsd</link>
|
|
</td>
|
|
<td>1020</td>
|
|
<td>fdd34da7014b044fd659091843d802cd</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/httpbind</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/httpbind.xsd">httpbind.xsd</link>
|
|
</td>
|
|
<td>4028</td>
|
|
<td>59559ed6a5025c2e4ecf1a9ad675c707</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/ibb</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/ibb.xsd">ibb.xsd</link>
|
|
</td>
|
|
<td>1557</td>
|
|
<td>45bac4486abb974f0d92ee98d8e356de</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/mood</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/mood.xsd">mood.xsd</link>
|
|
</td>
|
|
<td>3994</td>
|
|
<td>93bb8be5dab135b7189c475f3d80a03a</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/muc</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/muc.xsd">muc.xsd</link>
|
|
</td>
|
|
<td>1322</td>
|
|
<td>853ad555f102bb2b71da9a2f2787f4f9</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/muc#admin</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/muc-admin.xsd">muc-admin.xsd</link>
|
|
</td>
|
|
<td>2260</td>
|
|
<td>627d39d09e18208f0b068ff3ee1e4dc2</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/muc#owner</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/muc-owner.xsd">muc-owner.xsd</link>
|
|
</td>
|
|
<td>1284</td>
|
|
<td>6e4e2257c1a4ba937fbdf71664a7e793</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/muc#unique</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/muc-unique.xsd">muc-unique.xsd</link>
|
|
</td>
|
|
<td>512</td>
|
|
<td>43f77e28d5574453f1208c653a4eb710</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/muc#user</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/muc-user.xsd">muc-user.xsd</link>
|
|
</td>
|
|
<td>3881</td>
|
|
<td>4c2643e702a591ed09dd4e1af15f46f5</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/nick</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/nick.xsd">nick.xsd</link>
|
|
</td>
|
|
<td>498</td>
|
|
<td>280d55dac18c98559ea514e822d692d1</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/offline</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/offline.xsd">offline.xsd</link>
|
|
</td>
|
|
<td>1157</td>
|
|
<td>e0c329c185c3339480a78b8662be92a0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/pubsub</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/pubsub.xsd">pubsub.xsd</link>
|
|
</td>
|
|
<td>7296</td>
|
|
<td>18b754fd463509c7c95bde5a6bf54a07</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/pubsub#errors</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/pubsub-errors.xsd">pubsub-errors.xsd</link>
|
|
</td>
|
|
<td>4637</td>
|
|
<td>20479f150ffe1fa932da529528d89aa0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/pubsub#event</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/pubsub-event.xsd">pubsub-event.xsd</link>
|
|
</td>
|
|
<td>4866</td>
|
|
<td>003ba8f4780822511a84cc8f83ca6c95</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/pubsub#owner</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/pubsub-owner.xsd">pubsub-owner.xsd</link>
|
|
</td>
|
|
<td>4387</td>
|
|
<td>f0d2a4733fe7991135172ff6cfec66d9</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/rosterx</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/rosterx.xsd">rosterx.xsd</link>
|
|
</td>
|
|
<td>1338</td>
|
|
<td>97bfd4958edef7fb962eba8fe38ce810</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/rsm</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/rsm.xsd">rsm.xsd</link>
|
|
</td>
|
|
<td>1379</td>
|
|
<td>340cfcdf0827a12f8ba0fbca6b28aa37</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/shim</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/shim.xsd">shim.xsd</link>
|
|
</td>
|
|
<td>911</td>
|
|
<td>989fc4e6a95c1e763ec17245ac622c1a</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/si</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/si.xsd">si.xsd</link>
|
|
</td>
|
|
<td>1530</td>
|
|
<td>d00cd67eec0a6923ad01865c507d4808</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/si/profile/file-transfer</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/file-transfer.xsd">file-transfer.xsd</link>
|
|
</td>
|
|
<td>1479</td>
|
|
<td>8fbc4d2d7972696b30132a4092336122</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/sipub</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sipub.xsd">sipub.xsd</link>
|
|
</td>
|
|
<td>1655</td>
|
|
<td>3eafe26f5ade2fbbf0cc9d354051ead7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/soap#fault</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/soap-fault.xsd">soap-fault.xsd</link>
|
|
</td>
|
|
<td>856</td>
|
|
<td>df3517931ab9dcc747f89e7c84851d8e</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/tune</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/tune.xsd">tune.xsd</link>
|
|
</td>
|
|
<td>1237</td>
|
|
<td>d5ba7c1a0e061e7c2c1ec325f583edfb</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/waitinglist</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/waitinglist.xsd">waitinglist.xsd</link>
|
|
</td>
|
|
<td>2431</td>
|
|
<td>45637c6ae8a3db8048edeb241d54ff3e</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/xdata-layout</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/xdata-layout.xsd">xdata-layout.xsd</link>
|
|
</td>
|
|
<td>2021</td>
|
|
<td>c74f116543466f6a39352a2f95bc5e2d</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/xdata-validate</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/xdata-validate.xsd">xdata-validate.xsd</link>
|
|
</td>
|
|
<td>1874</td>
|
|
<td>0ace852dda1d5e9a72427515e934b342</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://jabber.org/protocol/xhtml-im</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/xhtml-im-wrapper.xsd">xhtml-im-wrapper.xsd</link>
|
|
</td>
|
|
<td>1402</td>
|
|
<td>a3733bf495c05653e86ef20a825c62cb</td>
|
|
</tr>
|
|
<tr>
|
|
<td>http://www.w3.org/XML/1998/namespace</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/xml.xsd">xml.xsd</link>
|
|
</td>
|
|
<td>4726</td>
|
|
<td>2e2cf9072dc058dcda41b7ee77a5cb54</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:client</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jabber-client.xsd">jabber-client.xsd</link>
|
|
</td>
|
|
<td>6968</td>
|
|
<td>5e2d5cbf0506e3f16336d295093d66c4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:component:accept</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/component-accept.xsd">component-accept.xsd</link>
|
|
</td>
|
|
<td>6635</td>
|
|
<td>eb052d6aadc60e4a704728e68e9b71b4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:component:connect</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/component-connect.xsd">component-connect.xsd</link>
|
|
</td>
|
|
<td>6637</td>
|
|
<td>74497cf7c9a306fdbd3c336d471dba87</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:auth</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-auth.xsd">iq-auth.xsd</link>
|
|
</td>
|
|
<td>1075</td>
|
|
<td>524d617af8f30feae26b92cd83a21d7f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:gateway</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-gateway.xsd">iq-gateway.xsd</link>
|
|
</td>
|
|
<td>766</td>
|
|
<td>736df8b8976add34b6065512dad8352f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:last</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-last.xsd">iq-last.xsd</link>
|
|
</td>
|
|
<td>700</td>
|
|
<td>93a08299e6a987209704502256b21721</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:oob</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-oob.xsd">iq-oob.xsd</link>
|
|
</td>
|
|
<td>739</td>
|
|
<td>556fa1cd4d36ae1780ed2e0c1053c296</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:pass</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-pass.xsd">iq-pass.xsd</link>
|
|
</td>
|
|
<td>1274</td>
|
|
<td>4cf2bab840ce9d592f573db2d1dde1ef</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:privacy</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-privacy.xsd">iq-privacy.xsd</link>
|
|
</td>
|
|
<td>3116</td>
|
|
<td>1dfec6d0dbd1f625f46fb3f68c188338</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:private</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-private.xsd">iq-private.xsd</link>
|
|
</td>
|
|
<td>605</td>
|
|
<td>b8d0aebb2370a2f8658304ba57677623</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:register</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-register.xsd">iq-register.xsd</link>
|
|
</td>
|
|
<td>2598</td>
|
|
<td>b79db0064b527f0da817e90333896eac</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:roster</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/roster.xsd">roster.xsd</link>
|
|
</td>
|
|
<td>1898</td>
|
|
<td>936bbba0ef836bc173735c3b416ff553</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:rpc</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jabber-rpc.xsd">jabber-rpc.xsd</link>
|
|
</td>
|
|
<td>4853</td>
|
|
<td>351909f64a5a6b66c35972a53d498e88</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:search</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-search.xsd">iq-search.xsd</link>
|
|
</td>
|
|
<td>1574</td>
|
|
<td>1f202602ae9b46d43a6e5791d8c54d93</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:time</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-time.xsd">iq-time.xsd</link>
|
|
</td>
|
|
<td>933</td>
|
|
<td>dde555d546b4f460ba3abb9848acc2aa</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:iq:version</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/iq-version.xsd">iq-version.xsd</link>
|
|
</td>
|
|
<td>763</td>
|
|
<td>22a89a8dcf2fb54710b534b85333f5a7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:server</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jabber-server.xsd">jabber-server.xsd</link>
|
|
</td>
|
|
<td>6948</td>
|
|
<td>dd95bd3055dfdd69984ed427cd6356e0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:server:dialback</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/dialback.xsd">dialback.xsd</link>
|
|
</td>
|
|
<td>1606</td>
|
|
<td>ddb71d38501ceea6dbf04b96aeabd6fc</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:conference</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-conference.xsd">x-conference.xsd</link>
|
|
</td>
|
|
<td>1339</td>
|
|
<td>d06113e71790a8b4f92fe38d0e76dda6</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:data</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-data.xsd">x-data.xsd</link>
|
|
</td>
|
|
<td>3562</td>
|
|
<td>ed9ac8c241c7f6503887c86b3d9ef2f1</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:delay</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-delay.xsd">x-delay.xsd</link>
|
|
</td>
|
|
<td>940</td>
|
|
<td>60cbc644095747e5f5e987845ce3a233</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:encrypted</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-encrypted.xsd">x-encrypted.xsd</link>
|
|
</td>
|
|
<td>469</td>
|
|
<td>95816171d561dad6d412112bb698aed4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:event</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-event.xsd">x-event.xsd</link>
|
|
</td>
|
|
<td>1013</td>
|
|
<td>305f4bef3c118b9d3d11d96aea753026</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:expire</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-expire.xsd">x-expire.xsd</link>
|
|
</td>
|
|
<td>916</td>
|
|
<td>2c4f88b96a5ba140532788ca47c6216e</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:oob</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-oob.xsd">x-oob.xsd</link>
|
|
</td>
|
|
<td>668</td>
|
|
<td>d85e431c630889f65e3139d947be1cca</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:roster</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-roster.xsd">x-roster.xsd</link>
|
|
</td>
|
|
<td>1077</td>
|
|
<td>00cb233dee83919067559c5dcee04f3d</td>
|
|
</tr>
|
|
<tr>
|
|
<td>jabber:x:signed</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/x-signed.xsd">x-signed.xsd</link>
|
|
</td>
|
|
<td>463</td>
|
|
<td>979b382c4f4b0d9278f184f078e291c3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>roster:delimiter</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/delimiter.xsd">delimiter.xsd</link>
|
|
</td>
|
|
<td>435</td>
|
|
<td>aa7d17ef59561634d78a5c3acf0cc23c</td>
|
|
</tr>
|
|
<tr>
|
|
<td>storage:bookmarks</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/bookmarks.xsd">bookmarks.xsd</link>
|
|
</td>
|
|
<td>1588</td>
|
|
<td>a500b821a46a4dece20671abe259c4fd</td>
|
|
</tr>
|
|
<tr>
|
|
<td>storage:rosternotes</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/rosternotes.xsd">rosternotes.xsd</link>
|
|
</td>
|
|
<td>1045</td>
|
|
<td>2d5a4c3e97af7650a941b74473b18903</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-bind</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/bind.xsd">bind.xsd</link>
|
|
</td>
|
|
<td>852</td>
|
|
<td>ef4bc7405e969b05e1df4c0f8fbb5e71</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-e2e</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/e2e.xsd">e2e.xsd</link>
|
|
</td>
|
|
<td>598</td>
|
|
<td>da2132f0a69fc389685a7c8fe7f66e92</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-sasl</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sasl.xsd">sasl.xsd</link>
|
|
</td>
|
|
<td>2769</td>
|
|
<td>fd9a83f5c75628486ce18c0eb3a35995</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-session</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/session.xsd">session.xsd</link>
|
|
</td>
|
|
<td>444</td>
|
|
<td>cc1dad32ba05d18407579b7a1c98c64b</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/stanzaerror.xsd">stanzaerror.xsd</link>
|
|
</td>
|
|
<td>3133</td>
|
|
<td>1a8d21588424f9134dc497de64b10c3f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-streams</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/streamerror.xsd">streamerror.xsd</link>
|
|
</td>
|
|
<td>3315</td>
|
|
<td>75cd95aecb9f1fd66110c3ddcf00c9b8</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:ietf:params:xml:ns:xmpp-tls</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/tls.xsd">tls.xsd</link>
|
|
</td>
|
|
<td>688</td>
|
|
<td>dc18bc4da35bc1be7a6c52aa43330825</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:archive</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/archive.xsd">archive.xsd</link>
|
|
</td>
|
|
<td>10355</td>
|
|
<td>379f31dbd639e577cc3671989f89eac7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:attention:0</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/attention.xsd">attention.xsd</link>
|
|
</td>
|
|
<td>621</td>
|
|
<td>42f9232182d298aa92f29d300d4087c5</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:avatar:data</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/avatar-data.xsd">avatar-data.xsd</link>
|
|
</td>
|
|
<td>482</td>
|
|
<td>d705ada4740d78c5d404f470e61ea06c</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:avatar:metadata</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/avatar-metadata.xsd">avatar-metadata.xsd</link>
|
|
</td>
|
|
<td>1782</td>
|
|
<td>d8cb3ff5805145161c81f73dc4f1d5dc</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:blocking</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/blocking.xsd">blocking.xsd</link>
|
|
</td>
|
|
<td>1437</td>
|
|
<td>f9540f863f741e300e4706c8f773d02d</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:blocking:errors</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/blocking-errors.xsd">blocking-errors.xsd</link>
|
|
</td>
|
|
<td>627</td>
|
|
<td>28eb443b113cbe7147cfed90834a68fd</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:bob</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/bob.xsd">bob.xsd</link>
|
|
</td>
|
|
<td>846</td>
|
|
<td>990e71ba1e657f3a587cd6f0e758c69b</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:captcha</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/captcha.xsd">captcha.xsd</link>
|
|
</td>
|
|
<td>752</td>
|
|
<td>2128162d221b39d19530769ccdedd01b</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:delay</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/delay.xsd">delay.xsd</link>
|
|
</td>
|
|
<td>762</td>
|
|
<td>34283385814c8db0dc3ad874ae57e9ab</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:eventlog</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/eventlogging.xsd">eventlogging.xsd</link>
|
|
</td>
|
|
<td>2021</td>
|
|
<td>b12ff6b4b79b1dedd7c0f6721a046fb8</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:features:rosterver</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/versioning-feature.xsd">versioning-feature.xsd</link>
|
|
</td>
|
|
<td>619</td>
|
|
<td>089d67a345ba701d21c1d3316a03c7e6</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:http</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/http-over-xmpp.xsd">http-over-xmpp.xsd</link>
|
|
</td>
|
|
<td>5135</td>
|
|
<td>51c68b927a5cc0ab4a6e8d081e100cb0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:iot:concentrators</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sensor-network-concentrators.xsd">sensor-network-concentrators.xsd</link>
|
|
</td>
|
|
<td>37801</td>
|
|
<td>0ea1b43d143b7857870e1397c93e6872</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:iot:control</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sensor-network-control.xsd">sensor-network-control.xsd</link>
|
|
</td>
|
|
<td>6293</td>
|
|
<td>74dcea52300e8c8df8c4de2c9e90495b</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:iot:interoperability</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/xep-0000-IoT-Interoperability.xsd">xep-0000-IoT-Interoperability.xsd</link>
|
|
</td>
|
|
<td>1275</td>
|
|
<td>5d39845a0082715ff8807691698353bb</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:iot:provisioning</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sensor-network-provisioning.xsd">sensor-network-provisioning.xsd</link>
|
|
</td>
|
|
<td>8856</td>
|
|
<td>3ed5360bc17eadb2a8949498c9af3f0c</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:iot:sensordata</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sensor-data.xsd">sensor-data.xsd</link>
|
|
</td>
|
|
<td>8752</td>
|
|
<td>49b101e7deea39ccc31340a3c7871c43</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle.xsd">jingle.xsd</link>
|
|
</td>
|
|
<td>4926</td>
|
|
<td>29d29c6f994ce1b1cc3d5da8c1b54d80</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:apps:rtp:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-apps-rtp.xsd">jingle-apps-rtp.xsd</link>
|
|
</td>
|
|
<td>3481</td>
|
|
<td>3f1d6e7fc12ebddd3c196fb44dc0912b</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:apps:rtp:errors:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-apps-rtp-errors.xsd">jingle-apps-rtp-errors.xsd</link>
|
|
</td>
|
|
<td>705</td>
|
|
<td>bb476ac38da026742ddb94862f8d3e1f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:apps:rtp:info:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-apps-rtp-info.xsd">jingle-apps-rtp-info.xsd</link>
|
|
</td>
|
|
<td>1467</td>
|
|
<td>c8fc00ddcff8c69cf4a923c3797a9d04</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:apps:rtp:zrtp:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-apps-rtp-zrtp.xsd">jingle-apps-rtp-zrtp.xsd</link>
|
|
</td>
|
|
<td>732</td>
|
|
<td>9144b780fc33098ad0c5725394d53e8e</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:errors:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-errors.xsd">jingle-errors.xsd</link>
|
|
</td>
|
|
<td>783</td>
|
|
<td>fa8cefea805ce412615a0e19fcc90f29</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:transports:ibb:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-transports-ibb.xsd">jingle-transports-ibb.xsd</link>
|
|
</td>
|
|
<td>1424</td>
|
|
<td>284b6271054657577a380c654f90453f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:transports:ice-udp:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-transports-ice-udp.xsd">jingle-transports-ice-udp.xsd</link>
|
|
</td>
|
|
<td>3103</td>
|
|
<td>03a3be93d48a393e5756717d74b27efc</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:transports:raw-udp:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-transports-raw-udp.xsd">jingle-transports-raw-udp.xsd</link>
|
|
</td>
|
|
<td>1826</td>
|
|
<td>54ab91e95e7d070a26b1b6afbd5559ca</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:jingle:transports:s5b:1</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/jingle-transports-s5b.xsd">jingle-transports-s5b.xsd</link>
|
|
</td>
|
|
<td>3336</td>
|
|
<td>fe5cb4f3077307279a7c0e5da7c5c6e7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:langtrans</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/langtrans.xsd">langtrans.xsd</link>
|
|
</td>
|
|
<td>1934</td>
|
|
<td>42fd5d84bfdab64d405146500833ff95</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:langtrans:items</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/langtrans-items.xsd">langtrans-items.xsd</link>
|
|
</td>
|
|
<td>1500</td>
|
|
<td>c28ef67fe38aeaed5ba44e239c1c1886</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:media-element</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/media-element.xsd">media-element.xsd</link>
|
|
</td>
|
|
<td>1051</td>
|
|
<td>0d4c292aa81f6eb1ad3f8b06421e1cee</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:pie:0</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/pie.xsd">pie.xsd</link>
|
|
</td>
|
|
<td>1590</td>
|
|
<td>a1a80b05609760cc0bf73c81c48a8ab6</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:ping</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/ping.xsd">ping.xsd</link>
|
|
</td>
|
|
<td>602</td>
|
|
<td>a2a720f5ee6da310e3a05ba89b89eb20</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:receipts</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/receipts.xsd">receipts.xsd</link>
|
|
</td>
|
|
<td>879</td>
|
|
<td>e11be9d296fa183a1c06ea021fd69559</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:sec-label:0</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sec-label.xsd">sec-label.xsd</link>
|
|
</td>
|
|
<td>3865</td>
|
|
<td>9e98b80af0f6376c24a678d14a9a642f</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:sec-label:catalog:2</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sec-label-catalog.xsd">sec-label-catalog.xsd</link>
|
|
</td>
|
|
<td>3378</td>
|
|
<td>f63f39aaacb09726ceabf6638008b13a</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:sec-label:ess:0</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sec-label-ess.xsd">sec-label-ess.xsd</link>
|
|
</td>
|
|
<td>804</td>
|
|
<td>99311ef62e7f29be25eb78d68baaff2a</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:sm:3</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/sm.xsd">sm.xsd</link>
|
|
</td>
|
|
<td>3583</td>
|
|
<td>392326992f88327d9958fb6afbbb4382</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:time</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/time.xsd">time.xsd</link>
|
|
</td>
|
|
<td>658</td>
|
|
<td>001c5347c00da7aad231504ec706fbb3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:xbosh</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/xbosh.xsd">xbosh.xsd</link>
|
|
</td>
|
|
<td>760</td>
|
|
<td>0920ea082f0ba162c8b96611368941a8</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:xdata:color</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/color-parameter.xsd">color-parameter.xsd</link>
|
|
</td>
|
|
<td>522</td>
|
|
<td>6b58fcba235d4f8888b5f6db0e5dfc91</td>
|
|
</tr>
|
|
<tr>
|
|
<td>urn:xmpp:xdata:dynamic</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/dynamic-forms.xsd">dynamic-forms.xsd</link>
|
|
</td>
|
|
<td>2453</td>
|
|
<td>32d8760506fd010f8c9fa6e4953ed5bc</td>
|
|
</tr>
|
|
<tr>
|
|
<td>vcard-temp:x:update</td>
|
|
<td>
|
|
<link url="http://xmpp.org/schemas/vcard-avatar.xsd">vcard-avatar.xsd</link>
|
|
</td>
|
|
<td>625</td>
|
|
<td>edaf52356eb306390849641bdc33fdc9</td>
|
|
</tr>
|
|
</table>
|
|
</section2>
|
|
<section2 topic="Known problems with existing schemas" anchor="knownproblems">
|
|
<p>
|
|
The following sections list some known problems that might affect already defined schemas. For these schemas to be used
|
|
together with EXI compression, the recommended procedures should be considered. If changes to the schema is required,
|
|
new byte sizes and hash values must be computed for the changed schema correspondingly.
|
|
</p>
|
|
<p>
|
|
Patched version of XML schemas may be placed in the <link url="#wellknown">snapshot repository for well-known schemas</link> to avoid wild patches (and too many derived schema for the same model).
|
|
</p>
|
|
<section3 topic="Patch to avoid UPA for streams.xsd" anchor="patch">
|
|
<!-- [YD] -->
|
|
<p>
|
|
TBD: group discussion needed
|
|
</p>
|
|
<p>
|
|
streams.xsd defined in RFC6120 has 'unique particle attribution (UPA)' problem.
|
|
UPA is undeterministic attribution of an element between a wildcard and an explicit definition.
|
|
Details could be found in <link url="http://www.w3.org/TR/xmlschema-1/#non-ambig">Appendix H</link> of XML schema specification.
|
|
</p>
|
|
<p>
|
|
A simple
|
|
way to solve UPA is to insert delimiters around wildcards to eliminate
|
|
ambiguity. A deterministic delimiter can resolve ambiguity.
|
|
The other way to solve UPA is to use 'weak wildcard model'
|
|
introduced in XML schema 1.1. The cause of ambiguity is lack of
|
|
precedence between explicit definitions and wildcard definitions. As
|
|
weak wildcards have weaker precedence against explicit definitions,
|
|
there are no ambiguity with UPA.
|
|
</p>
|
|
<p>
|
|
To keep the same semantics with current XML implementations, by
|
|
default this proposal recommends weak wildcard model on
|
|
implementations. However, if an implementation does not support weak
|
|
wildcards, it may use streams.xsd with following patch applied.
|
|
</p>
|
|
<!-- TODO: Something seems to have happened to the indentation.
|
|
Example should be formatted better, put within <example> and CDATA elements, so it does not get destroyed by automatic indentation and XML formatting. -->
|
|
<code>
|
|
--- streams.xsd 2013-03-25 17:37:52.733451313 +0900
|
|
+++ streams-UPA-patched.xsd 2013-03-25 17:57:44.889469868 +0900
|
|
@@ -32,10 +32,12 @@
|
|
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl'
|
|
minOccurs='0'
|
|
maxOccurs='1'/>
|
|
+ <xs:element name="delim" type="xs:boolean" minOccurs="1" maxOccurs="1" />
|
|
<xs:any namespace='##other'
|
|
minOccurs='0'
|
|
maxOccurs='unbounded'
|
|
processContents='lax'/>
|
|
+ <xs:element name="delim" type="xs:boolean" minOccurs="1" maxOccurs="1" />
|
|
<xs:choice minOccurs='0' maxOccurs='1'>
|
|
<xs:choice minOccurs='0' maxOccurs='unbounded'>
|
|
<xs:element ref='client:message'/>
|
|
@@ -77,6 +79,7 @@
|
|
<xs:element ref='err:text'
|
|
minOccurs='0'
|
|
maxOccurs='1'/>
|
|
+ <xs:element name="delim" type="xs:boolean" minOccurs="1" maxOccurs="1" />
|
|
<xs:any namespace='##other'
|
|
minOccurs='0'
|
|
maxOccurs='1'
|
|
</code>
|
|
</section3>
|
|
<section3 topic="Patch for missing wildcards in extensible schemas">
|
|
<!-- [PW]: Example missing wildcard definition in data forms, in relation to data form validation, data form layout, etc. -->
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="Default schema for alternative bindings" anchor="defaultSchema">
|
|
<p>
|
|
Default EXI grammar used in EXI/XMPP SHALL be equivalent to the EXI grammar defined by the following schema. The default EXI grammar
|
|
is used in initiating connection of EXI/XMPP alternate binding. The default schema is defined by following definition, and all
|
|
the imported schemas SHOULD be same schemas described in <link url="#wellknown">the snapshot</link> and SHOULD have the identical
|
|
MD5 hash value described in <link url="#knownhashes">this section</link>.
|
|
</p>
|
|
<code>
|
|
<![CDATA[
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:stream="http://etherx.jabber.org/streams"
|
|
targetNamespace="urn:xmpp:exi:cs"
|
|
elementFormDefault="qualified">
|
|
<xs:import namespace="http://etherx.jabber.org/streams"
|
|
schemaLocation="${snapshot_url}/streams.xsd" />
|
|
<xs:import namespace="http://jabber.org/protocol/compress/exi"
|
|
schemaLocation="${snapshot_url}/xep-0322-01.xsd" />
|
|
</xs:schema>
|
|
]]>
|
|
</code>
|
|
<p>
|
|
The ${snapshot-url} corresponds to yet-to-be-specified schema snapshot repository described in <link url="#wellknown">snapshot repository for well-known schemas</link> section.
|
|
The schemaId of this schema will is 'urn:xmpp:exi:default'. SchemaId is ID for this instance and not a namespace identifier and intentionally different from the target namespace of the schema.
|
|
</p>
|
|
</section2>
|
|
<section2 topic="Reserved Schema IDs" anchor="reservedSchemaID">
|
|
<!-- [YD] required for alternative bindings -->
|
|
<p>Following schema Ids are reserved.</p>
|
|
<ul>
|
|
<li>
|
|
Schema IDs starts with "c:". This is used as <link url="#shortcutaltBind">shortcut setup for alternative transport binding</link>.
|
|
</li>
|
|
<li>Schema IDs starts with "urn:xmpp". This may be used to describe XEP-based schemas.</li>
|
|
</ul>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
Note that EXI compressed information, even though it is hard to decode by humans, is by no means encrypted. If sensitive data is to be sent over an EXI compressed
|
|
channel, encryption should be considered as well.
|
|
</p>
|
|
<p>
|
|
The reason for using MD5 as a hashing mechanism to identify schema versions, is because MD5 has a small memory footprint and is easy to implement.
|
|
However, it has a weakness: Given a hash value, it's relatively easy to create another file returning the same hash value. However, it's very
|
|
difficult to create another file of the same size as the original, resulting in the same hash value. For this reason, file sizes are also included
|
|
when identifying a schema. Since the security threat, and any possible consequences of somebody trying to inject invalid schemas to a server is
|
|
relatively small, this is considered a sufficient protection against such threats.
|
|
</p>
|
|
<p>
|
|
The feature of uploading and downloading new schemas to the server is a feature that the server can disable for exceptional high security reasons, for instance,
|
|
in high-security installations where total control of the domain is necessary. Clients should be aware
|
|
if this fact and check setup after uploading or asking the server to download new schemas. If the setup fails a second time, i.e. schemas are still missing,
|
|
the client MUST NOT try to upload or download the missing schemas again, since this would provoke an indefinite loop.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>
|
|
<!-- [YD] static port number is optional -->
|
|
This XEP requires new service names (proposed 'xmpp-bclient' and 'xmpp-bserver') for SRV records registered in IANA.
|
|
A static port number for a dedicated binary EXI/XMPP binding may also be requested.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>
|
|
Some of schemas should be kept 'as-is' format in XSF registry. EXI interoperability
|
|
requires schema stability, so a snapshot repository of version-controlled well-known schemas is requested to XMPP Registrar.
|
|
Related discussion is in <link url="#wellknown">here</link>. Also, patched versions such as described in <link url="#knownproblems">Known problems</link>
|
|
should be placed in the same snapshot repository.
|
|
</p>
|
|
<p>
|
|
Furthermore, it is suggested that the table at <link url="http://xmpp.org/resources/schemas/">http://xmpp.org/resources/schemas/</link> is updated
|
|
with two columns containing updated byte size and MD5 hash information for the current files. Tools can be provided by the authors to automate
|
|
the extraction of byte size and MD5 Hash information from the collection of schema files and transform them to appropriate formats.
|
|
</p>
|
|
<p>
|
|
The <link url="#schema">protocol schema</link> needs to be added to the list of <link url="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
|
|
</p>
|
|
<p>
|
|
The target namespace for canonical schemas <strong>urn:xmpp:exi:cs</strong>, for default schemas <strong>urn:xmpp:exi:default</strong>, as well as the EXI compress schema namespace
|
|
<strong>http://jabber.org/protocol/compress/exi</strong> need to be registered on the list of known XSF schemas.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<code>
|
|
<!-- IMPORT_AS_CDATA: ./exi.xsd -->
|
|
<![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='http://jabber.org/protocol/compress/exi'
|
|
xmlns='http://jabber.org/protocol/compress/exi'
|
|
xmlns:xml="http://www.w3.org/XML/1998/namespace"
|
|
xmlns:client='jabber:client'
|
|
xmlns:streams='http://etherx.jabber.org/streams'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
|
|
<xs:import namespace="http://etherx.jabber.org/streams"/>
|
|
|
|
<xs:element name='setup' type='Setup'/>
|
|
<xs:element name='setupResponse' type='SetupResponse'/>
|
|
|
|
<xs:complexType name='Setup'>
|
|
<xs:choice minOccurs='0' maxOccurs='unbounded'>
|
|
<xs:element name='schema' type='Schema'/>
|
|
<xs:element name='datatypeRepresentationMap' type='DatatypeRepresentationMap'/>
|
|
</xs:choice>
|
|
<xs:attributeGroup ref='Options'/>
|
|
<xs:attribute name='configurationId' type='xs:string' use='optional'/>
|
|
<xs:attribute name='configurationLocation' type='xs:string' use='optional'/>
|
|
</xs:complexType>
|
|
|
|
<xs:complexType name='SetupResponse'>
|
|
<xs:choice minOccurs='0' maxOccurs='unbounded'>
|
|
<xs:element name='schema' type='Schema'/>
|
|
<xs:element name='datatypeRepresentationMap' type='DatatypeRepresentationMap'/>
|
|
<xs:element name='missingSchema' type='Schema'/>
|
|
</xs:choice>
|
|
<xs:attributeGroup ref='Options'/>
|
|
<xs:attribute name='configurationId' type='xs:string' use='optional'/>
|
|
<xs:attribute name='configurationLocation' type='xs:string' use='optional'/>
|
|
<xs:attribute name='agreement' type='xs:boolean' use='optional' default='false'/>
|
|
</xs:complexType>
|
|
|
|
<xs:complexType name='Schema'>
|
|
<xs:attribute name='ns' type='xs:string' use='required'/>
|
|
<xs:attribute name='bytes' type='xs:positiveInteger' use='required'/>
|
|
<xs:attribute name='md5Hash' type='MD5Hash' use='required'/>
|
|
</xs:complexType>
|
|
|
|
<xs:complexType name='DatatypeRepresentationMap'>
|
|
<xs:attribute name='type' type='xs:string' use='required'/>
|
|
<xs:attribute name='representAs' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
|
|
<xs:attributeGroup name='Options'>
|
|
<xs:attribute name='version' type='xs:positiveInteger' use='optional' default='1'/>
|
|
<xs:attribute name='alignment' type='Alignment' use='optional' default='bit-packed'>
|
|
<xs:annotation>
|
|
<xs:documentation>The alignment option is used to control the alignment of event codes and content items. The value is one of bit-packed, byte-alignment or pre-compression, of which bit-packed is the default value assumed when the "alignment" element is absent in the EXI Options document. The option values byte-alignment and pre-compression are effected when "byte" and "pre-compress" elements are present in the EXI Options document, respectively. When the value of compression option is set to true, alignment of the EXI Body is governed by the rules specified in 9. EXI Compression instead of the alignment option value. The "alignment" element MUST NOT appear in an EXI options document when the "compression" element is present.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='compression' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>The compression option is a Boolean used to increase compactness using additional computational resources. The default value "false" is assumed when the "compression" element is absent in the EXI Options document whereas its presence denotes the value "true". When set to true, the event codes and associated content are compressed according to 9. EXI Compression regardless of the alignment option value. As mentioned above, the "compression" element MUST NOT appear in an EXI options document when the "alignment" element is present.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='strict' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>The strict option is a Boolean used to increase compactness by using a strict interpretation of the schemas and omitting preservation of certain items, such as comments, processing instructions and namespace prefixes. The default value "false" is assumed when the "strict" element is absent in the EXI Options document whereas its presence denotes the value "true". When set to true, those productions that have NS, CM, PI, ER, and SC terminal symbols are omitted from the EXI grammars, and schema-informed element and type grammars are restricted to only permit items declared in the schemas. A note in section 8.5.4.4.2 Adding Productions when Strict is True describes some additional restrictions consequential of the use of this option. The "strict" element MUST NOT appear in an EXI options document when one of "dtd", "prefixes", "comments", "pis" or "selfContained" element is present in the same options document.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='preserveComments' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>Comments are preserved. Must not be used together with the strict option.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='preservePIs' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>Processing instructions are preserved. Must not be used together with the strict option.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='preserveDTD' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>DTD is preserved. Must not be used together with the strict option.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='preservePrefixes' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>Prefixes are preserved. Must not be used together with the strict option.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='preserveLexical' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>Lexical form of element and attribute values can be preserved in value content items. Can be used together with the strict option.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='selfContained' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>The selfContained option is a Boolean used to enable the use of self-contained elements in the EXI stream. Self-contained elements may be read independently from the rest of the EXI body, allowing them to be indexed for random access. The "selfContained" element MUST NOT appear in an EXI options document when one of "compression", "pre-compression" or "strict" elements are present in the same options document. The default value "false" is assumed when the "selfContained" element is absent from the EXI Options document whereas its presence denotes the value "true".</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='blockSize' type='xs:positiveInteger' use='optional' default='1000000'>
|
|
<xs:annotation>
|
|
<xs:documentation>The blockSize option specifies the block size used for EXI compression. When the "blockSize" element is absent in the EXI Options document, the default blocksize of 1,000,000 is used. The default blockSize is intentionally large but can be reduced for processing large documents on devices with limited memory.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='valueMaxLength' type='xs:positiveInteger' use='optional'>
|
|
<xs:annotation>
|
|
<xs:documentation>The valueMaxLength option specifies the maximum length of value content items to be considered for addition to the string table. The default value "unbounded" is assumed when the "valueMaxLength" element is absent in the EXI Options document.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='valuePartitionCapacity' type='xs:positiveInteger' use='optional'>
|
|
<xs:annotation>
|
|
<xs:documentation>The valuePartitionCapacity option specifies the maximum number of value content items in the string table at any given time. The default value "unbounded" is assumed when the "valuePartitionCapacity" element is absent in the EXI Options document. Section 7.3.3 Partitions Optimized for Frequent use of String Literals specifies the behavior of the string table when this capacity is reached.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
<xs:attribute name='sessionWideBuffers' type='xs:boolean' use='optional' default='false'>
|
|
<xs:annotation>
|
|
<xs:documentation>If set to true, all buffers, string tables, etc. will be maintained during the entire session. This may improve performance during time since strings
|
|
can be omitted in the compressed binary stream, but it might also in some cases degrade performance since more options are available in the tables, requiring more bits
|
|
to encode strings. The default value is false, meaning that buffers, string tables, etc., are cleared between each stanza.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:attribute>
|
|
</xs:attributeGroup>
|
|
|
|
<xs:simpleType name='MD5Hash'>
|
|
<xs:restriction base='xs:string'>
|
|
<xs:pattern value='[0-9a-f]{32}'/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
|
|
<xs:simpleType name='Alignment'>
|
|
<xs:restriction base='xs:string'>
|
|
<xs:enumeration value='bit-packed'>
|
|
<xs:annotation>
|
|
<xs:documentation>The alignment option value bit-packed indicates that the event codes and associated content are packed in bits without any padding in-between.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:enumeration>
|
|
<xs:enumeration value='byte-alignment'>
|
|
<xs:annotation>
|
|
<xs:documentation>The alignment option value byte-alignment indicates that the event codes and associated content are aligned on byte boundaries. While byte-alignment generally results in EXI streams of larger sizes compared with their bit-packed equivalents, byte-alignment may provide a help in some use cases that involve frequent copying of large arrays of scalar data directly out of the stream. It can also make it possible to work with data in-place and can make it easier to debug encoded data by allowing items on aligned boundaries to be easily located in the stream.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:enumeration>
|
|
<xs:enumeration value='pre-compression'>
|
|
<xs:annotation>
|
|
<xs:documentation>The alignment option value pre-compression indicates that all steps involved in compression (see section 9. EXI Compression) are to be done with the exception of the final step of applying the DEFLATE algorithm. The primary use case of pre-compression is to avoid a duplicate compression step when compression capability is built into the transport protocol. In this case, pre-compression just prepares the stream for later compression.</xs:documentation>
|
|
</xs:annotation>
|
|
</xs:enumeration>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
|
|
<xs:element name='uploadSchema'>
|
|
<xs:complexType>
|
|
<xs:simpleContent>
|
|
<xs:extension base='xs:base64Binary'>
|
|
<xs:attribute name='contentType' type='ContentType' use='optional' default='Text'/>
|
|
<xs:attribute name='bytes' type='xs:positiveInteger' use='optional'/>
|
|
<xs:attribute name='md5Hash' type='MD5Hash' use='optional'/>
|
|
</xs:extension>
|
|
</xs:simpleContent>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:simpleType name='ContentType'>
|
|
<xs:restriction base='xs:string'>
|
|
<xs:enumeration value='Text'/>
|
|
<xs:enumeration value='ExiBody'/>
|
|
<xs:enumeration value='ExiDocument'/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
|
|
<xs:element name='downloadSchema' type='DownloadSchema'/>
|
|
<xs:element name='downloadSchemaResponse' type='DownloadSchemaResponse'/>
|
|
|
|
<xs:complexType name='DownloadSchema'>
|
|
<xs:attribute name='url' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
|
|
<xs:complexType name='DownloadSchemaResponse'>
|
|
<xs:complexContent>
|
|
<xs:extension base='DownloadSchema'>
|
|
<xs:choice minOccurs='0' maxOccurs='1'>
|
|
<xs:element name='httpError'>
|
|
<xs:complexType>
|
|
<xs:attribute name='code' type='xs:positiveInteger' use='required'/>
|
|
<xs:attribute name='message' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
<xs:element name='invalidUrl'>
|
|
<xs:complexType>
|
|
<xs:attribute name='message' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
<xs:element name='timeout'>
|
|
<xs:complexType>
|
|
<xs:attribute name='message' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
<xs:element name='invalidContentType'>
|
|
<xs:complexType>
|
|
<xs:attribute name='contentTypeReturned' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
<xs:element name='error'>
|
|
<xs:complexType>
|
|
<xs:attribute name='message' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:choice>
|
|
<xs:attribute name='result' type='xs:boolean' use='required'/>
|
|
</xs:extension>
|
|
</xs:complexContent>
|
|
</xs:complexType>
|
|
|
|
<xs:element name='streamStart'>
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element name='xmlns' minOccurs='0' maxOccurs='unbounded'>
|
|
<xs:complexType>
|
|
<xs:attribute name='prefix' type='xs:string' use='required'/>
|
|
<xs:attribute name='namespace' type='xs:string' use='required'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
<xs:element ref='streams:features'
|
|
minOccurs='0'
|
|
maxOccurs='1'/>
|
|
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls'
|
|
minOccurs='0'
|
|
maxOccurs='1'/>
|
|
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl'
|
|
minOccurs='0'
|
|
maxOccurs='1'/>
|
|
<xs:element ref='streams:error' minOccurs='0' maxOccurs='1'/>
|
|
</xs:sequence>
|
|
<xs:attribute name='from' type='xs:string' use='optional'/>
|
|
<xs:attribute name='id' type='xs:string' use='optional'/>
|
|
<xs:attribute name='to' type='xs:string' use='optional'/>
|
|
<xs:attribute name='version' type='xs:decimal' use='optional'/>
|
|
<xs:attribute ref='xml:lang' use='optional'/>
|
|
<xs:anyAttribute namespace='##other' processContents='lax'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:element name='streamEnd'>
|
|
<xs:complexType/>
|
|
</xs:element>
|
|
|
|
</xs:schema>
|
|
]]>
|
|
</code>
|
|
</section1>
|
|
<section1 topic='For more information' anchor='moreinfo'>
|
|
<p>
|
|
For more information, please see the following resources:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
The <link url='http://wiki.xmpp.org/web/Tech_pages/SensorNetworks'>Sensor Network section of the XMPP Wiki</link> contains further information about the
|
|
use of the sensor network XEPs, links to implementations, discussions, etc.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The XEP's and related projects are also available on <link url='https://github.com/joachimlindborg/'>github</link>, thanks to Joachim Lindborg.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
A presentation giving an overview of all extensions related to Internet of Things can be found here:
|
|
<link url='http://prezi.com/esosntqhewhs/iot-xmpp/'>http://prezi.com/esosntqhewhs/iot-xmpp/</link>.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Acknowledgements' anchor='ack'>
|
|
<p>Thanks to Joachim Lindborg, Takuki Kamiya, Tina Beckman, Karin Forsell, Jeff Freund and Rumen Kyusakov for all valuable feedback.</p>
|
|
</section1>
|
|
</xep>
|
|
<!-- please keep this to inform YD's editor (Emacs) work aligned with Peter's indent style
|
|
Local Variables:
|
|
nxml-child-indent: 4
|
|
sgml-indent-step: 4
|
|
End:
|
|
-->
|