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 <[email protected]>
<mailto:[email protected]> 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
<[email protected]/resource>
<mailto:[email protected]/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 <[email protected]> <mailto:[email protected]> 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
<[email protected]/resource>
<mailto:[email protected]/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
[email protected]
+46708204288
