On 3/8/10 8:52 AM, Tomasz Sterna wrote: > Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze: >>> The clean separation of RFC 3920 and RFC 3921 allows this. >>> XEP-0279 breaks this and causes tight coupling of these layers. >> >> On the other hand, if your server implementation has a hard time >> figuring it out, don't support it. > > I always thought that the Standards JIG was created to come up with the > best protocols possible through exchange of technical arguments. So > called "meritocracy".
Publishing version 0.1 of a XEP does not imply standardization of a technology, only the first step of publication so that we can have the kind of discussion we're having now. > "If you don't like it, then don't use it." is not a technical argument. The people who have argued for this extension (mostly Diana Cionoiu and Thiago Camargo) think that it would be helpful in certain situations as either (1) an indicator to the client that it might be behind a NAT and therefore might need to do more work to gather candidates for successful Jingle negotiation, or (2) a method for gathering yet another candidate for things like ICE (in which the philosophy is, the more candidates the better). The fact that Diana and Thiago haven't posted in this thread is unfortunate, but for all I know they are subscribed only to the [email protected] list. > I pointed a deficiency in the tight coupling approach. This is not an > immediate danger, but a possibility of hurting us in the future. So the 0.1 specification might be improved. Thanks. :) > On the other hand, not every XMPP protocol extension needs to be blessed > by XSF and published as XEP. Google has no problems with adding own > extensions to the protocol without asking us for acceptance. And that has been wonderful for interoperability, hasn't it? > Dnia 2010-03-08, pon o godzinie 15:10 +0000, Matthew Wild pisze: >> Yay, I'm not alone in thinking that each implementation need not >> support *every* published XEP :) > > Unfortunately this point of view is not shared by software users. > They tend to compare implementations by counting features. > This leads to a race of implementing every possible XEP, no matter how > silly or useless the idea is. If only we could write a spec that prevented people from being silly. XEP-0148 might help here... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
