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
