On Thu, Jul 19, 2012 at 4:17 PM, Peter Saint-Andre <[email protected]>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 > 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? :-) > > 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...
