[Standards] 301 feedback

Christian Vogler christian.vogler at gallaudet.edu
Tue Jul 2 18:08:22 UTC 2013

I agree with Mark re the bare JID. It seems to be simpler from both a
user's point of view and an implementer's perspective. The logic can be
seen in line 1252 at

- all it does is to check whether a RTT message is in sync by both checking
expected sequence number and last seen full JID. If either exhibit a
mismatch, it is treated as an out of sync condition with normal recovery
procedures. All subsequent dispatch of that message is by bare JID.


Sent from my mobile phone.  Please excuse any touchscreen-induced weirdness.
On Jul 2, 2013 1:57 PM, "Mark Rejhon" <markybox at gmail.com> wrote:

> On Tue, Jul 2, 2013 at 1:46 PM, Mark Rejhon <markybox at gmail.com> wrote:
>> 4.7 "For implementation simplicity, recipient clients MAY track
>>> incoming <rtt/> elements per bare JID <localpart at domain.tld> to keep
>>> only one real-time message per sender"
>>> Would this really help implementors? Trying to do bare-JID only seems
>>> like it's going to involve more complexity and headache than doing
>>> full-JID.
>> To the contrary; you would be surprised that this actually simplifies
>> things.  Since all implementers are REQUIRED to implement other parts of
>> section 4.7 "Keeping Real-Time Text Synchronized" (for other reasons), this
>> de-facto makes bare JID processing _much_ simpler than full JID processing
>> because:
>> -- Your software only need to keep track of one real-time buffer per
>> window
>> -- Your software user interface only needs to dispolay one real-time
>> message per window.
>> -- It's accidentally more intuitive anyway (we don't expect multiple
>> typists from the same JID).
>> No other software changes because other REQUIRED elements of XEP-0301
>> automatically handles (or even by one interpretation, "by accident")
>> bare-JID processing.
>> Example use case, which can be done solely using web browser:
>> 1. Get three laptops/computers/ipads/tablets. (or three separate brands
>> of browsers on same computer -- Mozilla, Chrome, IE)
>> 2. Load http://tap.gallaudet.edu/rtt/ on all three
>> 3. Log on using one JID on one system.  This is system "A"
>> 4. Log on using different JID on two systems.  This is system "B1" and
>> "B2"
>> 5. Start playing with messaging each other.
>> 6. Start typing on A.  You'll see your real-time text show on both B1 and
>> B2.
>> 7. Start typing on B1.  You'll see your real-time text show on A.  Hit
>> Enter before the next step.
>> 8. Start typing on B2.  You'll see your real-time text show on A.  Hit
>> Enter before the next step.
>> Start typing on B1 and then stop typing without hitting Enter.  Real-time
>> text shows on A.
>> Now start typing on B2.  Real-time text is frozen on A (because it's
>> required anyway), for up to about ~10 seconds (thanks to section 4.7.3),
>> then the whole message gracefully suddenly switches from the B1 partial
>> message to the B2 active message.  You'll quickly see that the behaviour is
>> quite intuitive.
>> Both RealJabber and the TAP client use bare-JID processing for simplicity
>> (one real-time buffer per window)
> Now from the end-user's point of view, the equivalent situation occurs:
> 1. User (logged simultaneously on B1 and B2) is typing a message on B1
> (e.g. a desktop)
> 2. User steps away without hitting Enter.
> 3. User picks up B2 (e.g. a tablet) and starts typing a message.
> 4. The person at A will eventually start seeing real-time text from B2
> instead of B1.
> So this is the common use case: Device-switching (without first committing
> message).
> There is typically only one user logged onto all the JID's, and it would
> be a very rare case that people are typing from multiple clients under the
> same JID, too.
> -- If the client only supports bare JID, the RTT message from B2 simply
> eventually replaces the RTT message from B1.
> -- If we did multi-JID handling, we'd see multiple RTT messages (a stalled
> B1 message that's persistent on-screen, and an active B2 message).
> -- There are definitely pros/cons of the two above approaches, but on
> average, the bare JID handling tended to be more intuitive (user
> perspective) and simpler (developer perspective) as the developer is forced
> to implement other REQUIRED aspects of XEP-0301 for other, different
> reasons, but which happens to makes bare JID processing the simple choice
> since no other work is required to support bare JID processing.
> NOTE: If the user went back to B1 and resumed typing the message, it will
> replace again (switch back), or if the user already commited B2 by hitting
> Enter, the B1 message will automatically show up as a new real-time
> message, thanks to the first bullet in "4.3 Processing Rules".
> Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130702/cf00a23e/attachment.html>

More information about the Standards mailing list