[Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Mark Rejhon markybox at gmail.com
Thu Jul 26 21:30:48 UTC 2012

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 <markybox at 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]
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.

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]]].

>> - 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).

>> - 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 Clarify "Element <e/> Backspace" by renaming it to
"Element <e/> - Erase Text" and mention it's used for all text delete
- Section 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
(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.

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
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)

Mark Rejhon

More information about the Standards mailing list