[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
markybox at gmail.com
Tue Apr 17 13:57:08 UTC 2012
On Tue, Apr 17, 2012 at 5:35 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
> I think that you can just start rtt-ing on the previous message
> without retransmitting it in advance, unless you care about the edge
> case where a user has switched clients very quickly and so doesn't
> have that message. I would think that case isn't work optimising for.
I think it would work fine that way, although in clients not "aware of
combining XEP-0301 and XEP-0308", the RTT message would be a duplicate of
the message above it, which might confuse some users. But it would work.
There, however, is an interest to make sure that clients know *which* line
the <rtt> edits, so that software vendors can decide to do so. I think
it's about 3 or 4 years too early to have a serious spec about this, but:
One method of last message correction being built into XEP-0301 is to use
an 'id' parameter in <rtt> elements, so I could have "X-line" retroactive
editing, like being able to edit the last 10 lines of text. (Some
additional disco parameter could be use to define X lines). For clients
that don't have history, <rtt event='reset' id='oldmsgnumber'/> could be
used as a message history downloading technique, i.e. to redownload the
last 10 messages. Everytime a cursor moved to a line and the line was
begun to be edited, a new <rtt> 'event' would be used.
I feel that the ability to add a line 'id' to <rtt> gives XEP-0301
potential as a retroactive editor that is richer than XEP-0308, but it
would be of interest to "keep the door open" because XEP-0301 is a
potential spec used for live transcriptions, real-time captioning, court
reporting (my spouse was a court reporter), etc, as there are times that
major errors in captions needs to be retroactively edited within 30
seconds, etc. (Note: Good clients with retroactive editing can decide to
color retroactive edits in a different color-code, to indicate a successful
edit) -- Then again, the question comes up, as to whether XEP-0301 is
appropriate as a retroactive editing spec (if extended with a line 'id'
parameter, and using a variant of event='reset' to redownload lines of
messages, especially in client-switching situations) ... I intentionally
designed XEP-0301 to be theoretically compatible with private extensions
that allow XEP-0301 to behave as a basic text editor or an X-line
retroactive editor, although that's probably overkill.
> b. Can we keep the description about Last Message real-time correction by
> > <rtt> completely within XEP-0301, and let the implementor understand that
> > the modified message <body> after all <rtt> elements shall be sent with
> > <replaces> and<id> element? Or do we need to mention XEP-0301 in XEP-0308
> > and XEP-0308 in XEP-0301 and synchronize their approvals?
> It seems reasonable to me to keep this within 301.
Possibly, but some co-operation is necessary, because I sort of
intentionally designed XEP-0301 to *theoretically* behave as a multiline
text editor in the future (keeping the court reporting workflow door open,
due to my spouse), and that scope overlaps with XEP-0308.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards