WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process.

The Efficient XML Interchange (EXI) Format [1] 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.

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:

Schemas to use.

EXI version number.

Data alignment (bit-packed, byte-alignment, pre-compression).

If EXI-compressed data should be further compressed using additional compression.

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.

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.

There are two ways to use EXI to make efficient XMPP communication. The first method describes how to activate EXI-compression using Stream Compression (XEP-0138) [2] (XEP-0138).
The second method describes an alternative binding. This method does not use Stream compression as defined in
XEP-0138, rather it allows clients to connect
to the server and start using EXI directly from the beginning.

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:

Support for EXI compression through the normal XMPP port is detected by the existence of the exi compression method in the features 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 exi:PORT compression method,
where PORT is replaced by the port number used. More information about this alternative method is available in the Alternative Bindings section.

Note: 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.

Following is a list of use cases displaying how the client can configure and activate EXI compression on the current binding.

Note: Schema files are identified using three properties: Its target namespace, its byte size and its
MD5 hash. The MD5 hash provides a way to detect small changes in the file, even if the byte size and namespace are the same.

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.

Note: Hash values and byte sizes of known schemas at the time of writing, can be found here.
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 known problems.

After receiving the request, the server responds with a setupResponse 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.

Schema files that the server does not have (based on namespace, byte size and MD5 hash) are marked with the missingSchema element instead of the
normal schema element.

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.

If the server lacks information about a schema file, it is specified in the response through the missingSchema 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.)

To upload a schema file, the client simply sends the schema file using an uploadSchema element, as follows:

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 target namespace, byte size and MD5 Hash from the sent schema file.

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.

Note the agreement 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 configurationId attribute. This Configuration ID can be used later to quicker enter into EXI compressed mode.

The uploadSchema command has an optional attribute called contentType 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:

Table 1: contentType values

Value

Description

Text

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.

ExiBody

The schema file is sent as an EXI compressed file, but only the body is sent. *

ExiDocument

The schema file is sent as an EXI compressed file. The entire file, including Exi header is provided. *

(*) 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.

Table 2: Default EXI options

Option

Default value

Version

1

alignment

bit-packed

compression

false

strict

false

fragment

false

preserve

all false, except preserve prefixes that must be true or schema negotation may fail.

selfContained

false

schemaId

The Schema of schemas: http://www.w3.org/2001/XMLSchema.xsd.

datatypeRepresentationMap

No map

blockSize

N/A

valueMaxLength

unbounded

valuePartitionCapacity

unbounded

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 uploadSchema
command using the bytes and md5Hash 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.

Note: 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 bytes and md5Hash 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.

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 configurationId 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:

Note: the quick configuration includes all accepted schemas and all EXI options agreed upon during the
session when the configuration ID was returned. The configurationId attribute MUST NOT be used together
with other option attributes or schema definitions in the setup request.

If the configuration is still available on the server, the server responds:

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 propose new compression parameters.

The server now has the necessary knowledge on how the EXI engine should be configured for the current session and it responds as follows:

Example 19. Compression accepted

<compressed xmlns='http://jabber.org/protocol/compress'/>

When the client receives acknowledgement that the compression method has been accepted, it restarts the stream, as explained in
XEP 0138, except that it must not resend the <stream>
start element sequence. Similarly, the client must not send a </stream> element when closing the session.
Instead, special streamStart and streamEnd elements are sent. More information
about that later.

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 streamStart and streamEnd elements
have to be sent, allowing for similar semantics on the EXI-compressed channel, as described in the following subsections.

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.

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 streamStart element. This element replaces the start stream tag normally sent.

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.

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.

(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)

(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 draft-doi-exi-messaging-requirement.

The client connects to srv.example.net. 15222 with TCP and the server accepts the connection.

The client sends out 'EXI Cookie' (e.g. '$EXI') and starts EXI stream with an EXI Header without any option document (implies default encoding parameters). It sends out EXI events corresponds to start tag of <stream:stream>. Following shows XML Equivalent and EXI events

If client needs TLS or SASL negotiation, it should be done at this step. As specified in Section 4.3.3 of RFC6120, both parties MUST not send events corresponds to </stream:stream> tag. (e.g. exi:streamEnd element)

If client needs to use different encoding option or schema than the default encoding options or the default schema, then the client shall start schema negotiation. The streams with alternate options/schemas SHOULD NOT have an EXI Options document to indicate the parameter is negotiated via previous XMPP stream.

For example, the client want to use MUC option (XEP-0045), the following communication will occur. First, client try to renegotiate XML schema used in the communication.

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.

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.

The client and the server may end the stream with exi:streamEnd tag anytime.

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.

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.

Note: this expects an XMPP server shall return some error in plain
XML if the server receives EXI.

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.

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.

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.

<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.

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.

</stream:stream> end tag must be converted to standalone <exi:streamEnd> element.

Following post-process must be applied to XML streams from EXI processors before giving the stream to XMPP process.

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.

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.

<exi:streamEnd> element must be converted to </stream:stream> end tag. The context created under the connection may be released.

There are many EXI options in EXI Format. Followings are brief description for use in XMPP.

The alignment option 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.

The compression option 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.

The strict option 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.

The preserve option 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.

The selfContained option 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.

The datatypeRepresentationMap option 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.

The blockSize option specifies the block size used for EXI compression. It has no effect if compression is not used.

The valueMaxLength option 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).

The valuePartitionCapacity option 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).

To control buffer and string table life time, this XEP adds a new option: sessionWideBuffers.
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.)

The option sessionWideBuffers 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.

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.

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).

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.

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 sessionWideBuffers, which is false by default, meaning buffers and string tables are cleared between
each stanza.

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.

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.

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.

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.

Note: 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.

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.

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.

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.

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.

Note that schema files have three keys: Target namespace, byte size and MD5 Hash. 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 lower case.

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.

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.

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.

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.

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.

Also note that binary forwarding is only possible if session-wide buffers are not used.

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.

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 Efficient XML Interchange (EXI) Format
also specifies the use of Schema IDs identifying the schema to use.

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 Canonical Schemas is described
in this section.

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.

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.

The target namespace of the canonical schema MUST be urn:xmpp:exi:cs.

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.

The configurationId attribute has a similar attribute called configurationLocation. 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.

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 agreement="true". 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 agreement="false".

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 agreement=false
response. Otherwise the semantics of the configurationLocation attribute is the same as for the configurationId
attribute, except it provide a mechism for static configurations, while the configurationId provides a mechanism for
dynamic configurations.

The format for these opton documents or locations is beyond the scope of this specification.

The format for these opton documents or locations is beyond the scope of this specification.

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.

Client can start configured stream with a exi:streamStart 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.

If the server accepts the configuration, the server SHOULD respond with a exi:streamStart 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.

If the server does not accept the configuration, the server SHALL respond with a exi:streamEnd element encoded in the default schema and the EXI header option SHOULD be empty.

The client can continue pre-configured stream if and only if it receives exi:streamStart element encoded in the configurationId with EXI option header that contains the identical schemaId. Otherwise, the client SHOULD start a new exi:streamStart 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).

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.

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 Appendix H of XML schema specification.

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.

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.

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 the snapshot and SHOULD have the identical
MD5 hash value described in this section.

The ${snapshot-url} corresponds to yet-to-be-specified schema snapshot repository described in snapshot repository for well-known schemas 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.

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.

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.

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.

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 here. Also, patched versions such as described in Known problems
should be placed in the same snapshot repository.

Furthermore, it is suggested that the table at http://xmpp.org/resources/schemas/ 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.

The target namespace for canonical schemas urn:xmpp:exi:cs, for default schemas urn:xmpp:exi:default, as well as the EXI compress schema namespace
http://jabber.org/protocol/compress/exi need to be registered on the list of known XSF schemas.

Appendix C: Legal Notices

Copyright

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".