[Standards] Link-Local Messaging comments

Peter Saint-Andre stpeter at jabber.org
Wed Mar 21 23:04:11 UTC 2007

Sjoerd Simons wrote:
> On Tue, Mar 13, 2007 at 04:42:04PM -0600, Peter Saint-Andre wrote:
>> Sjoerd Simons wrote:
>>> Actually even before these changes iChat didn't adhere to XEP-0147 (for
>>> instance in the from attribute of it's messages it uses ip addresses 
>>> instead of
>>> logical addresses).  IMHO we shouldn't limit ourselves to the protocol 
>>> iChat implemented. 
>> Agreed. We don't want to break things unnecessarily, but I don't think 
>> anything we've talked about here should break anything. I suppose we'll 
>> find out, though...
> After i updated Salut to the latest revision i did some interoperability
> testing with the latest release of various other clients (Adium, iChat, Gaim
> and Gaijm).
> The biggest breakage is when changing txtvers=1 to txtvers=2. 

I thought that might happen. :)

> In that case
> both Adium and iChat ignore your presence :(  Also i noticed that various
> clients require specific TXT records to be present otherwise your presence is
> also ignored by them.  
> See http://telepathy.freedesktop.org/wiki/SalutInteroperability for details.

Thanks for that.

> It's somewhat unfortunate though that i can't update the txtvers field without
> breaking iChat compatibility.. Which i don't want to do just yet.


> It also made me wonder a little bit about what txtvers actually means. 

I wonder if we even really need it.

> The most
> logical meaning to me seems that newer txtvers only define new records but
> never change the meaning of an existing field (although fields can obviously be 
> deprecated).  
> This is important because it ensures that if a client A with txtvers=12 and a
> client B with txtvers > 12 want to communicate they know they still agree over
> what the TXT records defined in version <= 12 mean. 

That seems sensible. But it still doesn't help with the breakage.

> Also in this case it would be good to annotate all TXT records in the spec with
> an indication of when they were first introduced and/or deprecated. e.g. nick
> is introduced in version 2, port.p2pj is deprecated since version 1 

Yes I will do that.

> One ``crazy'' option to allow clients to update to a newer spec without
> breaking compatibility might be to define a new version field for the TXT
> records and deprecate txtvers. It does make sense a little bit because it was
> never define what a client should do/expect when it saw a txtvers it didn't 
> know about.

Right. But do we even need versioning here? I have my doubts. In that 
case we just leave txtvers at 1 forever and leave it at that.


Peter Saint-Andre
XMPP Standards Foundation

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

More information about the Standards mailing list