[Standards] 301 feedback part1

Gunnar Hellstrom gunnar.hellstrom at omnitor.se
Sun Jul 7 19:44:34 UTC 2013


On 2013-07-07 19:50, Mark Rejhon wrote:
> 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 <mailto: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)
No problem, just make sure that the reader sees it before starting to 
wonder why the seq are not in sequence in this example.
>
>     COMMENT #4
>     4.7 "Alternatively, recipient clients MAY keep track of separate
>     real-time messages
>     per full JID <localpart at domain.tld/resource>
>     <mailto: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>
>     <mailto: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>
>     <mailto: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
My proposal did not aim at explaining lower number of real-time 
messages. It aimed at what I thought was Kev's question.  "having 
multiple RTT messages per full-JID". So,
I inserted the explanation that it was only when there are multiple 
threads per full JID that you MAY want to use one real-time message per 
thread and therefore more than one for the full JID.

Kev, was that your question?

Thanks,

Gunnar





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130707/288c24ac/attachment.html>


More information about the Standards mailing list