Kevin and all,
We are glad to get a prolonged Last Call on XEP-0301 to get a chance
handle Kevin's questions.
A first set of answers to your questions, and proposals for
corresponding edits are provided here.
They relate to
http://xmpp.org/extensions/xep-0301.html
The set provided now are the simple ones resulting in minor modifications.
Answers on two more questions ( #7 and #8 ) are forthcoming, with
answers on the normative-related discussion related to sections 4.2.2
and 6.2.1.
_____
COMMENT #1:
6.4.4 -- seq numbers in example are not in sequence. Why?
ANSWER #1
Need to reference section 4.3 to remind reader:
ADD just before table:
"Note: The seq values are not in sequence in this example because all
messages contain event 'new' or 'reset' and section
Section [[4.3 Processing Rules]] allows <rtt event='new'/> and<rtt
event='reset'/> to restart seq numbering at any value."
COMMENT #2:
4.8.2 -- Kevin said "In addition, XML character entities are counted
as a single character." is redundant.
ANSWER #2
It is already mentioned in
"including entities converted to characters)" in a subsequent
paragraph. The latter mention alone, is sufficient.
DELETE: "In addition, XML character entities are counted as a single
character."
COMMENT #3:
4.7 Bare JID handling may not be clear why it is simpler.
ANSWER #3
There are good reasons why it was preferred by both RealJabber client
and the TAP
client, but it may not be a good idea to universally have the phrase "For
implementation simplicity".
CHANGE:
FROM: "For implementation simplicity, recipient clients MAY track
incoming <rtt/> elements per bare JID <[email protected]> to keep
only one real-time message per sender"
INTO: "Recipient clients MAY track incoming <rtt/> elements per bare
JID <[email protected]> to keep only one real-time message per
sender. (Also see 6.6.4.2 Simultaneous Logins)."
COMMENT #4
4.7 "Alternatively, recipient clients MAY keep track of separate
real-time messages
per full JID <[email protected]/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 <[email protected]/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 <[email protected]/resource> or
one per full JID and thread if threads are used. See (Best Practices for
Message Threads [9])."
COMMENT #5:
4.7.3 -- Decouple two conformance requirements. (A) Requirement of
regularity of transmission versus the size of the transmission
interval, and (B) clearly indicating that the 10 seconds is a default.
ANSWER #5:
CHANGE: "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)."
INTO: "The message refresh SHOULD be transmitted during active
typing or composing. It is RECOMMENDED to transmit the message
refresh at regular intervals of 10 seconds. This interval is frequent
enough to minimize user waiting time during out-of-sync conditions,
while being infrequent enough to not cause a significant bandwidth
overhead.
The interval can be varied, or be set to a longer time period, when so
needed
to reduce average bandwidth (e.g. in case of long messages, infrequent
or minor
message changes).
COMMENT #6:
10.1 Some clients pop up chat windows when incoming messages are
received - This may not be appropriate to enable RTT right away upon popup.
ANSWER #6
CHANGE:
FROM: "With real-time message editing, recipients can watch all text
changes that occur in the sender's text, before the sender finishes
the message."
INTO: "There can also be implications for chat clients that suddenly
pop up a chat window upon incoming messages and take focus, as the
sender can
unexpectedly start typing sensitive information into the wrong window.
Such risks should be avoided by good UI design. They are also apparent
for traditional chat but are more obvious for real-time
text because with real-time message editing,
recipients can watch all text changes that occur in the
sender's text, before the sender finishes the message."
----------------------------------------------------------
COMMENTS NOT YET ANSWERED
COMMENT #7
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.
ANSWER #7 - to come
COMMENT #8
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.
ANSWER#8 - to come
-----------------------------------------
Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email protected]
+46708204288
