[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
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
>>> 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
>>> MUST NOT be used as an undefined publishing channel between users"
>>> (perhaps it should?). However it does say, "A resource identifier
>>> 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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards