[Standards] XEP-0301 Fallback Mechanism of Determining Support (Accessibility)

Mark Rejhon 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

and 6.2?


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
message).
-- 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.

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120711/46f3c47e/attachment.html>


More information about the Standards mailing list