On Tue, Jun 4, 2013 at 10:34 PM, Peter Saint-Andre <[email protected]> wrote: > ...some technical and editorial comments... > MINOR ISSUES: > [snip]
(Regarding XEP-0301 real-time text) http://www.xmpp.org/extensions/xep-0301.html Thanks for your comments about minor changes to XEP-0301 during this last call period. Here are the proposed minor changes (list compiled by me and Gunnar): LIST OF MINOR CHANGES TO XEP-0301 ___ COMMENT 1: GOALS >>> Comment: Section 2: I think it would be worthwhile to mention >>> both internationalization and security as goals. SOLUTION: (A) Change second bullet in section 2.3: From: "2. Be able to function over intermittent and unreliable connections, including mobile phones." Into: "2. Be able to function securely via intermittent and unreliable connections, including mobile phones." (B) Add new bullet to end of section 2.3: "4. Be usable in an international setting, and in a secure manner." ___ COMMENT 2: Use of word "integrity" in section 4.2.1 > Section 4.2.1: "Recipients MUST monitor the seq value as an > integrity check on received real-time text." In what sense does the seq > value provide integrity, and what kind of integrity does it provide? What > comes immediately to mind is data integrity, which RFC 4949 defines as > follows: $ data integrity 1. (I) The property that data has not been > changed, destroyed, or lost in an unauthorized or accidental manner. (See: > data integrity service. Compare: correctness integrity, source integrity.) > 2. (O) "The property that information has not been modified or destroyed in > an unauthorized manner." [I7498-2] Yet the seq value does not provide data > integrity. Perhaps the authors mean something like in-order delivery? SOLUTION: Change 4.2.1 from current wording: > 4.2.1 seq > This REQUIRED attribute is a counter to maintain the integrity of real-time > text. Senders MUST increment this value by 1 for each subsequent edit to the > same real-time message, including when appending new text. Recipients MUST > monitor the seq value as an integrity check on received real-time text. Into: > This REQUIRED attribute is a counter to maintain synchronization of > real-time text. Senders MUST increment this value by 1 for each subsequent > edit to the same real-time message, including when appending new text. > Receiving clients MUST monitor this seq value as a lightweight verification > on the synchronization of real-time text messages. ___ COMMENT 3: Use of word "integrity" in section 4.3 > Comment: Section 4.3: "A random value is RECOMMENDED for improved integrity > during Usage with Multi-User Chat and Simultaneous Logins." Here again I'm > not sure the authors really mean 'integrity'. SOLUTION: Change sentence 4.3 in last bullet: > A random value is RECOMMENDED for improved integrity > during [[[Usage with Multi-User Chat and Simultaneous Logins]]]. Into: >"A random starting value is RECOMMENDED, since this improves > reliability of [[[Keeping Real-Time Text Synchronized]]] > during [[[Usage with Multi-User Chat and Simultaneous Logins]]]." ___ COMMENT 4: Remote cursor >>Section 6.3: Mention is made here of "remote cursor" but the term > > is not defined. SOLUTION: Change first sentence in 6.3 From: "Recipient clients can choose to display a separate cursor/caret indicator within incoming real-time messages." To: "Recipient clients can choose to display a remote cursor within incoming real-time messages. A remote cursor is a separate cursor/caret indicator within incoming real-time messages, separate of the user's local cursor for outgoing messages." ___ COMMENT 5: Timing attacks >>> On 2013-06-05 04:34, Peter Saint-Andre wrote: >>> >>> 4. Do you have any security concerns related to this specification? >>> I request that the authors describe whether transmission timing >>> attacks are possible even if message encryption is used. SOLUTION: Add new text to the end of section 10.2: "It is possible for the timing of individual key presses to be used as a timing attack on encryption. Protection against this is provided by buffering of key presses into a regular [[[Transmission Interval]]]. As an additional measure of security, the risk of timing attacks can be further mitigated by padding <rtt/> elements to lengths not clearly related to the number of characters in the message. Alternatively, general XMPP protection mechanisms hiding length information can be applied on the complete message exchange instead of (or in concert with) <rtt/> specific protection mechanisms." ___ COMMENT 6: Section 2.2 mentions "simultaneous logins". >> I assume this means "multiple simultaneous sessions associated with separate >> devices or user agents". This could also be clearer in Section 6.6.4.2. SOLUTION: Add item to Section 3 glossary: "Multiple simultaneous sessions, on multiple clients, using the same login (JID)." Change 6.6.4.2 from: > In simultaneous login situations, transmitting of <rtt/> works in > one-to-many situations without any special software support. For many-to-one > situations where there is incoming <rtt/> from more than one simultaneous > login, [[[Keeping Real-Time Text Synchronized]]] will pause the real-time > message upon conflicting <rtt/>, and resume during the next > [[[Message Refresh]]], presumably from the active login. Into: > In situations where there are multiple sessions from the same JID > (i.e. simultaneous logins on multiple clients/devices), transmitting of > <rtt/> works in one-to-many situations without any special software support. > For many-to-one situations where there is incoming <rtt/> from multiple > sessions under the same JID, [[[Keeping Real-Time Text Synchronized]]] > will pause the real-time message upon conflicting <rtt/>, and resume > during the next [[[Message Refresh]]], presumably from the active session. ___ COMMENT 7: Wording on elements in 4.3 > Comment Section 4.3: "Sender clients MUST use either element as the first > <rtt/> transmission of a new real-time message." What are the elements > referred to here? Do you actually mean something like this? "Sender clients > MUST use an <rtt/> element with an 'event' value of "new" or "reset" in the > first stanza sent when starting composition of a new real-time message." SOLUTION: In 4.3, first bullet point change first sentence: > Sender clients MUST use either element as the first <rtt/> transmission > of a new real-time message. Into: > Sender clients MUST use an <rtt/> element containing either > event='new' or event='reset', in the first transmission of a new > real-time message. ___ COMMENT 8: presence > Section 4.7.3: "When the recipient becomes available (e.g. presence changes > to 'chat');" ... a change in presence to a <show/> value of "chat" does mean > that the recipient has become available. This needs to be worded more > carefully. SOLUTION: Change From: "When the recipient becomes available (e.g. presence changes to 'chat');" To: "When the recipient presence changes to a more available state (e.g. <show/> value of 'chat');" ___ COMMENT 9: Section 6.1.2: > Please expand "VoIP" on first use. SOLUTION: Change From: "VoIP" To: "Voice over IP (VoIP)" ___ COMMENT 10: XMPP-SIP Address translation > Section 8.1: With regard to address translation, please consider referencing > draft-saintandre-sip-xmpp-core: > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ SOLUTION: Add sentence to end of 8.1: > Guidance on address translation and conveyance between XMPP and SIP can be > found in [[[Interworking between SIP and XMPP: Addresses and Error > Conditions]]]. (Adds link to reference) ___ COMMENT: DoS Comment. > Section 10.3: Please expand "DoS" on first use, and consider adding a > reference to XEP-0205. SOLUTION: Change From: "DoS" To: "Denial of Service(DoS)" And, at the end of that paragraph, add: "See &xep0205;" (Which will add reference automatically) ___ COMMENT 12: From gunnar Hellstrom: There is an extra bracket in the middle of section 6.5 SOLUTION: Delete right bracket from this phrase in the middle of 6.5. "If Element <w/> – Wait Interval] is supported" ___ COMMENT 13: From Mark Rejhon: > In 4.7 last paragraph, insert "bare JID" and "full JID" SOLUTION: Change: "&localbare;" Into: "bare jid &localbare;" Change: "&localfull;" Into: "full jid &localfull;" ___ COMMENT 14: All edits made by Peter Saint-Andre are already included. Thanks, Mark Rejhon
