[jdev] Resource binding

[chris]

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.

Hello,

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:

http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-10.html#bind-multi

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

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

chris

 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/