[jdev] Detecting multiple resource connections

[Peter Saint-Andre]

On Tue, Apr 26, 2005 at 02:43:00PM -0700, Justin Karneges wrote:
> On Tuesday 26 April 2005 02:09 pm, Peter Saint-Andre wrote:
> > On Tue, Apr 26, 2005 at 05:35:54PM -0300, Carolina Ardohain wrote:
> > > Is there a way to detect multiple resource connections? I want to run
> > > a bot that connect to the server but it need to detect if connected
> > > with same resource and try to connect again with other.
> >
> > If you try to log in as a resource and that resource already is logged
> > in, most servers will boot the old resource and connect the new one.
> >
> > It's rather hard to discover if a resource is being used if you're not
> > connected. You would need to connect (and thus provide a resource)
> > before you could query anything via XMPP. And at that point it is too
> > late, no?
> 
> Conceivably we could create a query-protocol for this, now that authentication 
> and resource binding are separate steps.

Sure, once a server implementation supports resource binding, it 
could provide a way for an authenticated entity to find out what 
other resources already exist. We already have a way to do that
using service discovery -- just send a disco#items request to the
bare JID (which in this case will be the bare JID for your own 
account). Whether an implementation allows you to disco your own
bare JID before you bind a resource is an open question. Currently
RFC 3920 says:

   If, before completing the resource binding step, the client attempts
   to send an XML stanza other than an IQ stanza with a <bind/> child
   qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the
   server MUST NOT process the stanza and SHOULD return a
   <not-authorized/> stanza error to the client.

Possibly the meaning of "send" is ambiguous here -- if it means "set
a 'to' address other than your own JID with the intent that it will
be delivered to some other entity", then sending an IQ to your own 
bare JID would be OK. Perhaps this is something to clarify when we
get around to rfc3920bis.

/psa