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

Dave Cridland dave at cridland.net
Tue May 29 20:39:39 UTC 2007


On Tue May 29 19:31:27 2007, Mridul Muralidharan wrote:
> 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?
>> 
>> 
(I had a quick skim to find the discussion mentioned, too, and 
couldn't find it. A more specific pointer would be great. I'm 
assuming this has something to do with being able to probe for the 
status on online resources, if the full jid is known, in which case 
randomness seems like a worrisome solution)


>>> 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 
>> don't see the problem with making any part of it look nice.
> 
> My bare jid is my 'address' in xmpp and so not opaque.

No, sorry, it's still opaque. The user portion of your bare jid does 
not mean anything outside the context of your bare jid, and means 
little to anyone outside your domain except as an opaque string. For 
some reason, though, we're all happy to have usernames that are human 
readable, and moreover human identifiable. Perhaps we should make all 
those be hex digits - it might save us from identity theft, so 
there's a solid, security-based reasoning here.

Similarly, the domain portion consists of labels which are opaque, 
although paradoxically many of those opaque labels have a 
well-defined meaning, and even those which do not are highly sought 
after, and/or treated as if they do. But they're still opaque to 
clients and servers - neither my DNS resolver nor my web browser 
thinks that www indicates an HTTP service, even though I tend to 
assume it does. Should I look forward to Sun's impending announcement 
that, due to the opacity of domain labels, they'll be henceforth 
changing their domain to a 40 digit hex number?


> In my business card, I could put my bare jid and that would be a 
> means of reaching me : just like my emailid/etc - but I doubt if 
> anyone would put their full jid :)

Your emailid (I'd call it an email address, perhaps I'm 
old-fashioned) is also opaque. I'll skip over the reductio ad 
absurdum of the domain, and concentrate on the local-part, which is 
opaque outside the domain.

Subaddressing - the closest parallel to resources in email - is 
commonly used to infer more precision about the destination of the 
email. So, for example, mridul+xmpp at sun.com would be, if seen, 
assumed by many to also end up in one of your mailboxes, although 
there's no specification at all that says so.

Similarly to a user-defined resource string, this is primarily used 
by the "power user" end of the email user spectrum, but that's in no 
small part because of the vanishingly small amount of documentation 
on the practise. Resource strings in jids, however, are well 
documented, often available to users through GUIs, and nearly 
homogeneously deployed throughout the network.


> There is a specific meaning associated with bare jid which is 
> outside the context of a single session.
> 
> 
And there's no specific meaning to a resource string, outside of a 
single session, I agree. That doesn't mean that, given an agreed upon 
pattern (or an observed one), a user cannot infer some meaning, and 
moreover, that that meaning cannot be useful.

The meaning we typically infer is that a resource is often used to 
identify a particular client instance across sessions, thus given a 
conversation with me at dwd at jabber.org/Office where I mention I'm in 
my office, it is reasonable to infer that dwd at jabber.org/Office is me 
at my office. That resource string could be anything, but it helps if 
its memorable to humans, and ideally mnenomic in some way.

Now, it's perfectly reasonable to avoid displaying the resource 
string to the user, and it's even reasonable (in as much as it 
follows the spec) to have the server override any resource supplied 
by the client. But I still hold that to do so is losing a 
human-to-human facility that's actively used and felt to be important.

Moreover, if you look at the demand for this sort of thing in email - 
where you get largely ad-hoc systems like subaddressing popping up - 
this is the kind of thing that's much neater to have in the system 
inherently than bolted on afterward.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list