On Tue, Jul 17, 2012 at 10:38 PM, Mark Rejhon <[email protected]> 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. /K
