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:Peter.Waher@clayster.com]
Sent: Friday, March 15, 2013 5:57 PM
To: Takuki Kamiya
Cc: FABLET Youenn (Youenn.Fablet@crf.canon.fr); Joachim Lindborg; John Schneider; mact-usa@att.net; Peter Saint-Andre; public-exi@w3.org; Stephen Williams <sdw@lig.net> (sdw@lig.net); 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:tkamiya@us.fujitsu.com]
Sent: den 15 mars 2013 21:26
To: Peter Waher
Cc: FABLET Youenn (Youenn.Fablet@crf.canon.fr<mailto:Youenn.Fablet@crf.canon.fr>); Joachim Lindborg; John Schneider; mact-usa@att.net<mailto:mact-usa@att.net>; Peter Saint-Andre; public-exi@w3.org<mailto:public-exi@w3.org>; Stephen Williams <sdw@lig.net<mailto:sdw@lig.net>> (sdw@lig.net<mailto:sdw@lig.net>); 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:Peter.Waher@clayster.com]
Sent: Friday, March 15, 2013 8:00 AM
To: Takuki Kamiya
Cc: FABLET Youenn (Youenn.Fablet@crf.canon.fr<mailto:Youenn.Fablet@crf.canon.fr>); Joachim Lindborg; John Schneider; mact-usa@att.net<mailto:mact-usa@att.net>; Peter Saint-Andre; public-exi@w3.org<mailto:public-exi@w3.org>; Stephen Williams <sdw@lig.net<mailto:sdw@lig.net>> (sdw@lig.net<mailto:sdw@lig.net>); 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:tkamiya@us.fujitsu.com]
Sent: den 15 mars 2013 04:00
To: Peter Waher; public-exi@w3.org<mailto:public-exi@w3.org>
Cc: Joachim Lindborg (joachim.lindborg@sust.se<mailto:joachim.lindborg@sust.se>)
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:Peter.Waher@clayster.com]
Sent: Wednesday, March 13, 2013 9:43 AM
To: public-exi@w3.org<mailto:public-exi@w3.org>
Cc: Joachim Lindborg (joachim.lindborg@sust.se<mailto:joachim.lindborg@sust.se>)
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