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