On Thu, Jul 19, 2012 at 3:32 AM, Kevin Smith <[email protected]> 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 > 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. > 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 incompatibilities.... > 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. www.access-board.gov) -- 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. Thanks Mark Rejhon
