Hello,<br><br>On a side note: Openfire does indeed allow you to configure the server in such a way that it will not accept an already-bound resource (#3, in various flavours). This is not the default setting though. By default, it uses option #2 from Wills list (kick the previous connection). You can find the configuration page in Openfires Admin panel, under "Server" > "Server Settings" > "Resource Policy"<br>
<br>Openfire doesn't currently allow you to do #1. I've created a new feature issue for this in our bugtracker: <a href="http://issues.igniterealtime.org/browse/OF-402">http://issues.igniterealtime.org/browse/OF-402</a><br>
<br>Regards,<br><br> Guus<br><br><div class="gmail_quote">On 17 September 2010 19:52, Peter Saint-Andre <span dir="ltr"><<a href="mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Will, you make some good points. I will add some stronger wording to<br>
rfc3920bis on this point after IETF Last Call.<br>
<div><div></div><div class="h5"><br>
On 9/16/10 2:38 AM, Will Thompson wrote:<br>
> Hi,<br>
><br>
> <<a href="http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-7.6.2.2" target="_blank">http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-7.6.2.2</a>><br>
> specifies three legal server responses to a client trying to connect<br>
> with an already-connected resource:<br>
><br>
> 1. Assign the new client a fresh resource;<br>
> 2. Boot the old connection, granting the resource to the new client;<br>
> 3. Refuse the new connection.<br>
><br>
> It recommends 1, which is what (e.g.) Google Talk implements (well, they<br>
> always randomize, but it's equivalent in this case ;-)). I was under the<br>
> impression that no-one did 3, but I discovered that Openfire apparently<br>
> does. <<a href="https://bugzilla.gnome.org/show_bug.cgi?id=629768" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=629768</a>><br>
><br>
> I don't really think behaviour 3 is very useful. Maybe this is a<br>
> function of being interested in mobile stuff, but I believe that the<br>
> most common reason for trying to connect with an already-connected<br>
> resource is recovering from a loss of connectivity. As the above-linked<br>
> bug shows, behaviour 3 means you can't reconnect until the original<br>
> connection times out.<br>
><br>
> So, I think the third behaviour should be strongly discouraged, with<br>
> this rationale. (I suspect making it illegal is not going to fly now.) I<br>
> guess the client can work around this behaviour by retrying with a<br>
> different resource, but this doesn't have the nice property of cleaning<br>
> up dead connections.<br>
><br>
> (Obviously the One True Way to recover from a loss in connectivity is<br>
> XEP-0198, but deployed servers don't all implement this.)<br>
><br>
> Regards,<br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
JDev mailing list<br>
Forum: <a href="http://www.jabberforum.org/forumdisplay.php?f=20" target="_blank">http://www.jabberforum.org/forumdisplay.php?f=20</a><br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/mailman/listinfo/jdev</a><br>
Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org">JDev-unsubscribe@jabber.org</a><br>
_______________________________________________<br>
</div></div></blockquote></div><br>