On Tue, Oct 7, 2008 at 8:27 PM, Justin Karneges <[EMAIL PROTECTED]> wrote: > On Tuesday 07 October 2008 11:57:21 Justin Karneges wrote: >> question whether the extra complexity of having two values instead of one >> is worthwhile. > > And on that note, the best argument *I* personally see in having two values is > with regard to usability: > - Most users don't want to have to specify a name for their connection. > - It should be possible to name a connection for those that desire to. > - We shouldn't use the resource for the connection name, since the resource > is a required field and most users won't know what to put for it. > - Server should supply a randomly-assigned resource for all connections. > - Users may optionally name their connections using a separate attribute > (one proposed way is disco identity name). > - Clients should not display resources of other contacts, since resources > are useless values. Instead, they should only display the separate name > attribute if applicable. > - There ought to be a mechanism in place to prevent two named connections > from having the same name. >
In the whole I agree. Only I think people are being too radical :) We are discussing 3 issues here: 1) Static resources, or dynamic? 2) User-generated, client-generated or server-generated? 3) Regardless of what we decide for the above two, people want human-readable labels for connections == Regarding #1: Static or dynamic? == I think we are (mostly) agreed that static resources can be a problem (some users may not care, but some do, so it *is* a problem). Note however that we have all the mechanisms in place for a safer system already, there is no need to reinvent the wheel with a new protocol and what-not, wait for servers to implement it, and by the time they do, have us all change our minds again. We need to recommend that end-user IM clients don't set a resource by default, so that they have the server generated resource. == Regarding #2: Who generates the resource? == Why do we need to set this in stone for everyone? Right now we have it worked out perfectly. Clients who want a secure, unique, random identifier simply ask the server to assign them one. Clients who instead want a well-known (for routing purposes) or a human-readable (maybe a bot would want this) resource can easily ask for it. No changes to the protocol required. == Regarding #3: Human-readable identifiers for connections == I don't think we should be overloading disco/caps for this, it's not what it was designed for. If people want to discuss a protocol to solve that issue, **please start a new thread**. More threads are good, long threads lose focus :) Matthew.
