[jdev] Question about resource binding to server implementors
vinod.p at gmail.com
Tue Mar 28 22:27:41 CST 2006
On 3/29/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> On Tue, Mar 28, 2006 at 03:20:15PM +0530, Vinod Panicker wrote:
> > Anyways, the point to be clarified that remains is -
> > In case of a connected resource, a new resource with the same resource
> > identifier is to be returned a <conflict/>, whereas in the case of an
> > active resource, a new resource with the same resource identifer is
> > recommended to be allowed to login, returning a <conflict/> to the old
> > resource.
> Where did you get this? I think you're reading too much into the spec.
>From RFC 3920, Section 7
Client binds a resource:
<iq type='set' id='bind_2'>
When a client supplies a resource identifier, the following stanza
error conditions are possible (see Stanza Errors (Section 9.3)):
o The provided resource identifier is already in use but the server
does not allow binding of multiple connected resources with the
Resource identifier is in use:
<iq type='error' id='bind_2'>
>From RFC 3921, Section 3
Step 1: Client requests session with server:
Several error conditions are possible. For example, the server may
encounter an internal condition that prevents it from creating the
session, the username or authorization identity may lack permissions
to create a session, or there may already be an active resource
associated with a resource identifier of the same name.
If there is already an active resource of the same name, the server
MUST either (1) terminate the active resource and allow the
newly-requested session, or (2) disallow the newly-requested session
and maintain the active resource. Which of these the server does is
up to the implementation, although it is RECOMMENDED to implement
case #1. In case #1, the server SHOULD send a <conflict/> stream
error to the active resource, terminate the XML stream and underlying
TCP connection for the active resource, and return a IQ stanza of
type "result" (indicating success) to the newly-requested session.
Step 2 (alt): Server informs existing active resource of resource
conflict (case #1):
This is what I read, and hence the above interpretation. IMHO, like
we have multiple paths for session binding, we should have the same
for resource binding. Possibly that may have been intended - if so,
the spec needs to be updated.
PS: "Reading too much into the spec" meaning?
More information about the JDev