[jdev] Resource binding
jugg at hotmail.com
Mon Mar 1 07:21:41 CST 2010
On 1/24/10 5:43 AM, Jonathan Dickinson wrote:
> You can 'multiplex' multiple resources into one stream. Not sure
> about server support though.
On 2010-01-24, 20:55 -0700, Peter Saint-Andre wrote:
> we removed the protocol for multiple resources over a single stream
> from draft-ietf-xmpp-3920bis because list consensus led me to think
> that people believe it is unnecessary and too complicated.
On 2010-01-25, 14:40 -0700, Peter Saint-Andre wote:
> The multi-resource stuff seemed like a good idea at the time but
> people on the XMPP WG discussion list were concerned about adding
> complexity. We could, of course, still define it as an XMPP
> extension if there's interest.
On 1/30/10 9:22 AM, Tomasz Sterna wrote:
> One may always establish multiple connections to bring up more
> resources. But I think resource binding is way simpler method.
On Thu Feb 11 22:12:12 CST 2010 Justin Karneges wrote:
> Also, the feature seemed to come out of left field. Maybe I missed
> the discussion, but to me it felt like this feature was just a case
> of "Why Not?" rather than being born from real necessity. That
> doesn't make it a bad thing, but I want to remind that we should be
> conservative about our changes to the core specs.
The ability to multiplex multiple resources is certainly desirable.
It is too bad that it has missed the core spec at this point.
Strange however, that draft-ietf-xmpp-3920bis-04 still contains the
text in section 1.1 Overview:
"Defined of optional support for multiple resources over the same connection"
Yet no where in that draft revision does it discuss multiple resources
anymore. The last draft I could locate this in is:
Anyway, my use case for this is generalized as such, and is not IM related:
An internet connected client exists for node at example.com, this client
is the interface to many non internet enabled clients which are
identified by resources node at example.com/x1,x2..xn, where n could be a
fairly large number. As x1..xn are all associated in a particular way
for this use case, it makes sense (for reasons not here explained) that
they are connected using a single bare JID, besides the fact that
maintaining many streams/connections is certainly not ideal and even
It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :)
I imagine that as XMPP moves further passed the IM world, these types
of needs will become more apparent. It is unfortunate a forward looking
update to the protocol was axed for the lack of understanding its use
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
More information about the JDev