Re: Resource binding

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. 

Re: Resource binding

On Mon Mar  1 13:21:41 2010, chris wrote:
> 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.

But you're likely to be running your own extension anyway to talk to  
these things, so you could make your XMPP client handle the routing  
in other ways than try to break the 1:1 relationship between  
connections and resources.

For instance, XEP-0030 encapsulates individually addressable objects  
within a client perfectly well without introducing multiple resources  
on a single connection.

Dave.
--

-- 
Dave Cridland - mailto:dave <at> cridland.net - xmpp:dwd <at> dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/

Re: Resource binding

On Mon, 1 Mar 2010 14:01:18 +0000, Dave Cridland wrote:
> On Mon Mar 1 13:21:41 2010, chris wrote:
>> 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.
> 
> But you're likely to be running your own extension anyway to talk to 
> these things, so you could make your XMPP client handle the routing 
> in other ways than try to break the 1:1 relationship between 
> connections and resources.

Not quite true... Although I did say this was not IM related, I am 
using XMPP for the core functionality it was built around, namely 
presence and messaging (along with custom extensions) with the 
expectation of being interoperable at a basic level with the 
federated XMPP network.

So, if they are not exposed as a resource then they can not appear as 
a resource to the rest of the network. ie one can no longer naturally 
add them to the roster, get presence information, send messages etc. 
Any generic XMPP client loses the ability to interact with them at 

Re: Resource binding

On Wed Mar  3 14:18:45 2010, chris wrote:
> So, I am not certain what you meant by "individually addressable
> objects within a client" in the context of XEP-0030 as applied to a
> client JID.  I would appreciate some clarifications on that  
> statement.

Pubsub nodes, for instance, are addressable (ie, you can send stuff  
to them) but they share a single jid. This happens not to be within a  
client, but there's plenty of examples of XEP-0030 nodes being used  
for addressing.

If you want your objects to appear as being individually addable to  
rosters, etc, then you do have a problem, but the solution is really  
to use multiple connections, since you'll find it extremely difficult  
to add full jids (ie, ones with a resource) to rosters with most  
clients anyway.

Of course, you could always use the component protocol, which *will*  
give you multiple jids within a domain on a single connection, which  
you can then process how you want.

Dave.
--

-- 
Dave Cridland - mailto:dave <at> cridland.net - xmpp:dwd <at> dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20

Re: Resource binding

On Wed, 3 Mar 2010 15:14:15 +0000, Dave Cridland wrote:
> On Wed Mar  3 14:18:45 2010, chris wrote:
>> So, I am not certain what you meant by "individually addressable
>> objects within a client" in the context of XEP-0030 as applied to a
>> client JID.  I would appreciate some clarifications on that
>> statement.
>
> Pubsub nodes, for instance, are addressable (ie, you can send stuff
> to them) but they share a single jid. This happens not to be within a
> client, but there's plenty of examples of XEP-0030 nodes being used
> for addressing.

For a client, XEP-0030 nodes aren't helpful as they aren't addressable.

In any case, if multiplexing resource bindings do not become standard, 
I've intended to use XEP-0163 for a stripped down feature set, and 
expose the rest via custom extensions.  But I believe that approach 
greatly reduces the usefulness of this system.

> If you want your objects to appear as being individually addable to
> rosters, etc, then you do have a problem, but the solution is really
> to use multiple connections, since you'll find it extremely difficult
> to add full jids (ie, ones with a resource) to rosters with most
> clients anyway.

I'm sorry to hear that... I guess I haven't tested enough clients, but 
the few I have, allowed full JIDs to be added to the roster, per the 
specification, just fine.

Re: Resource binding

On 3/3/10 9:18 PM, chris wrote:

> I still haven't read any reasonable argument against multiplexed resource 
> binding.  The two main points made are "it complicates the protocol" and 
> "for what purpose".
> 
> To the first point, it was a very simple change to the protocol in my 
> perception and OPTIONAL (unfortunately) at that.
> 
> To the second point I think this and other threads have answered that 
> question, but essentially it boils down to allowing the only type of XMPP 
> entity, a client, that does not require DNS and custom server support to 
> be something besides an instant messenger or a one off implementation 
> that is only useful within its own network.

