<div class="gmail_quote">On Thu, Jul 19, 2012 at 4:17 PM, Peter Saint-Andre <span dir="ltr"><<a href="mailto:stpeter@stpeter.im" target="_blank">stpeter@stpeter.im</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Why do organizations for the hearing-impaired need to write their own<br>
libraries in order to write their own clients? Just use one of the<br>
existing open-source libraries. That's what libraries are for, after all.<br></blockquote><div><br></div><div>Fair comment -- it's certainly is considered a borderline reason :-)</div><div><br></div><div>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 ...</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>     It'll prevent stanzas being sent to a client that it doesn't understand.<br>


><br>
><br>
> But from my viewpoint, that's not a problem:<br>
> -- We already have disco for XEP-0301 and we already have disco for<br>
> XEP-0308 !<br>
> -- We have no invalid stanzas at all -- if I add it to XEP-0301, then<br>
> the namespace is valid.  Then there is no stanzas that the client<br>
> doesn't understand, since 'id' would already be documented in the<br>
> upcoming v0.4 of XEP-0301 and the business rules of it being allowed to<br>
> be ignored, is "complying with XEP-0301 allowing id to be ignored"<br>
> rather than "an attribute that I don't understand"<br>
><br>
> This edge case doesn't need _additional_ disco for such an edge case of<br>
> 0301+0308 without 0301 retroactive, when the developer has two perfectly<br>
> good choices.  The one-line code (for the good XMPP libraries) is not<br>
> worth the pollution of 1/3 page of inflation to the document for<br>
> additional confusing disco that 99%+ of implementers will never use.<br>
>  (especially as I have low-skilled programmers asking me for help about<br>
> XEP-0301 already -- I sometimes refer them to the chapter "Basic Real<br>
> Time Text"<br>
> at <a href="http://xmpp.org/extensions/xep-0301.html#basic_realtime_text" target="_blank">http://xmpp.org/extensions/xep-0301.html#basic_realtime_text</a> ...)<br>
><br>
> Right now, I still have mixed feelings about having to comply with<br>
> XEP-0030 and XEP-0115 (I've now already improved the upcoming v0.4 to<br>
> include both, to be similiar in spirit to other XEP's) -- given some<br>
> situations requiring a fallback method (refer to earlier discussion).<br>
><br>
> Right now, I really do not want to complicate 0301 even further with<br>
> having two separate disco parameters (including an additonal separate<br>
> disco parameter for 0301 retroactive) -- it's already a big spec, and I<br>
> feel the edge case is not worth confusing 99% of XEP-0301 readers.<br>
> There's been interest by other people for other parameters that are more<br>
> important, such as negotiation of a mutually-agreed transmission<br>
> interval.  (including server-negotiated transmission interval, such as<br>
> automatic rate-limiting real-time text in MUC, etc).  All presently<br>
> beyond the scope of XEP-0301 today, and possibly belongs in a future<br>
> "enhancements" XEP.  Presently, there are higher priorities at the<br>
> disco/feature negotiation level at the moment, and I've excluded them too.<br>
><br>
> After all, if a developer goes to the effort of implementing 0301 +<br>
> 0308, it's quite easy to support 0301 retroactive, anyway.   It might be<br>
> more effort for some of you than a one-line change, but it's worth<br>
> avoiding confusing 99% of spec readers that won't ever need retroactive<br>
> 0301 (saving spec inflation to an already-big spec)<br>
><br>
><br>
>     > If we can agree to call a simultaneous LAST CALL before the end of<br>
>     this<br>
>     > month (I was hoping for earlier, but there's been so much<br>
>     discussion), so we<br>
>     > can bring both 0301 and 0308 to Draft status roughly<br>
>     simultaneously -- I<br>
>     > will go ahead and immediately add the 'id' parameter to XEP-0301.<br>
><br>
>     I'm happy to ask for LC on 308.<br>
><br>
> Ok, agreed.<br>
><br>
> I am now extending XEP-0301 to support real-time retroactive editing,<br>
> since it'll inflate the spec by only approximately two paragraphs or so.<br>
>   My goal is to send a v0.4 update to XEP-0301, and ask you to review it<br>
> to tell me if you think it's ready for LAST CALL.   If it is, then let's<br>
> commence, shall we?  :-)<br>
<br>
Sounds good!<br></blockquote><div><br></div><div>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...</div>

</div>