[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
kevin at kismith.co.uk
Thu Jul 19 07:32:10 UTC 2012
On Tue, Jul 17, 2012 at 10:38 PM, Mark Rejhon <markybox at gmail.com> wrote:
> (scroll below to see a proposed XEP-0301 modification to gain full benefits
> of XEP-0308)
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.
> One person in our group has been quite determined to see last message
> correction be made compatible with real-time text (i.e. make XEP-0308
> compatible with XEP-0301).
They seem to play fairly well together.
> I am reluctant to further complicate the RTT
> specification, and this can easily be done as a private extension, but the
> situation arises where someone wants to be able to edit the last message "in
> place" in real-time, by knowing which message is being edited.
I don't have strong opinions about whether this should be in 301 or in
an additional XEP. I think that it'd be a fairly short addition to 301
if you wanted to do it that way.
> However, one of the members in the Real Time Text Taskforce has been pretty
> interested in this, despite the high probability that this wouldn't be
> beneficial for public interop the next several years. (And for single
> vendor solutions, it can still be used as a private extension to XEP-0301
> for now, between their own brands of clients for now).
I don't see why RTT-with-correction should take any longer to be
beneficial for interop than RTT is.
> Right now, my opinion is that because I don't even see implementations using
> XEP-0308 yet (not even Pidgin!), I feel it is too early to add this
> capability to XEP-0301. It is my opinion that it is not the end of the
> world, and is only of interest to vendors who want interoperability with
> widepspread clients that has last-message editing. (And right now, that
> doesn't exist yet).
There are at least a couple of mainstream clients that either support
308 or are currently implementing it.
> Does anyone outside the Real Time Text Taskforce, think I should expand the
> 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.
> 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.
> Personally, my opinion is that it is 5 years to early, the one vendor that
> might really need it today, can use a private extension for now, knowing
> that it's backwards compatible.
If it's 5 years to early for this, is it 5 years too early for RTT? :)
> Opinions about updating XEP-0301 to allow the optional id attribute for <rtt
> event='reset'/> elements? (for seamless operation with XEP-0308)?
Whether as an update to 301 or as a new document (and I'm vaguely
inclined to think it may as well go in 301), I think there's value in
speccing this now rather than waiting.
More information about the Standards