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!


Reply via email to