As I've already said, if you and other people care about multiplexing
resources on a single XML stream, then write a document defining how it
works and propose it for consideration. Basically all you need to do is:

1. Copy the XML for XEP-0193, as described at
http://xmpp.org/xsf/sourcecontrol.shtml (sorry, the SVN viewer is broken
right now but you can find the XML through git or directly via SVN checkout)

2. Perhaps factor in some of the differences that might be found in
older versions of draft-saintandre-rfc3920bis, such as:

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

3. Change the namespace for the unbind feature (or perhaps we should
call it "multibind") to something like urn:xmpp:multibind:0 in

Re: Resource binding

On Wed, 3 Mar 2010 21:56:43 -0700, Peter Saint-Andre wrote
> On 3/3/10 9:18 PM, chris wrote:
>> I still haven't read any reasonable argument against multiplexed resource
>> binding. The two main points made are "it complicates the protocol" and
>> "for what purpose".
>>
>> To the first point, it was a very simple change to the protocol in my
>> perception and OPTIONAL (unfortunately) at that.
>>
>> To the second point I think this and other threads have answered that
>> question, but essentially it boils down to allowing the only type of XMPP
>> entity, a client, that does not require DNS and custom server support to
>> be something besides an instant messenger or a one off implementation
>> that is only useful within its own network.
>
> As I've already said, if you and other people care about multiplexing
> resources on a single XML stream, then write a document defining how it
> works and propose it for consideration. Basically all you need to do is:

Peter, thanks for the heavy lifting and foot work in laying that out for us. 
I certainly care, so we will have to see where this takes us.

regards,

chris

 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.

Re: Algorithms and XMPP

Sorry about the late reply, I had been quite distracted by others
things this week.

On Sun, Feb 21, 2010 at 8:18 PM, Sebastiaan Deckers <cbas <at> pandion.im> wrote:
>
> Problems with reference implementations:

I should note that while I think reference implementations are a good
idea, I wasn't suggesting an official reference implementation (not
that I wouldn't be happy for having some)..

And we seem to mean entirely different things by the phrase 'reference
implementation'. I think you misunderstood what I proposed. I'll just
point to the Wikipedia article:
http://en.wikipedia.org/wiki/Reference_implementation_(computing)

Your points about official reference implementations are incorrect however:

> - Programming language dependent (eg. does a Python reference
> implementation help an Erlang developer?)

Yes it does. I'll explain below.

> - Platform dependent

It should be reasonably platform independent. It would be useful even
if it weren't, but more useful when it is.

> - Not subject to same design goals as other implementations

Re: Resource binding

Dnia 2010-03-01, pon o godzinie 05:21 -0800, chris pisze:
> The ability to multiplex multiple resources is certainly desirable. 
> It is too bad that it has missed the core spec at this point.
[...]
> It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :) 

Peter promised to resurrect this as a XEP, so you should have an option
of using the server supporting this XEP.

_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe <at> jabber.org
_______________________________________________

Re: Resource binding

On 3/4/10 5:43 AM, Tomasz Sterna wrote:
> Dnia 2010-03-01, pon o godzinie 05:21 -0800, chris pisze:
>> The ability to multiplex multiple resources is certainly desirable. 
>> It is too bad that it has missed the core spec at this point.
> [...]
>> It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :) 
> 
> Peter promised to resurrect this as a XEP, so you should have an option
> of using the server supporting this XEP.

I don't know that I promised to do this. :) I think it would be great
for us to define this and I've provided most of the pieces, *but* I am
extremely busy these days and I don't have time to work on every XEP
anymore, so I am encouraging other people to take over some of this
work. Resurrecting and slightly modifying XEP-0193 seems like a good
opportunity for someone to help out.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev