[jdev] Question about resource binding to server implementors

[Michal Vaner (Vorner)]

Dne úterý 28 březen 2006 11:08 Alexey Nezhdanov napsal(a):
> В сообщении от Вторник 28 Март 2006 10:45 Vinod Panicker написал(a):
> > On 3/28/06, Alexey Nezhdanov <snake at penza-gsm.ru> wrote:
> > > В сообщении от Вторник 28 Март 2006 09:06 Vinod Panicker написал(a):
> > > > Hi,
> > > >
> > > > Just wanted to check with the server implementors - Do you allow
> > > > multiple "connected" resources with the same resource identifier?
> > > >
> > > > If yes, how do you handle delivery of <iq/> stanzas addressed to the
> > > > full jid of the user.
> > > >
> > > > If no, how do you handle it when a client connects with a resource
> > > > identifier that is already in use?
> > >
> > > xmppd.py not allows that and drops previous connection with <conflict/>
> > > stream error.
> >
> > According to RFC 3920, in this case, the server should return a
> > <conflict/> to the new connection.
> >
> > From 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>
> >
> >    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>
> >
> > Note that the <conflict/> error is sent to the new resource and not
> > the currently connected one.
>
> Well, I just do not remember. Probably it behaves exactly then. I have
> leaved xmppd.py long ago, but at that time I was consulting with RFC for
> every case.
>

Hm, I found this: 
Client asks server to bind a resource: 
<iq type='set' id='bind_1'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>

A server that supports resource binding MUST be able to generate a resource 
identifier on behalf of a client. A resource identifier generated by the 
server MUST be unique for that <node at domain>. 
If the client wishes to specify the resource identifier, it sends an IQ stanza 
of type "set" that contains the desired resource identifier as the XML 
character data of a <resource/> element that is a child of the <bind/> 
element: 
Client binds a resource: 
<iq type='set' id='bind_2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>someresource</resource>
  </bind>
</iq>

Once the server has generated a resource identifier for the client or accepted 
the resource identifier provided by the client, it MUST return an IQ stanza 
of type "result" to the client, which MUST include a <jid/> child element 
that specifies the full JID for the connected resource as determined by the 
server: 
Server informs client of successful resource binding: 
<iq type='result' id='bind_2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>somenode at example.com/someresource</jid>
  </bind>
</iq>

A server SHOULD accept the resource identifier provided by the client, but MAY 
override it with a resource identifier that the server generates; in this 
case, the server SHOULD NOT return a stanza error (e.g., <forbidden/>) to the 
client but instead SHOULD communicate the generated resource identifier to 
the client in the IQ result as shown above.

Tha most iportant thing seems to be at the end - the best way to handle it is, 
in my opinion, to accept the resource if it is not used, or return something 
differet, like the resource itself appended by some random string, is it is 
already used. It would still behave OK for the users that care about the 
resource, it would not close the connection for users who do not care about 
them.

-- 

Ostatně soudím, že uzavřené protokoly a formáty by měly být zničeny, stejně 
jako Kartágo.

Michal Vaner (Vorner)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20060328/3c63bcb9/attachment-0002.pgp>