Re: http://www.xmpp.org/extensions/xep-0301.html
On Tue, Jul 16, 2013 at 4:20 PM, Peter Saint-Andre <[email protected]>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 made: ___________ 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]> <[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> <[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]> <[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><[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 "
