[Standards] 301 feedback part1

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 16 21:20:48 UTC 2013


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 <stpeter at stpeter.im
> <mailto: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 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 <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 "


-- 
Peter Saint-Andre
https://stpeter.im/





More information about the Standards mailing list