On Thu, Jul 19, 2012 at 8:18 PM, Mark Rejhon <marky...@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. /K
