Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
Even though the EXI protocol is most likely to be used by IoT implementations, it is not really IoT-specific - it defines some core extensions to XMPP and therefore I would prefer to discuss it on the standards@ list. I agree that discussing the IoT-specific XEPs on the iot@ list is appropriate, and I will start posting reviews there soon. Peter On 1/6/17 11:07 AM, Peter Waher wrote: Hello Peter I'm travelling at the moment. Let's discuss this XEP in the IoT SIG, along the others, in turn. Best regards, Peter *Från:* Peter Saint-Andre <stpe...@stpeter.im> *Skickat:* den 6 januari 2017 17:00:29 *Till:* XMPP Standards *Kopia:* yusuke@toshiba.co.jp; Peter Waher *Ämne:* Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format) Old thread alert! On 10/8/14 10:33 AM, XMPP Extensions Editor wrote: 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. 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? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! I noticed substantive spec and security feedback in October 2014 from several list participants. However, as far as I can see, that feedback has not been addressed by the authors. As part of my review of all the IoT specs, I would like to provide feedback on XEP-0322, but it seems like wasted effort if the spec hasn't been updated since the previous last call. Yusuke & Peter, do you plan to update XEP-0322 or do you need a co-author to help finish this off? Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
Hello Peter I'm travelling at the moment. Let's discuss this XEP in the IoT SIG, along the others, in turn. Best regards, Peter Från: Peter Saint-Andre <stpe...@stpeter.im> Skickat: den 6 januari 2017 17:00:29 Till: XMPP Standards Kopia: yusuke@toshiba.co.jp; Peter Waher Ämne: Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format) Old thread alert! On 10/8/14 10:33 AM, XMPP Extensions Editor wrote: > 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. > > 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? > 2. Does the specification solve the problem stated in the introduction and > requirements? > 3. Do you plan to implement this specification in your code? If not, why not? > 4. Do you have any security concerns related to this specification? > 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! I noticed substantive spec and security feedback in October 2014 from several list participants. However, as far as I can see, that feedback has not been addressed by the authors. As part of my review of all the IoT specs, I would like to provide feedback on XEP-0322, but it seems like wasted effort if the spec hasn't been updated since the previous last call. Yusuke & Peter, do you plan to update XEP-0322 or do you need a co-author to help finish this off? Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
Hi, Following inline some feedback. While a little late I hope it’s still useful. On 08.10.2014, at 18:33, XMPP Extensions Editor edi...@xmpp.org wrote: 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? Yes. It aims to provide higher compression rations compared to general purpose compression like ZLib. 2. Does the specification solve the problem stated in the introduction and requirements? I hope so. I haven’t implemented it and the document itself doesn’t show how it compares to the currently available general purpose compression methods. Considering the constrained devices application scenario I would expect the compression ratios be as good if not better as general purpose compression and that the code required for this is as small in comparison as devices are not only constrained in battery energy but also in code storage size and processing power.. 3. Do you plan to implement this specification in your code? If not, why not? I currently don’t have plans to implement this protocol as my current XMPP usage scenarios don’t include extremely constrained devices, where implementing EXI would have a benefit justifying the work to implement it. 4. Do you have any security concerns related to this specification? I think using a more secure hash function would be beneficial for reducing code. Secure wireless constrained applications are likely to already include a high security cryptographic hash function. Using this hash function would avoid the need of implementing MD5 at all. Maybe, hash agility could also be useful in this case. So clients, I think this is the main deployment target for as constrained device, can pick the one already available. Servers which are likely to have more power can then simply use the same hash as the client. 5. Is the specification accurate and clearly written? As Philipp already mentioned, the negotiation of the port inside the stream features as dedicated compression methods seems quite strange. I haven’t read it in all detail but except for some typos it reads okay. Typo: Once an EXI setup has been accepted by the server, and agreement is reched, the… : “reched” - “reached” Cheers, Tobias
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
On 22 October 2014 09:57, Tobias Markmann tmarkm...@googlemail.com wrote: I think using a more secure hash function would be beneficial for reducing code. Secure wireless constrained applications are likely to already include a high security cryptographic hash function. Using this hash function would avoid the need of implementing MD5 at all. Maybe, hash agility could also be useful in this case. So clients, I think this is the main deployment target for as constrained device, can pick the one already available. Servers which are likely to have more power can then simply use the same hash as the client. I would think SHA-1 a better choice than MD5 at least. And clients will already need it for capabilities: http://xmpp.org/extensions/xep-0115.html#security-mti
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
On 10/22/14, 9:32 AM, Daurnimator wrote: On 22 October 2014 09:57, Tobias Markmann tmarkm...@googlemail.com mailto:tmarkm...@googlemail.com wrote: I think using a more secure hash function would be beneficial for reducing code. Secure wireless constrained applications are likely to already include a high security cryptographic hash function. Using this hash function would avoid the need of implementing MD5 at all. Maybe, hash agility could also be useful in this case. So clients, I think this is the main deployment target for as constrained device, can pick the one already available. Servers which are likely to have more power can then simply use the same hash as the client. I would think SHA-1 a better choice than MD5 at least. And clients will already need it for capabilities: http://xmpp.org/extensions/xep-0115.html#security-mti See also RFC 6151, which states that MD5 is no longer acceptable where collision resistance is required (such as in digital signatures). We can do better than MD5 these days. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
Sorry for late response... 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? I believe yes. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. IoT-related items can work very efficiently over the protocol. 3. Do you plan to implement this specification in your code? If not, why not? Partially yes. A student's open-sourced code (though, not fully-working yet) is on https://github.com/akari-h/nex 4. Do you have any security concerns related to this specification? I've not noticed at the point of writings. I'd read the comments carefully... 5. Is the specification accurate and clearly written? I welcome any comments. Yusuke
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
All, Please find below my comments to Last Call XEP-0322: Efficient XML Interchange (EXI) Format (Version: 0.4, Last Updated: 2014-03-10) in section order. Hope the feedback helps, -- Daniel # 2.2.3 Uploading new schema files I propose changing the MD5 hash calculation for schema files. The idea is to build the hash by means of Canonical XML (http://www.w3.org/TR/xml-c14n). Doing so helps to identify XML/XSD documents that are logically equivalent but vary in physical representation based on syntactic changes permitted by XML. Hence, irrelevant changes do not affect hash. # 2.2.4 Uploading compressed schema files Table 1: contentType values offers beside the Text contentType two more content types for EXI, namely ExiBody and ExiDocument. In the best case the difference is one byte (the first byte differs). I would recommend using ExiDocument only and remove ExiBody. The reason is not only the minimal 1 byte overhead but also that off-the-shelf EXI processors always expect an entire EXI document with the header instead of just the body. Note: Nevertheless, I think it is perfectly fine to assume the EXI options in Table 2. Also, with the previous comment (see Canonical XML) it should be also OK to generate md5Hash with the EXI- encoded schema. Note: Section 2.2.3 and 2.2.4 could be combined given that the latter also speaks about uncompressed schema files. General Note: Does it makes sense to use mime/media-types? # 2.2.5 Downloading new schema files on server Does it make sense to add an attribute that allows identifying whether a downloadable schema files is represented in XML or EXI. e.g., downloadSchema xmlns='http://jabber.org/protocol/compress/exi' contentType=ExiDocument url='http://schemavault.example.org/compress/sn/provisioning.xsd.exi'/ Backlink again to mime-type comment (http accept/response)? # 2.3 EXI-specific stream elements a) Typo: EXP-compressed XMPP stream ... EXP vs. EXI b) Strong similarity to websocket. Why not using the same tag names? framing ideas (one stanza per frame etc)? https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ General Note: Harmonize with websocket RFC... e.g. transport binding/communication setup c) Link to XEP-0045 is not correct. # 3.1 EXI Encoding Preprocessing and Postprocessing I wonder whether in the case of prefix recovering it is enough to use the prefix/NS declarations from the initial streamStart element? If so it could/should be mentioned. https://tools.ietf.org/html/rfc6120#section-4.8.5 Typo in the post-process steps .. Prefixies # 3.2 EXI options The new option sessionWideBuffers adds a new feature. Apart from string table to me it is not totally clear what is meant by all buffers. Hence, the term buffers should be defined: * I assume all String Tables (uris, prefixes, and values) * What about evolved EXI built-in grammars, expanded global element grammars etc. # 3.3 Transmission of EXI bodies and Session-wide Buffers Question 1: Can an EXI recipient be sure that an EXI stanza is sent at once? One packet? Question 2: Can an EXI recipient be sure that a packet contains exactly one stanza? My assumption w.r.t. pure XMPP results in a No for both questions. However, harmonizing it with Websocket (see comment Section 2.3) results in a Yes and would make it easier for the decoder to identify stanza boundaries. # 3.11 Using EXI Option Documents for Shortcut Setup Duplicated last paragraph The format for these opton documents or locations is beyond the scope of this specification. Typo: opton # General NOTE What about pre-defining some default configurationId's for some typical setups e.g., - schema-less coding (does not require any schema negotiation) - XML schema datatypes only coding (does not require any schema negotiation) - maybe some very typical core XMPP schemas Doing so allows a fast setup in many use cases. Does it that make sense to exludude a given range for such pre-defined combinations also? Von: Standards [standards-boun...@xmpp.org] im Auftrag von XMPP Extensions Editor [edi...@xmpp.org] Gesendet: Mittwoch, 8. Oktober 2014 18:33 An: standards@xmpp.org Betreff: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format) 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. 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? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
A short official feedback, Daniel also will be contributing more details and we have started direct discussions with the authors. 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. 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? To my opinion yes. The most critizied point on XMPP is always that used string-based XML representation is inefficient. EXI offers an efficient binary representation of the information while still enabling a 1:1 translation between textual XML and EXI. Apart from reducing the wire load, it also is far more efficient to serializeparse (due to binary structuring and native types and instead of string representations) Thus, it offers protocol enhancements for every application where performance bandwidth is an issue - and that is not just IoT. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement this specification in your code? If not, why not? We are aware of several efforts to implement the XEP and we are currently in discussions how to join them. 4. Do you have any security concerns related to this specification? None right now. 5. Is the specification accurate and clearly written? We support the comments on the mailing list. Best Regards, Johannes
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
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.
methodexi: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.
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08.10.2014 18:33, XMPP Extensions Editor wrote:
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.
Please consider the following questions during this Last Call and
send your feedback to the standards@xmpp.org discussion list:
5. Is the specification accurate and clearly written?
This is more are generic comment on how to deal with this then a EXI
specific one:
XEP-322 § 2.2.2 …it sends a setup stanza… but according to RFC 6120
§ 8 Three kinds of XML stanza are defined …: message/, presence/,
and iq/.
So a setup element is not a stanza. I suggest having stanza replaced
by stream element. There are maybe other wrong uses of stanza in
this XEP (and others).
I think what's missing is a term for XML elements that are not stanzas
but directly embedded into stream/. And a term for everything that
is directly embedded into stream/.
Smack currently refers to those as 'StreamElement' and
'PlainStreamElement', which forms the following hierarchy:
Stream Element
/ \
/ \
Stanza Plain Stream Element
('Packet' in Smack)
This hierarchy has proven to be useful in Smack, e.g. to differentiate
between stream elements that should handled by XEP-198 Stream Management.
But maybe I'm wrong, and the intention was to allow other stanza types
besides presence, message an iq. I hope that this isn't the case.
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQF8BAEBCgBmBQJUPOz/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMzU3QjAxODY1QjI1MDNDMTg0NTNEMjA4
Q0FDMkE5Njc4NTQ4RTM1AAoJEIysKpZ4VI41qDIIAKUcWXJK/Vg9/dwQW+d1P021
tixqmcEEeBsQT++9u2lRL+F52BVmCm8ngEmtOMHlW9cX0d4fqYQfWrnRweRMSjKh
Zjf2qJpGHqJQDnT45AjOMNAxsr5aAPaxSQ3vdB2BZo2XoKbdFaZai1zl73/DLCGi
Lkzu0vqeklBAsh+VNdRaRM1C287yVpPwSK21A+cn7MENQjDQAWRqrdqM02LV+3Er
R4z6YD+HX50zIVMX9q3VYbCTYxZfmBXUZE818ohlLoylsItdN4tMyB8RDgG5Lda+
yfVgmmaXLXm9fdOMvkxmdMBoKygTouJrFcv8xgfzEMNhIh7bybXl8enJyillA3E=
=AJPf
-END PGP SIGNATURE-
[Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
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. 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? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
