[Standards] Link-Local Messaging comments

Sjoerd Simons sjoerd at luon.net
Sat Mar 17 14:03:12 UTC 2007


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. 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.

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. 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. 

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 



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.

  Sjoerd
-- 
Free yourself from negative influence. Negative thoughts are the old
habits that gnaw at the roots of the soul.
Moses Shongo, (Seneca)



More information about the Standards mailing list