[Standards] XEP-0301 Real-time text feedback response

Gunnar Hellstrom gunnar.hellstrom at omnitor.se
Sat Aug 3 10:14:26 UTC 2013


Version 0.11 of XEP-0301 is published and available at
http://xmpp.org/extensions/xep-0301.html

*This version is intended to contain changes corresponding to Kevin's 
last call feedback from July, 2.
*
Comments and answers #1-#6 have been submitted before, but are included 
here to make the list of changes from version 0.10 complete.
By this we regard all comments received so far during the last call 
period to be handled.
The comments and answers are the following:
____

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 after table:
"Note: The seq attribute can be restarted at any value with <rtt 
event='reset'/> and <rtt event='new'/>. See [[[Processing Rules]]]."
____

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.  Also, Kevin 
said "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 #3
The paragraph had several weaknesses, so the paragraph has been reworded 
in several places.
-- Remove "For implementation simplicity" phrase.  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 this phrase.
-- Change "sender" to "contact" for consistency with RFC6121 in using 
"contact" towards bare JID / full JID / thread terminology.
-- Mention use case of only one typist per contact, as a clarifying 
rationale.
-- Word the last sentence in a more similar way to the second sentence.

CHANGE:
FROM: "Recipient clients MUST keep track of separate real-time messages 
on a per-sender basis, including tracking independent seq 
<http://xmpp.org/extensions/xep-0301.html#seq> values. For 
implementation simplicity, recipient clients MAY track incoming <rtt/> 
elements per bare JID <localpart at domain.tld> 
<mailto:localpart at domain.tld> to keep only one real-time message per 
sender. Recipient client handling of conflicting <rtt/> elements (e.g. 
coming concurrently from separate Simultaneous Logins 
<http://xmpp.org/extensions/xep-0301.html#simultaneous_logins>) is 
described in the remainder of this section. Alternatively, recipient 
clients MAY keep track of separate real-time messages per full JID 
<localpart at domain.tld/resource> 
<mailto:localpart at domain.tld/resource>and/or per <thread/> (Best 
Practices for Message Threads 
<http://xmpp.org/extensions/xep-0201.html> [9 
<http://xmpp.org/extensions/xep-0301.html#nt-id301361>])."

INTO: "Recipient clients MUST keep track of separate real-time messages 
on a per-contact basis, including tracking independent 
/[[[seq]]]/ values. Recipient clients MAY track incoming <rtt/> elements 
per bare JID <localpart at domain.tld> <mailto:localpart at domain.tld> to 
keep only one real-time message per contact. The remainder of this 
section automatically handles conflicting <rtt/> elements (e.g. typing 
coming concurrently from separate [[[Simultaneous Logins]]], contrary to 
the common case of one typist per contact). Alternatively, recipient 
clients MAY track incoming <rtt/> elements per full JID 
<localpart at domain.tld/resource> 
<mailto:localpart at domain.tld/resource>and/or per <thread/>, to keep 
multiple separate real-time messages for the same contact.  For more 
information about <thread/>, see Best Practices for Message Threads 
<http://xmpp.org/extensions/xep-0201.html> [9 
<http://xmpp.org/extensions/xep-0301.html#nt-id301361>]."
____

COMMENT #4:
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 #4:

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 at intervals during active
  typing or composing. The RECOMMENDED interval is 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 #5:
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 #5:
Add more text to the Privacy section to also cover this.  This makes the 
paragraph too big, so some sentences are rearranged/reworded and is now 
broken into two separate paragraphs.  The 10.1 Privacy section now reads 
as follows:
"It is important for users to be made aware of real-time text (e.g. user 
consent, software notice, introductory explanation). Users of real-time 
text need to be aware that their typing is now visible in real-time to 
everyone in the current chat conversation. There can be potential 
security implications if users copy & paste private information into 
their chat entry buffer (e.g. a shopping invoice) before editing out the 
private parts of the pasted text (e.g. a credit card number) and then 
sending the message. There can also be implications for chat clients 
that suddenly pop up a chat window upon incoming messages and takes 
keyboard focus unexpectedly, resulting in the sender typing sensitive 
information into the wrong window. These accidental privacy risks are 
also apparent for traditional chat (e.g. accidentally sending a message) 
but are more immediate for real-time text. With real-time message 
editing, recipients can watch all text changes that occur in the 
sender's text, before the sender finishes the message.
Such risks can be avoided by good user interface design. In addition, 
implementation behaviors and improved education can be added to reduce 
privacy issues. Examples include showing an introduction upon first 
activation of feature, special handling for copy and pastes (i.e. 
preventing them, or prompting for confirmation), recipient confirmation 
of real-time text via [[[Activating and Deactivating Real-Time Text]]], 
etc."
___

COMMENT #6, added by Gunnar and Mark.
The document in reference #23 has been replaced, and complemented with a 
series of documents.
The one covering the addressing and general mapping between SIP and XMPP is
"Interworking between the Session Initiation Protocol (SIP) and the 
Extensible Messaging and Presence Protocol (XMPP): Addresses and Error 
Conditions"
http://tools.ietf.org/html/draft-ietf-stox-core

ANSWER #6:

(A) CHANGE in 8.1
FROM: "at Interworking between SIP and XMPP: Instant Messaging  [23]"
INTO "in [23]

(B) CHANGE in Appendix G, item 23
FROM: "23. draft-saintandre-sip-xmpp-im: Interworking between the 
Session Initiation Protocol (SIP) and the Extensible Messaging and 
Presence Protocol (XMPP): Instant Messaging 
<http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im-03>"
INTO: "23. Interworking between the Session Initiation Protocol (SIP) 
and the Extensible Messaging and Presence Protocol (XMPP): Addresses and 
Error Conditions", IETF, http://tools.ietf.org/html/draft-ietf-stox-core "
___
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  - There are some far-going consequences of making all items 
required. We prefer to keep the levels as they are.
---------------
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
MOVE "6.2 Activating and Deactivating Real-Time Text"
TO: "6 Guidelines for Initiating Real-Time Text" (independent section 
between "5. Determining Support" and earlier chapter 6, now moved to "7. 
Implementation Notes")
And then adjust text in new chapter 6 for its new upgraded status as an 
RFC2119-qualified section but not a strict one (zero use of "MUST" / 
"MUST NOT").  Less important than Protocol, but more important than 
Implementation Notes. Clarification on how to avoid loops of 
transmission of event='init' is added.  Also slight adjustments related 
to MUC, based on Kevin's comment.

--------
-- 
------------------------------------------------------------------------
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/20130803/0fe6417c/attachment.html>


More information about the Standards mailing list