[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
ian.paterson at clientside.co.uk
Tue May 29 11:17:52 UTC 2007
Adam Nemeth wrote:
> 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
> unavailable resource.
IMHO this can been seen as a server implementation issue. Although using
the same resource would fix the specific scenario you describe, it does
not address the fundamental problem. The server should realise that the
TCP connection to the high priority resource is down (i.e. that the
resource is offline) when it fails to deliver the message (XEP-0198 may
be necessary if proxies are involved). It should then try delivering the
message to another resource instead.
In summary, fixing resource names is not the right way to solve this issue.
> 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.
The resource is not well suited and should not be overloaded to provide
this sort of functionality. Use entity caps instead: see disco <identity
category='client' type='phone'/> and <identity category='client'
type='pc'/>. We might want to define a new disco feature for "funny
link" support too ;-)
> 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.)
IMHO clients should not allow users to set the resource string at all.
The purpose of the resource should be purely architectural (i.e. to
enable one account to make multiple simultaneous connections). Some
clients have historically overloaded the resource by making it into a
user interface feature, or into a product advertisement for the client.
But IMHO we need to strongly discourage such overloading going forward.
The presence <status/> string allows users to express themselves (we can
define more protocols if necessary), while XEP-0092 (Software Version)
allows clients to advertise themselves.
More information about the Standards