xeps/xep-0322.xml

2806 lines
138 KiB
XML
Raw Permalink Normal View History

2013-03-13 10:33:04 -04:00
<?xml version='1.0' encoding='UTF-8'?>
2013-04-16 15:45:45 -04:00
<!-- TODO: Add sequence diagrams. -->
2013-07-25 09:18:30 -04:00
<!-- TODO: Add schema for <message> and <iq>. -->
<!-- TODO: Intermittent connections and reconnection to previous EXI session, reutilizing options, string tables, etc. -->
2013-03-13 10:33:04 -04:00
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
2013-03-13 10:33:04 -04:00
]>
<?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>Deferred</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.6.0</version>
<date>2018-01-25</date>
<initials>XEP Editor (jwi)</initials>
<remark>Defer due to lack of activity.</remark>
</revision>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2013-03-13 10:33:04 -04:00
<p>
Added quick setup attributes: <strong>configurationId</strong>, <strong>configurationLocation</strong>.
2013-03-13 10:33:04 -04:00
</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 &lt;<link url='http://www.w3.org/TR/exi/'>http://www.w3.org/TR/exi/</link>&gt;.
</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'>
2014-10-08 12:26:56 -04:00
<!-- TODO: [YD] can we have a summary section to desribe the use case? a short proposal is as follows
2013-07-25 09:18:30 -04:00
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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<example caption='Invalid setup'><![CDATA[
<compress xmlns='http://jabber.org/protocol/compress'>
<method>exi</method>
</compress>
2014-10-08 12:26:56 -04:00
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<example caption='Uploading schema file'><![CDATA[
<uploadSchema xmlns='http://jabber.org/protocol/compress/exi' contentType='Text'>
PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4NCjx4czpzY2hlbWENCiAgICB4
bWxuczp4cz0naHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEnDQogICAgdGFyZ2V0TmFt
ZXNwYWNlPSd1cm46eG1wcDpzbjpwcm92aXNpb25pbmcnDQogICAgeG1sbnM9J3Vybjp4bXBwOnNu
2014-10-08 12:26:56 -04:00
2016-11-02 16:10:35 -04:00
2014-10-08 12:26:56 -04:00
2016-11-02 16:10:35 -04:00
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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>
2016-11-02 16:10:35 -04:00
<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>&lt;stream&gt;</strong>
start element sequence. Similarly, the client must not send a <strong>&lt;/stream&gt;</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 &lt;stream&gt; element,
and close the stream by sending a closing &lt;/stream&gt; 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[
2016-11-02 16:10:35 -04:00
<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 &lt;streams:stream&gt; 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[
2016-11-02 16:10:35 -04:00
<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 &lt;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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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 &lt;/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>
2016-11-02 16:10:35 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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>
2013-07-25 09:18:30 -04:00
<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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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[
2013-07-25 09:18:30 -04:00
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[
2013-07-25 09:18:30 -04:00
<?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>
2016-11-02 16:10:35 -04:00
]]>
</example>
<example caption="XML Equivalent of streamStart">
<!-- samples/C2S/010-base+muc-restart.xml -->
<![CDATA[
2013-07-25 09:18:30 -04:00
<?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>
2016-11-02 16:10:35 -04:00
]]>
</example>
<!--
2013-07-25 09:18:30 -04:00
<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>
2013-07-25 09:18:30 -04:00
<example caption="EXI Option Document used for Shortcut Setup (Server to Client)">
<!-- samples/quick-setup-header.xml -->
<![CDATA[
2013-07-25 09:18:30 -04:00
<?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>
2016-11-02 16:10:35 -04:00
]]>
</example>
<example caption="XML Equivalent of streamStart in response">
<!-- samples/S2C/010-base+muc-restart.xml -->
<![CDATA[
2013-07-25 09:18:30 -04:00
<?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>
<!--
2013-07-25 09:18:30 -04:00
<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[
2013-07-25 09:18:30 -04:00
<?xml version="1.0"?>
<streamEnd xmlns='http://jabber.org/protocol/compress/exi' />
2016-11-02 16:10:35 -04:00
]]>
</example>
<!--
2013-07-25 09:18:30 -04:00
<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 a