[Standards] resource identifiers: a summary

Peter Saint-Andre stpeter at jabber.org
Thu May 31 18:31:29 UTC 2007

Here is a summary of the recent thread about resource identifiers...

1. The current practice of specifying non-random resource identifiers 
from the client side results in potential presence leaks. No one has 
contested this. So if I always log in as "stpeter at jabber.org/roundabout" 
then people can send IQs to that full JID and perhaps discover if I am 
online, even if they are not in my roster. This seems like a bad thing.

2. Resource identifiers are supposed to be used purely for routing 
purposes and are not supposed to have semantic meaning for any entity on 
the network. If this is not sufficiently clear in RFC 3920 then we can 
make it clearer in rfc3920bis.

3. Most users are blithely unaware of resource identifiers (e.g., 
because they log in with only one client or because their clients hide 
other users' multiple resources from them as too complicated for end 
users to handle), but some power users like resource identifiers and 
also like them to have semantic meaning (foo at bar.com/office is always my 
desktop machine at the office, etc.).

4. We have ways to discover the identity of particular resources, via 
things like the presence <status/> element, Entity Capabilities 
(XEP-0115), Software Version (XEP-0092), Service Discovery (XEP-0030) 
potentially with extensions (XEP-0128), Geolocation (XEP-0080), and so 
on. So power users do have the means to know that some other resource is 
in fact their desktop computer at the office, even without semantically 
meaningful resource identifiers.

5. From my recent reading of the specs, I think that the text about 
resource binding in RFC 3920 and rfc3920bis could be cleaned up, 
especially with regard to handling of user-provided resource identifiers 
as opposed to server-generated resource identifiers. Also I think that 
we should recommend server-generated resource identifiers and specify 
that the resource identifier should be a UUID in string format, such as 
"ca486eba-0f9a-11dc-8835-000bcd821bfb". I will post separately about 
this once I come up with proposed text for this section.

6. Allowing a client to specify the resource identifier is not evil and 
should not be disallowed. So I am not arguing that a server MUST 
generate the resource identifer or override a resource identifier 
provided by the client during resource binding. As long as client 
developers understand the risks involved, let them do what they've 
always done. But we need to add something about this to the security 
considerations in rfc3920bis and perhaps rfc3921bis.

Anything else?


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070531/46e9fcb0/attachment.bin>

More information about the Standards mailing list