[Standards] 301 feedback

Mark Rejhon markybox at gmail.com
Tue Jul 2 17:46:46 UTC 2013


On Tue, Jul 2, 2013 at 12:23 PM, Kevin Smith <kevin at kismith.co.uk> wrote:

> 4.2.2  - I'm aware than we've had debates in the past about how much
> needs to be MTI. As things currently stand, the XEP is fairly clear
> and straightforward, and I wonder if making all of these MTI would be
>

MTI?


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.
9. (TEST OF BARE JID PROCESSING)
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)


4.7 "Alternatively, recipient clients MAY keep track of separate
> real-time messages per full JID <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.
>

To the contrary.  It's rather simple: Test the use-case.
In a client that supports multiple RTT messages per window, both B1 and B2
would be displayed simultaneously on A in the above use-case example.   The
only difference to the UI would be B1 replacing B2, and vice-versa (4.7
processing), versus B1 and B2 being displayed at the same time.   There is
thusly, no incompatibility.

Also, it's already been checked several times.
Please try the implementations before discussing this matter as I suspect
you are slightly confused in this matter (not sure; but this is my
impression).
Once the client behaviours "make sense", please comment on how the wording
can be improved.
Perhaps a sentence needs to be added somewhere, to address the specific
confusion that you have?



> 4.7.3 "The message refresh SHOULD be transmitted regularly at an
> average interval of 10 seconds during active typing or composing. This
> interval is frequent enough to minimize user waiting time, while being
> infrequent enough to not cause a significant bandwidth overhead. This
> interval MAY vary, or be set to a longer time period, in order to
> reduce average bandwidth (e.g. long messages, infrequent or minor
> message changes)."
>
> It feels to me like this is really saying "It is suggested that a
> message refresh be transmitted regularly at an..." - otherwise the
> SHOULD and the MAY seem contradictory.
>

The "SHOULD" refers to an exact 10 second interval.
The "MAY" refers to a varying time interval (not exactly 10 seconds).
I can remove the second "MAY" into a "suggested", but the first "SHOULD" is
far more important as we've found it greatly improved reliability during
the emergency-use/911 tests/work with InDigital's demo.   I was considering
changing it to a "MUST" (I had pressure for that).


4.8.2 "In addition, XML character entities are counted as a single
> character."
> Isn't the RTT editing calculated before XML encoding in the sender and
> after XML decoding in the recipient? This statement seems redundant
> (or worse, misleading) to me.
>

That's correct.
The sentence is there if there are any implementations that needs to
encode/decode entities manually. (I don't think there are any).
(e.g. low level implementations)


6.2.1 "it is inappropriate to send any further <rtt/> elements, until
> support is confirmed either by incoming <rtt/> elements or via
> discovery."
>
> This needs to be normative somewhere, I think, that clients MUST NOT
> start transmitting RTT edits until support has been confirmed. I don't
> think the non-normative information note here is going to be sufficient.
>

Section 5.1 of XEP-0085 allows transmitting of XEP-0085 without determining
support.   I am merely simply being consistent with that, by permitting
only a single <rtt event='init'/> to be transmitted so that I'm fully
compatible with combining XEP-0301 with XEP-0085 in every single situation
that XEP-0085 can be used.   There has also been long discussions in the
past to this aspects, and this was an acceptable decision that was reached
by majority (albiet, not by everyone) -- consistency with XEP-0085 use
cases.



> Discovery for MUCs isn't covered - I think it needs to be; blithely
> sending RTT to an unsuspecting MUC would not be good.
>
> 6.4.4 - the seqs here aren't sequential - is that deliberate?
>

Correct.  event='new' and event='reset' are allowed to restart the 'seq'
numbering at any number, as mentioned in 4.3 Processing Rules.
If this was unclear, let me know how to tweak this.



> It's still long, but I found the XEP much clearer and easier to read
> than I did the early versions, so thank you to the authors for the
> improvements they've made.
>

Appreciated,
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130702/497361aa/attachment.html>


More information about the Standards mailing list