[Standards] Link-Local Messaging comments
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
> 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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards