[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
aadaam at gmail.com
Mon May 28 23:22:53 UTC 2007
Three thoughts on forced randomization of resource IDs:
1) Let's say I'm connected with a given resource ID on a desktop
client, set the priority higher than normal (for example, I needed
this because another resource was temporarily online), and the client
freezes; Now I reconnect. Without random resource IDs, the old
connection is kicked out immediately (with certain server-side
settings ie. in OpenFire); with random resource IDs, some messages
could be lost, since it will be transferred to a higher priority, yet
(Probably I'm wrong on this, IRC had such problems sometimes)
2) Resource strings are the abilities I can be reached: let's say I
have a mobile client, and a desktop client, both online. Since both
are the same place (on my desk), geo-loc is absolutely meaningless,
still they differ; for example, desktop client could be more
comfortable. But if I go to the kitchen, geoloc won't change too much
(if all; given today's GPS), people could know that throwing me a
funny link to my mobile client is worthless, even if it has higher
priority actually (I set it manually, or it was automatically set by
bluetooth range). I know it isn't today's custom, but still I think
this is the very near future, and probably that's why ability for
paralell resources are built in to both XMPP and SIP.
(Summary: resource identifiers will *have* meanings to humans if
they'll be used to multiple resources at the same time)
3) I feel privacy an optional thing - if a client wants to generate a
random resource ID on every connection, go with it; If a service
provider gives random resource IDs if I haven't set one - go with it.
But: If I explicitly state what resource ID I want, I don't want
hexadecimal numbers behind it (yes, I hate this practice of GTalk)
(Summary: I don't like when a program tries to prescribe what's good to me.)
This is my two cents; oh yes, I'm planning to develop a
multi-resource jabber experience :-)
On 5/22/07, Peter Saint-Andre <stpeter at jabber.org> wrote:
> 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 Saint-Andre
> XMPP Standards Foundation
Aadaam <aadaam at gmail.com>
More information about the Standards