[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

Kevin Smith kevin at kismith.co.uk
Thu Jul 19 19:40:11 UTC 2012

On Thu, Jul 19, 2012 at 8:18 PM, Mark Rejhon <markybox at gmail.com> wrote:
>> 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).
> That's not true...
> It's 100% backwards compatible!

I didn't claim it wasn't backwards compatible! "I won't fail in any
interesting way"

> Backwards compatible behavior (End User Viewpoint)
> The retroactive real-time edit will temporarily appear as if it was a brand
> new message.   Basically, the real-time message will be a *copy* of the old
> message, while the retroactive edit is taking place.   When the edit is
> finished, the real-time message disappears and the edit shows up above in
> the last message.

Right, it's a bit of a goofy user experience.

> Thus, adding new disco is
> overkill (shooting a fly with a shotgun) when the developer already has the
> full flexibility of choosing these two perfectly reasonable choices,
> correct?  As a result, I'm somewhat stumped why you think disco is necessary
> for this situation.

I'm similarly baffled why you think of disco as a shotgun - this is
the usual XMPP way of doing things - it's so cheap as to almost be
free for a developer - who will need to already have written the code
for handling disco/caps to be able to implement the spec already, and
so this becomes a one-line-of-code check.

> Can you re-explain why you still think disco is needed for the 301+308 case
> without retroactive 301?

It'll prevent stanzas being sent to a client that it doesn't understand.

>> > -- 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.
> It's been less than 12 months since the spec was granted a number.  As long
> as XEP-0001 rules allows it, then this could be a pretty quick LAST CALL for
> an XEP.

To the best of my knowledge, nothing in XEP-0001 says we need to leave
a XEP at Experimental for 12 months before moving it to Draft
(although 12 months /is/ the period after which an inactive
Experimental XEP gets automatically deferred).

> If we can agree to call a simultaneous LAST CALL before the end of this
> month (I was hoping for earlier, but there's been so much discussion), so we
> can bring both 0301 and 0308 to Draft status roughly simultaneously -- I
> will go ahead and immediately add the 'id' parameter to XEP-0301.

I'm happy to ask for LC on 308.


More information about the Standards mailing list