[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
ian.paterson at clientside.co.uk
Tue May 29 22:48:31 UTC 2007
Justin Karneges wrote:
> On Tuesday 29 May 2007 8:39 am, Ian Paterson wrote:
>> Dave Cridland wrote:
>>> I see no technical advantage in changing [resources] to a random string.
>> Well, how about the advantage that random resources seem to be the only
>> feasable way to avoid presence leaks? (see previous posts)
> This could use more explanation. Do you have a previous post to refer to?
Well this thread seems to be out of order in the mail archive.
I recommend reading all the posts with the same Subject as this thread
And up to and including Peter's:
For example, here is Mridul's reply to Peter's suggestion:
Here is Mridul's reply:
Here's Peter's conclusion 4 days later:
>> Admittedly RFC 3920 does not specifically say, "A resource identifier
>> MUST NOT be used as an undefined publishing channel between users"
>> (perhaps it should?). However it does say, "A resource identifier is
>> opaque to both servers and other clients".
> The resource is opaque, but technically so is the whole JID.
I agree with Mridul, the bare JID is not opaque, it goes on your
> I don't see the problem with making any part of it look nice.
Well, until recently I didn't see the problem either, as long as a
client that does that explains to its user that many of their contacts
will never see the resource string she types (because several clients
never show the resources to their users).
But then Peter pointed out that random JIDs are probably the best (only
feasable?) way of preventing presence leakage. And I became strongly
convinced that nice resources are a big problem.
I also note that those clients that assume other clients' resource
strings are overloaded with some non-opaque meaning are often displaying
random strings to their users!
As Mridul said, overloading in a non-standard way is always a bad idea.
Eventually things break.
> Then how would you handle multiple resources in a client, and without PEP?
From disco/caps the client learns type="phone" or name="Psi". If two
resources of a contact have the same identity then the receiving client
could display an index (e.g. "Psi 1", "Psi 2", "Phone").
Of course many clients and servers have implemented PEP now (and we are
developing standards for the future), but if you still haven't got PEP
then geoloc <description/> also works with <presence/> or <iq/>. It's
not recommended for bandwidth reasons, but it works. You still get: "Psi
Office" , "Psi Home" and "Phone".
> Keep in mind that resources have been around for years and years now. You
> can't say that displaying the resource value is an incorrect practice.
You can always depricate a practice and make it "obsolete". I think we
have a strong case for that:
1. not all clients overload the resource, so we will simply be
standardising an existing practice without introducing any new
2. the resource was supposed to be "opaque" anyway
3. perfectly good standards exist to provide the location functionality
4. if we don't depricate then we'll have to come up with another way of
protecting people's presence (privacy).
More information about the Standards