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 _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
