[Standards] Link-Local Messaging comments

Sjoerd Simons sjoerd at luon.net
Tue Mar 13 22:14:52 UTC 2007

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

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

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. 

Base 8 is just like base 10, if you are missing two fingers.
		-- Tom Lehrer

More information about the Standards mailing list