[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
markybox at gmail.com
Thu Jul 19 20:23:46 UTC 2012
On Thu, Jul 19, 2012 at 4:17 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:
> Why do organizations for the hearing-impaired need to write their own
> libraries in order to write their own clients? Just use one of the
> existing open-source libraries. That's what libraries are for, after all.
Fair comment -- it's certainly is considered a borderline reason :-)
Still, the superior reason is: The other arguments (below) about avoiding
inflating the spec any further for an edge case that doesn't even have
invalid protocol requiring a third disco (other than existing 0301 and 0308
disco) -- since there are going to be no confusing stanzas, if I document
an 'id' attribute in version 0.4 of XEP-0301 ...
> It'll prevent stanzas being sent to a client that it doesn't
> > 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
> > 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? :-)
> Sounds good!
This is going to put a probable one-day delay, but I'm going to try to
submit the updated XEP-0301 tonight :-) Now that Kevin and I agree to
sync up our specs and sync up our LAST CALL...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards