Dear Yusuke Thanks for your mail. Regarding your questions and comments:
> Ok, so I think I need to write another proposal. Would you mind if I re-use > the basic idea on 'EXI encoding part' of your proposal to make better > interoperability? By all means. It would be excellent if you did. It would allow devices to be able to connect freely between servers supporting either of the two versions. >> The proposal supports different EXI versions. It's part of the negotiation, >> using the version attribute. > >I see, then may I assume you have no intention to make 'yet another EXI for >XMPP' such as sessionWideBuffer option? I'm not sure what you mean with 'yet another EXI for XMPP'. Where do you find another proposal for EXI with option negotiation? Also, we plan to let the sessionWideBuffer to stand for the time being. I believe it's an important aspect of the integration of EXI into XMPP. And as I showed using my examples (which are in no ways extreme, they are in fact two common use cases in sensor networks) sometimes one option is better than the other. One option is not the best for all use cases. > In my (yet) shallow understandings, your approach to send a stanza looks like > following (correct me if I'm wrong) > > <stream> > <a-single-stanza/> > </stream> > (padding, fflush(), PSH) > <stream> > <a-single-stanza/> > </stream> > (again, padding, fflush(), PSH) > > For me, it looks different from the semantics of </stream> tag defined in > RFC6120 section 4.4: > > If the parties are using either two streams over a single TCP connection or > > two streams over two TCP connections, the entity that sends the closing > > stream tag MUST behave as follows: > > > > 1. Wait for the other party to also close its outbound stream before > > terminating the underlying TCP connection(s); this gives the other party an > > opportunity to finish transmitting any outbound data to the closing entity > > before the termination of the TCP > connection(s). > > 2. Refrain from sending any further data over its outbound stream to the > > other entity, but continue to process data received from the other entity > > (and, if necessary, process such data). > > 3. Consider both streams to be void if the other party does not send its > > closing stream tag within a reasonable amount of time (where the definition > > of "reasonable" is a matter of implementation or deployment). > > 4. After receiving a reciprocal closing stream tag from the other party > > or waiting a reasonable amount of time with no response, terminate the > > underlying TCP connection(s). Added a note in ยง2.7. regarding this, since it was unclear. <stream> is only written at the start of a stream, and </stream> when the stream is closed, with stanzas inbetween. When entering EXI-compressed mode, the <stream> and </stream> should be omitted. Sincerely, Peter Waher -----Original Message----- From: Yusuke DOI [mailto:[email protected]] Sent: den 19 mars 2013 05:07 To: Peter Waher Cc: Peter Saint-Andre; XMPP Standards; Joachim Lindborg ([email protected]); Takuki Kamiya ([email protected]) Subject: Re: EXI extension proposal Peter, (sorry for multiple mail, I did wanted to split technical details and requirement discussions) (2013/03/18 22:53), Peter Waher wrote: >> Stepping back to the requirements. For example, what I need is binary-only >> bootstrap mechanism for EXI (not like XEP-0138) with least >> negotiation/propose of compression parameter. Does your proposal cover such >> use case? > > No. This XEP covers EXI negotiation in a way compliant with XEP-0138. Ok, so I think I need to write another proposal. Would you mind if I re-use the basic idea on 'EXI encoding part' of your proposal to make better interoperability? >> Let me ask a question: which strategy are you taking? >> >> 1) short target: find a way to encode XMPP stanza with existing >> EXI format 1.0 >> 2) long target: find a way to encode XMPP stanza ideally with >> proposed currently-nonexistent ideal EXI 1.1 (or 2.0) > > The proposal supports different EXI versions. It's part of the negotiation, > using the version attribute. I see, then may I assume you have no intention to make 'yet another EXI for XMPP' such as sessionWideBuffer option? >> My concern on a-1 is about XML semantics. Does current server implementation >> okay to have modified XML-level structure? On the other hand, re-use of >> string table is possible only in a-3 (discussion below). > > Sorry, I don't understand your question. In my (yet) shallow understandings, your approach to send a stanza looks like following (correct me if I'm wrong) <stream> <a-single-stanza/> </stream> (padding, fflush(), PSH) <stream> <a-single-stanza/> </stream> (again, padding, fflush(), PSH) For me, it looks different from the semantics of </stream> tag defined in RFC6120 section 4.4: > If the parties are using either two streams over a single TCP connection or > two streams over two TCP connections, the entity that sends the closing > stream tag MUST behave as follows: > > 1. Wait for the other party to also close its outbound stream before > terminating the underlying TCP connection(s); this gives the other party an > opportunity to finish transmitting any outbound data to the closing entity > before the termination of the TCP connection(s). > 2. Refrain from sending any further data over its outbound stream to the > other entity, but continue to process data received from the other entity > (and, if necessary, process such data). > 3. Consider both streams to be void if the other party does not send its > closing stream tag within a reasonable amount of time (where the definition > of "reasonable" is a matter of implementation or deployment). > 4. After receiving a reciprocal closing stream tag from the other party or > waiting a reasonable amount of time with no response, terminate the > underlying TCP connection(s). >> For dynamic grammars, your proposal "reusing the same options as used by the >> stream" (section 3.2) may not be adequate, because this means all stanzas >> should be in the same schema and does not allow introduction of new schema >> on the fly. However, I agree a > constrained node seldom updates its >> functionality so fixed set of schema on C2S pair should be okay (for S2S >> communication it's not good). > > I don't see why this should require all stanzas to be in the same schema. > Schemas are handled by namespace, and a collection of schemas can be used in > compression. Which schema namespaces are to be included is part of the > negotiation. Sorry, I mean 'the set of schema given in the negotiation phase.' S2S connection may be required to re-negotiated if a new client connect to a server with schemas not included in the running S2S communication. Regards, Yusuke
