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

[Peter Saint-Andre]

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.

It's easier for people to understand the examples that way.

> 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.

That seems to be an accurate description of what resources "mean" right now.

> --
> 
> A possible solution would be to completely hide the resource string from the 
> users, having it reffered as "resource id".

That is probably best.

> 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 

I don't know that we can make it a MUST, but I agree that it would be 
good to make it a SHOULD.

If we do that, then we should also say how to generate the resource ID 
(e.g., make it a UUID, as we recommend for thread IDs).

> //
> 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)

Probably no good reason for that.

> 2. no resource id should be shown for the users available online - recommend 
> showing geo-loc information as an alternative (for example)

Why show anything? And what other information would be available?

> 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.

I agree -- that behavior is quite confusing.

> 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).

Why do users even need to refer to resource IDs? Many (most?) clients 
hide resource IDs from user, and that seems best.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070522/46510a82/smime-0001.bin