On 8 March 2010 15:52, Tomasz Sterna <[email protected]> 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". > > "If you don't like it, then don't use it." is not a technical argument. >
Agreed, I don't pretend it to be - but my argument wasn't quite that. It was "if you can't implement it, don't". From what you described it sounds like you don't have access to the client's IP address - which means without changing that you could never implement a XEP like this. > I pointed a deficiency in the tight coupling approach. This is not an > immediate danger, but a possibility of hurting us in the future. > How would you propose to do it without "tight coupling"? > > 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. > Indeed, but going through the XSF is preferable. > > 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. Tell me about it (I regularly get asked if we support AMP). > 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. > Such is life. Matthew
