On Thu, Jul 19, 2012 at 9:44 AM, Mark Rejhon <marky...@gmail.com> wrote: > On Thu, Jul 19, 2012 at 3:32 AM, Kevin Smith <ke...@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.
I had not meant that every RTT element would have an id in it, but that every RTT element that is part of a correction would include the id it's part of the correction for. So no id) I'm RTTing a new message id) I'm RTT correcting the message referred to by id. > 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? If I was to implement 301 and 308, but not RTT correction (the intersection), another client would send me RTT corrections - a significant number of stanzas that I'll then ignore. I won't fail in any interesting way (although the UX will be quite odd), but we generally try to design protocols that don't send unsolicited stanzas that the recipient will be unable to process (or will misinterpret). >> > 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? :-) A not unreasonable point. > -- Since you are the primary author -- when do you plan to execute a LAST > CALL for XEP-0308? I'm not opposed to requesting one ~=now, if it's useful. > Any major changes planned? No, just wordsmithing - it's deployed, it works, I don't see anything that needs changing right now. > -- 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. Given the way the 308 is, and the proposed approach for 301, I don't see any problems with editing messages X old - it's just a case of having an agreed feature for discovery. The community weren't fond of the feature so I left it out of 308, but that's all that's needed in the future. /K
