[Standards] 301 feedback part1

Gunnar Hellstrom gunnar.hellstrom at omnitor.se
Sun Jul 7 17:31:44 UTC 2013


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 <localpart at domain.tld> to keep
only one real-time message per sender"

INTO: "Recipient clients MAY track incoming <rtt/> elements per bare
JID <localpart at domain.tld> 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 <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> 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> 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
gunnar.hellstrom at omnitor.se
+46708204288
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130707/b39bfb44/attachment.html>


More information about the Standards mailing list