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

[Mircea Bardac]

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.

--

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)

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.

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