Excellent, thanks for the update! On 7/16/13 3:16 PM, Mark Rejhon wrote: > Re: http://www.xmpp.org/extensions/xep-0301.html > > On Tue, Jul 16, 2013 at 4:20 PM, Peter Saint-Andre <[email protected] > <mailto:[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]> >> <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 "
-- Peter Saint-Andre https://stpeter.im/
