[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
dev.list at mircea.bardac.net
Sat May 19 12:28:31 UTC 2007
On Saturday 19 May 2007 11:14:15 Ian Paterson wrote:
> Yes you're right. 3920bis should strongly recommend random resource
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
- 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).
More information about the Standards