[Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

Philipp Hancke fippo at goodadvice.pages.de
Mon Oct 20 14:42:59 UTC 2014


Am 08.10.2014 18:33, schrieb XMPP Extensions Editor:
> This message constitutes notice of a Last Call for comments on XEP-0322 (Efficient XML Interchange (EXI) Format).
>
> Abstract: This specification describes how EXI compression can be used in XMPP networks.
>
> URL: http://xmpp.org/extensions/xep-0322.html
>
> This Last Call begins today and shall end at the close of business on 2014-10-21.

Well, since there were so few responses...
my comments are based purely on spec review, not on implementation 
experience.

> Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

That depends on the definition of "XMPP protocol stack". It seems to 
solve problems in the usage of xmpp for IOT.

> 2. Does the specification solve the problem stated in the introduction and requirements?

I can't comment on that due to lack of experience in that area.

> 3. Do you plan to implement this specification in your code? If not, why not?

No, see above.

> 4. Do you have any security concerns related to this specification?

Yes. It seems to upload schemas from clients prior to authentication.

> 5. Is the specification accurate and clearly written?

I found a number of issues...

in section 2.2:
Example 1 is titled "Search Features". Should be "Stream Features".

 > <method>exi:54321</method>

I'd prefer not to shoehorn a 
port-to-connect-to-with-an-alternate-protocol into this. Besides, it 
seems that xs:NCName can't contain colons so this violates the XEP-0138 
schema.


In section 2.2.1:
 > Example 2. Invalid setup

So the flow is that EXI is offered in stream features and the client is 
magically supposed to know it can't use this particular compression 
method before negotiating it (which would be ok for this particular 
method)? I think this is against the way we usually use stream features.

I'd rather have it as follows:
<stream:features>
         <exi xmlns=somenamespace altport=54321/>
         <compression xmlns='http://jabber.org/features/compress'>
             list-of-mechanisms-not-including-exi
         </compression>
</stream:features>
Then, the client would do all the exi negotiation outlined in 2.2 and 
2.3 and do a stream restart after which exi is allowed as a compression 
mechanism.

In section 2.2.2:
 > Example 4. Unable to accommodate parameters

Does a setupResponse which contains a missingSchema prevent the client 
from activating the exi mechanism?

 > Example 5. Uploading schema file

There is no response?

 > Example 7. Agreement between client and server

Well, there is still a <missingSchema ns='urn:xmpp:iot:provisioning' 
bytes='6303' md5Hash='3ed5360bc17eadb2a8949498c9af3f0c'/>


 > Example 8. Downloading a new XML schema file on server

Shouldn't the client give the server a hint about the hash of the file?
Makes it easier for the server.

 > Example 10. HTTP Error

How about reusing SHIM or stanza errors? Even though technically those 
elements are not stanzas.

In 2.2.8
 > except that it must not resend the <stream> start element sequence.

Well, this reopens the stream in a way which is not shown in XEP-0138.

2.3
This should be aligned (as in: replaced with) to the new websocket 
framing in 
https://tools.ietf.org/html/draft-ietf-xmpp-websocket-10#section-3.3

2.3.1 streamStart
has an anchor http://xmpp.org/extensions/xep-0322.html#startStream which 
breaks the internal link in 2.2.8

In 2.4:
 > Example 26. XML equivalent of setup element (Client to Server)

If EXI configuration was a separate stream feature, could this be 
simplified?


In 2.4.1:
I am somewhat opposed to adding a new port and SRV record for S2S. We 
haven't done that for plain tls.
The use-case for clients may be big enough to allow this there, but it 
certainly isn't for s2s.

In 2.4.2:
 > 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

Sending the $EXI cookie without negotiation is a no-no imo.


 > 3.12 XMPP Schema files and their hash values

Should be moved to an appendix or the registrar considerations section?


 > 3.13.1 Patch to avoid UPA for streams.xsd

This seems like a matter for the IETF XMPP WG.
I don't recall it being raised there. This issue needs to be resolved 
before this can advance.

 > 3.13.2 Patch for missing wildcards in extensible schemas
section is empty.

In 3.14
 > The ${snapshot-url}
should be snapshot_url. This is also called (TBD-URL) in 3.9.

In 3.15
 > This is used as shortcut setup for alternative transport binding.
The link (to 3.11?) is broken.



More information about the Standards mailing list