[Standards] 301 feedback part1

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 16 20:20:52 UTC 2013


Where do we stand on finishing this round of edits?

On 7/7/13 1:44 PM, Gunnar Hellstrom wrote:
> 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?





More information about the Standards mailing list