[Standards] 301 feedback part1

Mark Rejhon markybox at gmail.com
Sun Jul 7 17:50:26 UTC 2013


Regarding XEP-0301 --
http://www.xmpp.org/extensions/xep-0301.html
Totally agree with the vast majority of Gunnar's answers.  Just some very
minor tweaks needed.


On Sun, Jul 7, 2013 at 1:31 PM, Gunnar Hellstrom <
gunnar.hellstrom at omnitor.se> wrote:

>  ADD just before table:
>

For consistency, the text may need to be added afterwards the table (other
parts of XEP-0301 put such table-describing text afterwards)



> COMMENT #4
> 4.7 "Alternatively, recipient clients MAY keep track of separate real-time
> messages
> per full JID <localpart at domain.tld/resource><localpart at domain.tld/resource>and/or per <thread/> (Best Practices for Message Threads [9])."
> I think that some of the earlier instructions will be incompatible with
> having multiple RTT messages per full-JID.
> It would be worth someone else checking.
>
> ANSWER #4
> The sentence may be confusing, it is only when multiple threads are used
> that multiple real-time messages
> per full JID are needed.
>
> CHANGE:  "Alternatively, recipient clients MAY keep track of separate
> real-time messages
> per full JID <localpart at domain.tld/resource><localpart at domain.tld/resource>and/or per <thread/> (Best Practices for Message Threads [9])."
>
> INTO:  "Alternatively, recipient clients MAY keep track of one real-time
> message per full JID <localpart at domain.tld/resource><localpart at domain.tld/resource>or
> one per full JID and thread if threads are used. See (Best Practices for
> Message Threads [9])."
>

Let's discuss this a bit further with Kevin:
This type of wording change may not be sufficient.
There are these theoretical situations:
1. bare JID handling, ignoring <thread/> (execting 4.7 out-of-sync handling
on any collisions)
2. bare JID handling, interpreting <thread/> (execting 4.7
out-of-sync handling on conflicting full JID's)
3. full JID handling, ignoring <thread/> (execting 4.7 out-of-sync handling
on conflicting <threads/>)
4. full JID handling, separate <thread/>

XEP-0301 would work fine with all the above scenarios.  The user experience
would vary, but none of the scenarios would make XEP-0301 unusuable
because, in principle, there's typically only one typist coming from bare
JID.  The major usability divergences do begins to occur when multiple
typists start to use the same account (e.g. a wife and a spouse sharing the
same Jabber login).  In this event, the out-of-sync handling behaviour
differences become apparent (Simple worst case scenario: Thrashing of
real-time text from one buffer to the other buffer in a
once-every-10-second cycle, in the rare situation of simultaneous typists.
 But when hitting Enter, the two separate messages will still successfully
be delivered)

Now, as both me and Chris has expressed that we should leave it to the
implementer to decide how it handled -- e.g. decide on what handling to do
that allows simplification of implementation to just
"one-real-time-buffer-per-chat" -- then I would prefer it that way, as
typical scenario (>99% of use cases) is one active typist per bare JID
(e.g. simply switching between devices) and all 1/2/3/4 works just fine in
that scenario in a very interoperable manner; it's mostly a UX variance.
 The implementor does not have to merge window handling and
real-time-message-buffer handling, but the option is easily there, if the
implementer shall choose to do so; to simplify & improve UX.

Obviously, MUC would require support for multiple real time message buffers
per window, and thus would make it fairly easy to handle (4).  But not all
clients want to support MUC, and thus would be quite a lot simpler
(multiple implementers agree with me) for such clients to just follow (1).
  As a result, I want to word things in a way that allows the implementer
to decide what is easiest;

Thanks!
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130707/cd9defe5/attachment.html>


More information about the Standards mailing list