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