[Standards] NEW: XEP-0279 (Server IP Check)

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 10 05:11:34 UTC 2010

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
jingle at xmpp.org 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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100309/8c714201/attachment.bin>

More information about the Standards mailing list