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

Ian Paterson 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 
after Peter's:

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

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

- Ian

More information about the Standards mailing list