> Ok, I can understand your suggestions now. However, you're missing one > point: What advantage do we get by a resource that has no meaing? IMO, > nothing. A static resource just makes it easier for everyone, IMO. Replacing > the connection, etc.
- Resources are freely chosen by servers and clients. Displaying the resource name to the user might work for some client/server combinations, but may be completely useless for others. The <identity> string on the other hand is meant to be human readable. - A client can easily translate identity strings into the language of the user (and back). With resources, you don't know where the human readable part is (if any). - When a user accidentally forgets to set/change the resource string, he will always kick out his other connected resource, and doesn't really know why. Imagine a user setting both his work laptop and work pc to type 'Work', and imagine his amazement to find out that he can't name them both work (if he can even figure out that's the problem why he keeps on getting disconnected). So, I agree with Pedro that resources should be opaque, and that what we currently abuse resource names for (mainly historical because not many clients did much disco'ing before caps). However, that's orthogonal to the original point: If you ask for a specific resource, I assume you know what you're doing, and the server should respect that. I think that using some kind of micro id for resource name is the easiest and best way to avoid the reconnection problems, and in the mean time avoid the problem with multiple resources kicking each other out (just because the user happened to name his location the same). cheers, Remko
