[jdev] Resource binding limit(ation)

Peter Saint-Andre stpeter at jabber.org
Mon Mar 13 12:48:03 CST 2006

Hash: SHA1

Vinod Panicker wrote:
> On 11/24/05, Vinod Panicker <vinod.p at gmail.com> wrote:
>> On 11/24/05, Norman Rasmussen <norman at rasmussen.co.za> wrote:
>>> I think you can by forcing binding to an existing resource, but I'm
>>> not sure it allows you to force an old resource off and bind a new
>>> one.
>> Wont work since even binding to an existing resource would mean that
>> I'm adding one more connected resource (albeit of a same name).  What
>> I'm asking is - shouldn't this be treated in the same way we treat
>> server provisioning for allowing/disallowing two resources of the same
>> name to be available?
>>> On 11/24/05, Vinod Panicker <vinod.p at gmail.com> wrote:
>>>> According to RFC 3920 -
>>>>    o  The client is not allowed to bind a resource to the stream (e.g.,
>>>>       because the node or user has reached a limit on the number of
>>>>       connected resources allowed).
>>>> Wont it make sense if there is some provision to automatically logoff
>>>> the user from a previous resource (based on server provisioning) if
>>>> he's trying to login from a new resource?
> No closure on this so I'm assuming that we are not allowing any more
> resources to login once the limit has reached, though it would be
> great to have something that allows the server to logoff an existing
> resource to make way for the new one.

Sure, an implementation could do that if it wants. Nothing in the spec
forbids it and you can implement it if you think it's a cool feature.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20060313/168d3073/attachment-0002.bin>

More information about the JDev mailing list