Hello Takuki Thanks for your input.
I'm trying to see to which extent an ordering of enumeration or boolean options has any meaning. My first observation is that the default values of the options must be supported by the server. They could be seen as "easier". Furthermore, they are all "false". So "false" < "true" in this case. This could be generalized in a MUST-statement, that the XMPP Server must support the default values of all EXI options for the EXI versions it is supporting. Regarding the alignment attribute, it's more difficult to order something based on "difficulty", since the default value is "bit-packed", which is "harder" in a sense than byte aligned. Could this be resolved using a MUST-statement that the XMPP server must support all three alignments? Sincerely, Peter Waher From: Takuki Kamiya [mailto:[email protected]] Sent: den 18 mars 2013 16:03 To: Peter Waher Cc: FABLET Youenn ([email protected]); Joachim Lindborg; John Schneider; [email protected]; Peter Saint-Andre; [email protected]; Stephen Williams <[email protected]> ([email protected]); XMPP Standards; Yusuke DOI Subject: RE: Proposal for including EXI in XMPP Hi Peter, The updated text in section 3.2 looks good. Thanks for incorporating the change. Now, I have another aspect of the XEP that I am not very clear about. It is about section 2.3 Proposing compression parameters. Though I understand the described mechanics of parameter convergence, I wonder if there were things that could improve the mechanism further. For numeric parameters such as blockSize or valueMaxLength, each option value can be deterministically ordered. On the other hand, the order among values of options such as alignment option or lexical preservation option is subject to judgment. For those not-totally-ordered parameters at least, allowing for specifying ordered preference values (instead of a single value) may help the negotiation to succeed, avoiding unsuccessful marriages that could otherwise be successfully matched. Regards, taki From: Peter Waher [mailto:[email protected]] Sent: Friday, March 15, 2013 5:57 PM To: Takuki Kamiya Cc: FABLET Youenn ([email protected]<mailto:[email protected]>); Joachim Lindborg; John Schneider; [email protected]<mailto:[email protected]>; Peter Saint-Andre; [email protected]<mailto:[email protected]>; Stephen Williams <[email protected]<mailto:[email protected]>> ([email protected]<mailto:[email protected]>); XMPP Standards; Yusuke DOI Subject: RE: Proposal for including EXI in XMPP Hello Taki Thanks for your valuable input. You're of course correct, so I've corrected §3.2 accordingly. I've attached the latest version. Sincerely, Peter Waher From: Takuki Kamiya [mailto:[email protected]] Sent: den 15 mars 2013 21:26 To: Peter Waher Cc: FABLET Youenn ([email protected]<mailto:[email protected]>); Joachim Lindborg; John Schneider; [email protected]<mailto:[email protected]>; Peter Saint-Andre; [email protected]<mailto:[email protected]>; Stephen Williams <[email protected]<mailto:[email protected]>> ([email protected]<mailto:[email protected]>); XMPP Standards; Yusuke DOI Subject: RE: Proposal for including EXI in XMPP Hi Peter, Each EXI Body needs to always start with SD and ends with ED. SD is ethereal (i.e. zero-bit), so its presence is indiscernible. On the other hand, ED often carries bits (depending on EXI preservation settings in effect). Therefore, stripping EXI Body grammar of them would amount to an alteration to the EXI specification, which I think we should avoid. I suggest to adopt EXI body as a whole. Exerpted from the first paragraph of Section 3.2: > 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 Element (EE) 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. Assuming that each stanza is represented as an EXI body, it is the ED event (instead of EE) for which flush operation needs to occur. Regards, taki From: Peter Waher [mailto:[email protected]] Sent: Friday, March 15, 2013 8:00 AM To: Takuki Kamiya Cc: FABLET Youenn ([email protected]<mailto:[email protected]>); Joachim Lindborg; John Schneider; [email protected]<mailto:[email protected]>; Peter Saint-Andre; [email protected]<mailto:[email protected]>; Stephen Williams <[email protected]<mailto:[email protected]>> ([email protected]<mailto:[email protected]>); XMPP Standards; Yusuke DOI Subject: RE: Proposal for including EXI in XMPP Hello Takuki, Thank you for your valuable comments. I've rewritten §3.2 according to the ideas you presented. I also specify when the stream ends in the same section. Would this address your comments? I've attached the most recent revision. Sincerely, Peter Waher From: Takuki Kamiya [mailto:[email protected]] Sent: den 15 mars 2013 04:00 To: Peter Waher; [email protected]<mailto:[email protected]> Cc: Joachim Lindborg ([email protected]<mailto:[email protected]>) Subject: RE: Proposal for including EXI in XMPP Hi Peter, Thank you for sharing your XMPP work which already appear to have collated many relevant points in producing an excellent draft specification. Section 3.2 in the updated version of the document describes successive, back-to-back use of multiple EXI bodies. Since this usage is something EXI does not directly describe, you might want to make sure EXI bodies (except for the first EXI body which begins immediately after a EXI header) each start at a byte boundary by explicitly mentioning that is the case. Also, you may want to use the terminology "EXI body" explicitly in order to avoid each sequence of (SD ... ED) to be understood as an EXI document. EXI 1.0 requires string table content to be reset for each EXI document, which is in conflict with what I think you want to achieve. One thing that was not very clear to me was the way the recipient recognizes that there is no more EXI body following one. Is there going to be a stanza that represents it is the last one in the communication? Regards, taki From: Peter Waher [mailto:[email protected]] Sent: Wednesday, March 13, 2013 9:43 AM To: [email protected]<mailto:[email protected]> Cc: Joachim Lindborg ([email protected]<mailto:[email protected]>) Subject: Proposal for including EXI in XMPP Hello We have made a first draft of a proposal for incorporating EXI into XMPP networks. (See attached files.) Anybody with an interest in EXI & XMPP are welcome to join us in this effort, please contact us. Any comments, suggestions, etc., on the contents of these documents are warmly welcomed and appreciated. Sincerely, Peter Waher
