More changes made, after thought and consultations. I think I've now addressed 90% of the section 1-5 concerns by Kevin. Some small unanswered questions in the original email (not included here), but this email aims to reduce workload for Kevin.
On Mon, Jul 23, 2012 at 3:17 PM, Mark Rejhon <marky...@gmail.com> wrote: >> == Requirements == >> 2.3.4 doesn't seem quite right - what we want is for it to be possible >> to produce gateways for interoperability - not that XEP 301 >> implementations themselves interop with other networks? >> 2.4 Doesn't seem to be about Accessibility. >> 2.4.4 Doesn't make much sense to me. > > [Question] > Peter (or anyone else at XSF), any comments about these? > I'd like a second set of comments on these points, and then I'd like to > confer with the R3TF group about revisions. [Change Made] -- 2.3.4 bullet clarified to say "Allow use within gateways to interoperate with other real-time text protocols, including RFC 4103 and ITU-T T.140." ... This feature is a critical requirement for some parties, including Omnitor (Gunnar Helstrom). -- 2.4 heading remains unchanged for 0.6, I would appreciate wider comment for renaming this heading while keeping accessibility. -- 2.4.4 bullet changed to "Allow immediate conversational text through mobile phone text messaging and mainstream instant messaging." ... A major goal of XEP-0301 is to permit existing texting environments to be used conversationally. It's worth noting that this bullet acknowledges the use of XMPP in environments normally used for SMS (e.g. Apple iMessenger, Google Talk Android, etc) >> 4.2.2 - "Recipients MUST treat 'reset' the same as 'new'." - I'm not >> sure that's quite right. If recipients want to render 'new' >> differently that seems to be fine. Maybe "Recipients MUST reset the >> state of the current real-time message when receiving a 'reset' >> (returning the real-time message to the same state as when receiving a >> 'new')"? > > [Comment & Question] > Yes, rendering 'new' and 'reset' is the reason that the two still are treated > separate. > However: > (1) It's possible to receive <rtt event='reset'/> without ever receiving an > <rtt event='new'/>. (e.g. recipient logs on after sender starts composing, > MUC participant joins, stanza with 'new' is lost, etc). > (2) Basic Real-Time Text at > http://xmpp.org/extensions/xep-0301.html#basic_realtime_text > (3) The 'new' _also_ resets any existing real-time message if any is shown. > There is always only one real-time message per sending client. > [snip] [Change Made] event='new' Senders MUST use this value when transmitting the first <rtt/> element containing [[[Action Elements]]] (i.e. the first character(s) of a new message). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the <rtt/> element. If a real-time message already exists in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent <rtt/> elements that do not contain an event attribute. event='reset' For recipients, both 'new' and 'reset' are logically identical, and differ only for implementation purposes (e.g. highlighting newly-started messages). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the <rtt/> element. If a real-time message already exists in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent <rtt/> elements that do not contain an event attribute. Recipients MUST be able to process 'reset' without first receiving 'new'. See [[[Message Reset]]], used for [[[Keeping Real-Time Text Synchronized]]] and [[[Basic Real-Time Text]]]. >> 4.5.3.2 - This might become clearer later, but at this stage it's not clear >> what 'positions' are. [Change Made] Section 4.5.2: Improved the first two bullets, for definition of position and length: - For [[[Element <e/> – Erase Text]]]: The n attribute is a length value, in number of characters. If n is omitted, the default value of n MUST be 1. - For [[[Element <t/> – Insert Text]]] and [[[Element <e/> – Erase Text]]]: The p attribute is an absolute position value, as a character position index into the message, where 0 represents the beginning of the real-time message. If p is omitted, the default value of p MUST point to the end of the message (i.e. p is set to the current length of the real-time message). >> 4.5.3.3 - Apart from adding complexity I'm not sure what forward >> delete is buying us vs. backspace. [Change Made] Background information: After a few hours of tests and consultations, several implementers have agreed the merger has more advantages than disadvantages. There are several reasons posted in my last reply, including time-smoothed display, and accurate journalling of edits (recipient being able to tell Backspace keypresses apart from Delete keypresses). However, I have now consulted several known implementations, and we have all, so far, unamiously agreed that the merger of <e/> and <d/> elements. Of the two, we have to keep <e/> for the obvious reason of efficency (<e/> can be used without attributes for efficient bandwidth). Compatibility impact is not a problem for always using <e/> for both backspace and delete key presses, and compatibility with Remote Cursor is still maintained even when the Delete key is pressed. This is the only real change to protocol that we have agreed on, and is mostly backwards compatible (but better now, while Experimental, rather than Draft). I have now updated RealJabber internally (to be checked in a few days) and found it actually saved a little more code than expected -- 30 lines (out of 1000) while still preserving all other features. No difference in user experience for this specific implementation (since I don't do journalling of edits), even the Remote Cursor continues to function exactly the same as before, even with the Delete key (which now causes <e/> elements to be sent instead). The spec is simpler without it. In conclusion, the advantages outweigh the disadvantages. Changes Made, for removal of <d/> element (simply use <e/> instead of <d/>) - Section 4.5.1 Action Elements: Remove the <d/> element from the table. - Section 4.5.3: Remove reference to <d/> - Section 4.5.3.2: Clarify "Element <e/> Backspace" by renaming it to "Element <e/> - Erase Text" and mention it's used for all text delete operations. - Section 4.5.3.3: Remove section "Element <d/> - Forward Delete" - Section 6.3.1: Calculating Cursor Position (optional remote cursor) - Remove mention of <d/> - Section 7 Use Cases: Convert all <d/> into equivalent <e/> - Section 13 XML Schema: Remove <d/> > 4.6 - "XMPP servers may drop <message/> elements (e.g. flooding protection)." > - They can't. [Change Made] "Resuming after lost message stanzas (e.g. [[[Congestion Considerations(link)]]])." (eliminates mentioning servers or where message stanzas are dropped; just that simply loss can happen, and then reference the pre-existing Congestion Considerations section.) > 4.6.1 - "Recipients MUST keep track of separate real-time messages per > sender, including maintaining independent seq values" - I think what > you mean is that they "MUST track RTT per full-JID, and not collate > across multiple full JIDs", rather than the present text, which > suggests that they must track multiple RTT streams for a single full > JID without providing guidance how. I think this needs tightening up > to be clear of the intent. [Comment] I split this information to a separate email message thread; which I'm interested in hearing your response. > 4.6.3 - "Retransmission SHOULD be done at an average interval of 10 > seconds during active typing or composing." - this seems like a lot of > data getting sent across if these messages are large. I'd be much > happier saying something like "Retransmission SHOULD NOT be done more > frequently than once every 10 seconds [Change Made] Improved third sentence of second paragraph: "This interval MAY vary to a longer interval, in order to reduce average bandwidth (e.g. long messages, infrequent or minor message changes)." RFC2119 normatives are eliminated from section 6 and beyond upon advice from Peter. Also, note that "Basic Real-Time Text" permits message resets every 0.7 seconds for short real-time messages, for simple implementations http://xmpp.org/extensions/xep-0301.html#basic_realtime_text It also notes stream compression can be very efficient with frequent message resets during XEP-0301, due to high redundancy. --- Concluding note: I believe that this email addresses most of Kevin's concerns for section 1-5, with the exception of the Unicode concerns, and the concerns about bare vs full JID. (These topics have already been forked to separate email threads) Hope this email at least reduces Kevin's workload, and allows me to publish Version 0.6 before the end of the week (So Matt et cetra can read it) (I think 90%+ of my v0.6 edits are made now, with the final edits after further comment) Cheers, Mark Rejhon
