[Standards] XEP-0301 Fallback Mechanism of Determining Support (Accessibility)
markybox at gmail.com
Thu Jul 12 03:35:53 UTC 2012
On Wed Jul 11 21:44:21 UTC 2012, Gunnar Helstrom <
gunnar.hellstrom at omnitor.se> wrote:
> Dave, Sounds good.
Can you convert your conclusion to modification proposals for chapter 5
Please hold off until Version 0.4;
I already made changes and like comments in the next review cycle. v0.4
will only have about 1/10th as many changes as v0.3. The flux is going
down. It will make it easier to re-review sections such as section 5 for
further refinements (if needed).
-- The new wording I already did, is cleaner and I think, more acceptable.
-- Instead of "blank rtt", I'm more specific as to it being <rtt
event='init'/> (Because it is a conveniently universal first element that's
the same with and without disco). If the protocol is followed, it is
harmless to send the optional <rtt event='init'/> (start RTT session)
practically instantly before the first <rtt event='new'/> (start new RTT
-- The spirit remains the same as chat state fallback: Chat states use the
fallback of that single blank <active/> element transmitted and then
watching for incoming chat states -- permitted by XEP-0085 chat states
section 5.1. This is exactly the same "fallback detection" technique as a
single blank <rtt event='init'/> and then waiting for response.
-- Yes, I'm still trying to figure out if I can still also incorporate
XEP-0115 (though I want to be consistent with the same method XEP-0085
plans to implement XEP-0115) -- to be determined.
So please wait and review the v0.4 of the spec coming in a few days.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards