[Standards] Link-Local Messaging comments

Peter Saint-Andre stpeter at jabber.org
Tue Mar 13 22:42:04 UTC 2007

Sjoerd Simons wrote:
> On Tue, Mar 13, 2007 at 01:29:06PM -0700, Justin Karneges wrote:
>>>>   In section 6 it says that the stream opening should have no 'to' or
>>>> 'from' attributes. Which is kinda unfortunate. This means that when
>>>> someone opens a new connection to me, the only information i have is the
>>>> ip the connection originated from. If the machine where the connection
>>>> originated from has multiple presence, i'll have to wait untill the first
>>>> stanza containing a 'from' attribute is received before i can link a
>>>> connection to a presence.. If there would be a 'from' attribute in the
>>>> stream opening, it would obviously be much easier/elegant.
>> That's how the protocol works though.  If you depend on this attribute being 
>> present, then you'll lose iChat compatibility.
>> IMO, it makes a lot of sense for the stream to not identify a particular 
>> account during the initial negotiation.  Like s2s, Link-local simply links 
>> two systems, and identification of accounts is better placed in the stanzas 
>> themselves (which allows multiplexing of one TCP connection for many stanza 
>> senders/receivers).
> In practice each contact on a machine is from a different user, each running
> their own client..  Making multiplexing stanzas from multiple contacts over 1
> tcp connection is rather unpratical. 
> Personally i think that multiplexing messages from multiple contact over one
> tcp connect will just make things unnecessarily complicated without any real
> benifits.

Agreed. Unless someone can make a strong argument for it, I say let's 
avoid that complexity.

>> Unfortunately, iChat doesn't multiplex chats over one connection like this.  
>> Instead, it explicitly ties a TCP connection to a contact.  For example, 
>> closing a TCP connection is considered to have a meaning similar to 
>> the "Gone" XEP-85 chat state.  Weird...  but this is how iChat works.
>> So, as much as we can talk about better ways of doing Link-local (what you 
>> did), or assumptions/possibilities about the current design (what I just 
>> did), it's all kind of moot if we want to retain iChat compatibility.
> 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...

> Keeping iChat compatibility is currently mostly about how liberal in handling
> what your receive in your application.. For example currently salut adheres
> strictly to the previous revision of XEP 0174, but it is still liberal enough
> for what it receives to be compatible with iChat. To be honest i did't yet 
> test what iChat does when you send it a stream opening with to/from and
> <stream:features />, hopefully it'll just ignore it. 

IMHO, if people follow Postel's Law then we should be fine. :)


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/20070313/46110023/attachment.bin>

More information about the Standards mailing list