[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
markybox at gmail.com
Thu Jul 19 08:44:05 UTC 2012
On Thu, Jul 19, 2012 at 3:32 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
> Including the id in an RTT element to indicate it's affecting the most
> recent message seems fine. Then sending a standard 308 stanza when the
> edit is complete seems sensible. This is I think what you're
> proposing. I think it's worth including the id on every RTT edit,
> rather than just the first - it makes the state machine easier for the
> receiving clients and doesn't hurt the sending client. I think it
> should have an additional disco feature, as one could implement 308
> and 301 but not implement RTT correction.
I've thought of this, and this is what I'd prefer to see. I like this idea.
But, sometimes the problem with including the id early (i.e. generating the
id before the <body/>) is that this kind of breaks the 'id' generator
workflow expected by most software. Most of the time, the id is generated
when a <body/> is generated. Many XMPP libraries have made the assumption
that id is generated only when a body is sent.
As a result, I would not like to make this REQUIRED for <rtt/> elements,
i.e. the lack of id automatically means the latest (most recent) message.
But it's a nice-to-have, for clients that can be made to pre-generate the
id for <rtt/> well before the id is used for <body>.
It's not necessary to provide an additional disco feature if 301 + 308 is
implemented without RTT correction, because the behaviours I described (in
the last message) are acceptable. Can you explain the rationale of
providing such an additional disco feature?
> > Does anyone outside the Real Time Text Taskforce, think I should expand
> > XEP-0301 standard to allow implementors to do in-place real-time text of
> > last message, by the addition of the 'id' parameter?
> It seems worthwhile - I would have thought that clients were more
> likely to implement RTT with correction at the same time (given the
> correction part is a trivial extension) than to implement RTT and then
> later to merge this with correction support.
Hmmm, it's a good rationale -- this might be a good reason, if one vendor
was trying to decide whether XEP-0301 was compatible with XEP-0308 and
opted to only go for XEP-0308 due to potentially mis-interpreted
> Or since it's a backwards-compatible modification, I should wait until
> > XEP-0308 is considered a Draft standard before adding it to XEP-0301?
> I think we should try to avoid planning to make changes to a Draft
> spec. It /is/ possible to make changes (especially
> backwards-compatible ones) to a Draft XEP, but still...going to Draft
> means we think the XEP is ready, so doing this while we know there are
> pending edits seems disingenuous.
Conversely, we're probably going to beat XEP-0308 to Draft status first --
so XEP-0301 as a Draft reference an Experimental spec. Which is allowed to
change more dramatically, as Experimental. Equally as bad, or worse,
right? Pick your own poison, right? :-)
Personally, I suspect compatibility risk is lower if I wait until XEP-0308
goes to Draft, because I already "preplanned" the compatibility in
XEP-0301. In the new version of XEP-0301 (version 0.4) I am about to
submit to Peter, it refers to NO other Experimental standards (just
Draft-or-better), and I've removed some mentions of some Deferred XEP's
from it (i.e. removal of mention of XEP-0286)
For me, this is the biggest showstopper for me -- avoiding referencing
Experimental standards. Especially when I'm trying to prepare XEP-0301 for
inclusion in U.S. and European accessibility documents (i.e.
-- Since you are the primary author -- when do you plan to execute a LAST
CALL for XEP-0308?
Any major changes planned?
-- Any plans to keep the door open to X-line retroactive editing (useful
for transcription captioning corrections)? Or if there's any demand in the
future, perhaps this could be done as a separate "Retroactive Editing" XEP
(with a new disco) that extends both 0301 and 0308? This is very, very
niche, but I see specific use cases in transcription/caption corrections,
court reporting, and other workflows. Anyway, we can both agree to keep to
1-message retroactive editing (to keep 0301 and 0308 in sync), and promise
to work together if there's a future need for X-line retroactive editing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards