Formatting and XML fixes.
+Updated contact information.
-Updated example JIDs to example.org
+Updated example JIDs to example.org
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, @@ -214,41 +219,37 @@ 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 setup-failed response.
-When the client decides to activate EXI compression, it sends a setup stanza containing parameter proposals to the server as follows:
-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. @@ -267,26 +268,24 @@ 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. @@ -306,19 +305,17 @@
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. @@ -327,50 +324,46 @@ 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.
-And the server should then respond:
-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 @@ -475,10 +468,9 @@ 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 downloadSchema command, as follows:
-The server tries to download the schema by itself, and then computes the target namespace, byte size and MD5 Hash from the downloaded schema. @@ -486,55 +478,44 @@
When the schema has been downloaded, the following successful download response is returned:
-If an HTTP error occurred while trying to download the schema, a response as follows is returned:
-If the URL could not be resolved, the following response is returned:
-If a timeout occurred during the download attempt, the following response is returned:
-If the url points to something that is not a schema, the following response is returned:
-If an error occurs that is unforeseen by this specification, the server can simply respond with a generic error message, as follows:
-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 @@ -549,10 +530,9 @@ 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 @@ -561,10 +541,9 @@
If the configuration is still available on the server, the server responds:
-Note that schemas or options are not mentioned explicitly when using this quick setup approach.
@@ -574,10 +553,9 @@ 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: -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 @@ -589,19 +567,16 @@ 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 compress stanza, as follows:
-The server now has the necessary knowledge on how the EXI engine should be configured for the current session and it responds as follows:
-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> @@ -628,15 +603,15 @@
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 @@ -652,7 +627,7 @@
- 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. + 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.
In addition, local value learning mechanism is disabled by - default as described in section 4 of EXI Profile. + default as described in section 4 of EXI Profile.
In the example, the box XMPP is conventional XMPP process. [EXI] represents EXI processor (encoder and decoder). [Proc] means preprocessor and postprocessor. @@ -1366,7 +1340,7 @@ FIXME 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.
- Patched version of XML schemas may be placed in the snapshot repository for well-known schemas to avoid wild patches (and too many derived schema for the same model). + Patched version of XML schemas may be placed in the snapshot repository for well-known schemas to avoid wild patches (and too many derived schema for the same model).
- The ${snapshot-url} corresponds to yet-to-be-specified schema snapshot repository described in snapshot repository for well-known schemas 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.
Following schema Ids are reserved.