[Standards] 301 feedback part1
markybox at gmail.com
Tue Jul 16 21:16:06 UTC 2013
On Tue, Jul 16, 2013 at 4:20 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:
> Where do we stand on finishing this round of edits?
We are finished with the edits, with the sole exception of Kevin's comment
on the normative in Section 6.2. Keep tuned on that last edit (and MUC).
For those keeping track, this is the current list of edits that have been
6.4.4 -- seq numbers in example are not in sequence. Why?
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]]]."
4.8.2 -- Kevin said "In addition, XML character entities are counted as a
single character." is redundant.
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
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
The paragraph had several weaknesses, so the paragraph has been reworded in
-- 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
-- Word the last sentence in a more similar way to the second sentence.
FROM: "Recipient clients MUST keep track of separate real-time messages on
a per-sender basis, including tracking independent
For implementation simplicity, recipient clients MAY track incoming <rtt/>
elements per bare JID <localpart at domain.tld> <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
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> <localpart at domain.tld/resource>and/or per
<thread/> (Best Practices for Message
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> <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><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>
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.
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
INTO: "The message refresh SHOULD be transmitted at intervals during active
typing or composing. The RECOMMENDED interval is 10 seconds. This interval
enough to minimize user waiting time during out-of-sync conditions,
while being infrequent enough to not cause a significant bandwidth
The interval can be varied, or be set to a longer time period, when so
to reduce average bandwidth (e.g. in case of long messages, infrequent or
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.
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
"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"
(A) CHANGE in 8.1
FROM: "at Interworking between SIP and XMPP: Instant Messaging "
INTO "in 
(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 <
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 "
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards