[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
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
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.
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'>
> 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