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

Mark Rejhon markybox at gmail.com
Thu Jul 19 20:09:57 UTC 2012


On Thu, Jul 19, 2012 at 3:40 PM, Kevin Smith <kevin at kismith.co.uk> wrote:

> 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.
>

Only if it's a good, comprehensive, well-documented XMPP library.

I've also been working with some really crappy XMPP implementations.
Please consider the charity angle too -- Some deaf organizations can't hire
good developers; and may have to stick with crappy XMPP implementations,
that doesn't make it a one-line-of-code check for disco stuff.   I've seen
some quite nasty code out there, too.  (Background info: RTT being a
technology of interest to the deaf, and also Canada had a $300 million
dollar cut to Canadian Hearing Society, and grant money is hard to come by
for deaf development in Canada.)



> > 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.
>

But from my viewpoint, that's not a problem:
-- We already have disco for XEP-0301 and we already have disco for
XEP-0308 !
-- We have no invalid stanzas at all -- if I add it to XEP-0301, then the
namespace is valid.  Then there is no stanzas that the client doesn't
understand, since 'id' would already be documented in the upcoming v0.4 of
XEP-0301 and the business rules of it being allowed to be ignored, is
"complying with XEP-0301 allowing id to be ignored" rather than "an
attribute that I don't understand"

This edge case doesn't need _additional_ disco for such an edge case of
0301+0308 without 0301 retroactive, when the developer has two perfectly
good choices.  The one-line code (for the good XMPP libraries) is not worth
the pollution of 1/3 page of inflation to the document for additional
confusing disco that 99%+ of implementers will never use.  (especially as I
have low-skilled programmers asking me for help about XEP-0301 already -- I
sometimes refer them to the chapter "Basic Real Time Text" at
http://xmpp.org/extensions/xep-0301.html#basic_realtime_text ...)

Right now, I still have mixed feelings about having to comply with XEP-0030
and XEP-0115 (I've now already improved the upcoming v0.4 to include both,
to be similiar in spirit to other XEP's) -- given some situations requiring
a fallback method (refer to earlier discussion).

Right now, I really do not want to complicate 0301 even further with having
two separate disco parameters (including an additonal separate disco
parameter for 0301 retroactive) -- it's already a big spec, and I feel the
edge case is not worth confusing 99% of XEP-0301 readers.   There's been
interest by other people for other parameters that are more important, such
as negotiation of a mutually-agreed transmission interval.  (including
server-negotiated transmission interval, such as automatic rate-limiting
real-time text in MUC, etc).  All presently beyond the scope of XEP-0301
today, and possibly belongs in a future "enhancements" XEP.  Presently,
there are higher priorities at the disco/feature negotiation level at the
moment, and I've excluded them too.

After all, if a developer goes to the effort of implementing 0301 + 0308,
it's quite easy to support 0301 retroactive, anyway.   It might be more
effort for some of you than a one-line change, but it's worth avoiding
confusing 99% of spec readers that won't ever need retroactive 0301 (saving
spec inflation to an already-big spec)


> 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.
>

Ok, agreed.

I am now extending XEP-0301 to support real-time retroactive editing, since
it'll inflate the spec by only approximately two paragraphs or so.   My
goal is to send a v0.4 update to XEP-0301, and ask you to review it to tell
me if you think it's ready for LAST CALL.   If it is, then let's commence,
shall we?  :-)

Thanks
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120719/e438d82d/attachment.html>


More information about the Standards mailing list