[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

Mridul Muralidharan mridul at sun.com
Sat May 19 14:03:23 UTC 2007

Mircea Bardac wrote:
> On Saturday 19 May 2007 11:14:15 Ian Paterson wrote:
>> Yes you're right. 3920bis should strongly recommend random resource
>> identifiers.
> From user's point of view, this doesn't always make much sense, because of the 
> way the term "resource" is perceived by users. Consider everything below as a 
> comment from a *jabber user point of view*.
> In the jabber world, the resource is the way you could connect several times 
> to an account. (Jabber uses priorities to make a difference between 
> the "importance" of a resource)
> The resource is most of the times associated with the place/name of the 
> computer running the client. Some clients assume this in the interfaces. The 
> XEPs assume this in the examples.
> Some Jabber clients have a way of setting this resource string (note that I 
> haven't said "resource name" or "resource id"). Users expect that the 
> resource to be shown somewhere and, most important, to have a meaning.
> Random resource strings confuses users who discover this option in the jabber 
> clients. On connection, some jabber servers offer a resource string 
> (generated with the resource provided by the client) or simply use the 
> resource string provided by the client.

Trying to associate meaning with resource name, imo is a bad idea.
Especially since there is no guarantee that the resource asked for by 
client would be granted to it by the server (server can change resource 
in bind response).
So meaning for resource names is something that was never exposed as an 
interface - it is just an opaque string which identifies an endpoint for 
a bare jid.

Like you mention below, we have other means of identifying 
availability/status/priority, location, etc - resource is not the right 
place for this information.

> --
> A possible solution would be to completely hide the resource string from the 
> users, having it reffered as "resource id".
> The XMPP spec should make it clear that the resource id
> - must have a length of X lower-case hex characters (as mentioned before, say 
> 128 bits)
> - must be randomly generated by the server(xmpp bind) or by the client 
> //
> There should be some kind of XEP with "best practices for using resources in 
> jabber clients" mentioning:
> 1. the resource id should not be editable by the user (could be available as 
> an advanced option though)
> 2. no resource id should be shown for the users available online - recommend 
> showing geo-loc information as an alternative (for example)

There are usecases where it would become necessary for a user to 
explictly chat with a particular resource for a bare jid ... so 
completely hiding it away might break these cases.

> 3. given the use of xmpp bind lately (GTalk), recommend using the same chat 
> window for the same user, if the user quit then returned (=only one resource 
> available all the time), with a warning or something similar (showing new 
> geo-loc if available) - it is very confusing to have a new chat window opened 
> for a contact and still have a window with the offline resource available.

About rebind : shouldn't this not happen in normal case ? Why would a 
user lose a session so frequently ?


> 4. on initial (manual) connection (not on retries), if the client detects 
> other resources of the same user are available and the client priority is 
> lower, in a window:
> - prompt the user that other resources are available
> - show other resources info (status, priority) + ad-hoc commands option
> - suggest using a higher resource number
> This only on initial connection. If the connection fails and reconnection 
> occurs, do not display this.
> *. other UI recommendations might apply
> From the user point of view, it is essential to have a close to uniform jabber 
> experience, at least concerning the major differences compared with other IM 
> systems - such as the resources. 
> This "random resource", as far as I see, has only one drawback - it makes it 
> difficult to reffer to other resources, if there's no other means available 
> (such as geo-loc).
> Comments?
> - Mircea

More information about the Standards mailing list