Hi, On Oct 4, 2008, at 1:18 AM, Matthew Wild wrote:
I thought I recalled some discussion on the lists already regarding this, but I haven't been able to find it. On resource binding, the RFC says the server MAY modify the client's chosen resource. Is there a reason that it doesn't say "If the client provides a resource, the server SHOULD use this" instead? It just seems to me that there are cases where I know I want a specific resource, it is highly annoying to see this changed by the server, and there is nothing I can do about it when I want to. I understand the concerns over presence leaks, but can't we push for this to be fixed on the client side? (ie. don't specify a resource, and warn a user if they do). Reasons to change this: - It makes no sense to say clients MUST warn users, when servers are probably going to be changing the resource anyway - There are times when I know I want a particular resource (usually non-IM situations) - There is no reason that this can't be fixed client-side (by warning users and not sending a resource by default) - It is easier to say to a user "Use a better (ie. more up to date) client" than "Use a more up to date server" (something over which they mostly have no control)
Let me go against the majority opinion and say that I think that the server should always change the resource. The network should always protect the user presence.
The reasons given to use a well-known resource can be solved better using other methods.
For example, the reconnect scenario, where your client looses the connection and wants it back should be solved by a session-reconnect protocol. After logging in, you should be able to resume a previous session, without having to ask for the roster again.
BOSH already has that, and in March/April there was some discussion about moving that to TCP-based sessions also.
As for using the resource as a well-known address for non-IM resources, I've used the same solution in the past, but recently I switched to using disco identities for the same purpose. Given that caps hashes include the identities and capabilities, I can use those to identify the connection I want. If I have a unique <identity> in my bot, I can quickly discover the bot using the <presence> broadcast. The caps hash will be unique for that bare JID.
Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!