[Standards] 301 feedback

Kevin Smith kevin at kismith.co.uk
Tue Jul 2 16:23:25 UTC 2013


Too late for the LC, I realise, but earlier than the Council vote tomorrow.

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
much of an imposition on implementers.


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.


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.

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.

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.

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.

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?

10.1 Some clients pop up chat windows when incoming messages are
received - I think it's worth a note here that such behaviour isn't
appropriate with RTT, as grabbing focus without the user's request can
mean that passwords get stolen into chats with other people.



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.

/K



More information about the Standards mailing list