[jdev] Question about resource binding to server implementors

[Vinod Panicker]

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'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <resource>someresource</resource>
     </bind>
   </iq>

<snip/>

   When a client supplies a resource identifier, the following stanza
   error conditions are possible (see Stanza Errors (Section 9.3)):

<snip/>

   o  The provided resource identifier is already in use but the server
      does not allow binding of multiple connected resources with the
      same identifier.

<snip/>

   Resource identifier is in use:

   <iq type='error' id='bind_2'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <resource>someresource</resource>
     </bind>
     <error type='cancel'>
       <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>
   </iq>

>From RFC 3921, Section 3

   Step 1: Client requests session with server:

   <iq to='example.com'
       type='set'
       id='sess_1'>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
   </iq>

<snip/>

   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.

<snip/>

   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.

<snip/>

   Step 2 (alt): Server informs existing active resource of resource
   conflict (case #1):

   <stream:error>
     <conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
   </stream:error>
   </stream:stream>

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.

Regards,
Vinod.

PS: "Reading too much into the spec" meaning?