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

Mridul Muralidharan mridul at sun.com
Tue May 29 16:00:43 UTC 2007


This and the earlier reasons Ian brought out make perfect sense imo.
Like I mentioned elsewhere, resource strings are opaque for both the 
client and the server - and associating meaning to them is relying on 
unstable interface. Doing so has interoperability issues, but in 'real 
life' could work ... until it breaks :)

Also, please refer to section 7 of 3920 :
"A server SHOULD accept the resource identifier provided by the client, 
but MAY override it with a resource identifier that the server 
generates; in this case, the server SHOULD NOT return a stanza error 
(e.g., <forbidden/>) to the client but instead SHOULD communicate the 
generated resource identifier to the client in the IQ result as shown 
above."

So any form of meaning a client tries to associate with a resource is 
not wise since the resource can be overridden by the server.


Regards,
Mridul


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)
> 
>> dwd at jabber.org/Office always goes to my desktop computer
> 
> An increasing number of servers offer PEP. So exactly the same 
> functionality (from the user perspective) can be implemented as defined 
> in XEP-0080:
> 
> <geoloc xmlns='http://jabber.org/protocol/geoloc'>
>  <description>Office</description>
> </geoloc>
> 
> 
> IMHO resource identifiers should only be used for what they were 
> designed for (overloading is bad).
> 
> 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". Several clients (IMHO 
> correctly) take that to mean "opaque to others, period". They therefore 
> generate a random resource and they don't display other clients' 
> resources to the user.
> 
> The result is that those clients that assume other clients' resource 
> strings are overloaded with a non-opaque meaning are currently 
> displaying random strings to their users! It also means they mislead 
> their users when they imply that the resource strings their users type 
> will be seen by their users' contacts.
> 
> Users will have a better experience once their clients follow the 
> standards (geoloc etc). Let's work towards the widespread adoption of 
> PEP/geoloc and fix this issue once and for all.
> 
> - Ian
> 




More information about the Standards mailing list