[Standards] Re: [OT] UIs for User Confusion (was: Re: Friendly XMPP Branding)
lists+jabber_standards at bigfatdave.com
Sun Mar 11 11:33:56 UTC 2007
On Fri, Mar 09, 2007 at 12:02:08AM -0800, Justin Karneges wrote:
> On Thursday 08 March 2007 10:58 pm, Dave wrote:
> > I'm not quite sure what exactly you mean by "kind of a rename," but if
> > you mean anything substantial, you're going to run into problems, since
> > there are many IM systems out there, an awful lot of which were around
> > long before Jabber/XMPP/XIM/whatever (and therefore would've earned the
> > "right" to call themselves "IM" first). It's also dangerous to try
> > renaming a protocol into the common name of its category of (possibly
> > yet undiscovered) protocols. Think, for a sec, what would've happened
> > if somebody had decided to rename UUCP into "email." We'd all be stuck
> > trying to explain to people whether we were using an email system called
> > "SMTP," or an email system that attempts to confuse people by calling
> > itself "email."
> Email is a great example to bring up, because it is made of a collection of
> protocols, none of which are irreplaceable components of the overall system.
> If we decided to one day transport email over XMPP instead of over SMTP, we'd
> still call it email, and we'd still invite users to email us from our
> webpages with "mailto:" URIs.
The problem with such a scheme would be that the "irreplaceable" SMTP system
(which the mailto: URI maps into) is incompatible with XMPP. The correct
solution "back in the day" would've been an "smtp:" URI. Then, an "xmpp:" URI
could've been phased in easily. The problem is that "mailto:dave at bigfatdave" is
ambiguous: it doesn't tell you whether you should find the highest priority MX
record for bigfatdave.com and try talking SMTP to it on port 25, or whether you
should do a SRV lookup for a jabberd on bigfatdave.com, and then speak Jabber to
it. Now, as you start adding more competing technologies for transporting mail,
the mail system, as a whole, becomes less efficient. (Think about all the
spurious connections, as mail servers everywhere try to figure out which
transport layer a particular email address is routable through ... and what if
the only available transport happens to be down? Still more spurious
connections will follow.) The mailto: URI was a Bad Thing (TM), and the "im:"
URI is also a Bad Thing (TM). (I wasn't even aware that the IETF was stupid
enough to endorse its usage by ANY protocol.)
> Similarly, RFC 3922 grants XMPP to use the "im:" URI. Of course, any of the
> big boys could submit for this as well, but aside from perhaps SIMPLE, nobody
> is rushing to do so. I'd say that this (and all CPIM conformance) gives XMPP
> clients the right to advertise themselves as plain/standard/whatever IM.
Plain: still no right ... the IETF doesn't decide what's IM and what's not
Standard: still no right ... again, SIP is also an IETF-standardized IM protocol
Whatever: no comment
I suppose you could call Jabber "An IETF Standard IM Protocol," but why? Jabber
has a name, and there's no reason not to use it. If you don't like it for
whatever reason, you're in luck: Jabber has another name. If you don't like
XMPP either, I'd say you're being a tad picky. . .
> Maybe this is unfair to AIM, MSN, etc, who came before, but we have IETF
> authority here.
I don't think that AIM, MSN, etc., should have any authority to use an "im:" URI
at all, since their protocols don't even have a concept of open federation,
rendering them "handicapped."
If we start following the braindead email idea of using a generic URI for a
specific protocol, then when DJB comes out with a better protocol for moving IMs
around, he'll have to be a genius not just at building protocols, but also at
crafting well-known-hacks to make them fit in with the current system
(essentially, an encore of his QMTP MX priority stunt, only this time, he may
have to do some funky SRV magic, except that he believes SRV itself sucks (for
valid reasons), and refuses to touch it, which means he might just decide to not
even attempt to fit into your "standard" IM world, and judging by the success of
his other systems, I don't think it'd be wise to alienate those types of
geniuses, with or without the IETF's blessing). If we all love email so much,
why can't we learn from any of the stupid mistakes we made with it?
> > > Similarly, "Standard IM Address" (again, just an idea) isn't a full-on
> > > rename, but rather more of a show of confidence. :) But with just enough
> > > of an edge that you know it isn't AIM we're talking about.
> > SIP/SIMPLE is also a standard IM system, so "Standard IM" would be
> > nothing but a subgroup of "IM," with at least two members.
> If SIMPLE reaches the point where people actually use it, and neither SIMPLE
> nor XMPP decide to disappear,
Well, SIMPLE isn't likely to disappear anytime soon, since it's built on the
same SIP platform that runs a huge percentage of the world's telecom
infrastructure, and telecom software (and firmware) takes forever to disappear.
> then we'll see dual-protocol servers
Presumably, every server would run both SMTP and QMTP listeners, and clients
would pick their favorite, try it, and if it didn't work, try the other. At
least DJB's arrangement guarantees only one connection attempt except in
pathological cases, where you end up having to try both protocols. I find the
IETF's incompetence quite funny. (If DJB had had the opportunity to create the
standards before the fact, I'm sure he would've given us an elegant solution,
rather than the ugly (yet efficient for all common cases) one he was forced (by
the "mailto:" URI being hijacked as an "smtp:" URI) to create. The IETF should
at least be able to match his after-the-fact solution with all their wizards,
standard-makers, and whoever else they have working there, considering the fact
that they didn't walk in and find the "im:" protocol already hijacked.)
> and possibly dual-protocol clients (or people will select a
> client that does their favorite protocol).
Oh, great ... we can live in a dual-protocol world. Don't you just love high
barriers to entry? It's a great thing when you need to link half a gazillion
libraries to every IM-related program you write. Do you know what else is neat?
It's a whole ton of fun to discover a vulnerability in the world's most popular
IM library, and to spread your malware all over the 'net like wildfire, because
these protocols are do damn complex that most guys don't bother with the hassle
of handcoding support, so you're attacking a homogenious population - a dream
> Like POP3 and IMAP, we may have a
> choice in protocols, but ultimately it's all just IM.
Ah, but POP3 and IMAP have their own URIs, and they're totally separate from the
"mailto:" URI. If I come up with SMAP, it too can have its own URI, and clients
never have to worry about incompatibilities. If the POP3 URI were named
"getmail:" or something like that, we might have had a repeat of QMTP with IMAP.
> However, until SIMPLE usage becomes widespread, I don't think it is necessary
> to have to say "XMPP" when we refer to standard IM.
It is, since as little as SIMPLE is used, it still exists, and the IETF still
endorses its usage as a standard IM, just as standard as XMPP. There's no
Democracy involved in the decision tree, here. Call an apple an apple, not
> XMPP is a redundant
Nope, XMPP is the name of your protocol. If you'd like to rename it IM, that's
a very stupid decision, since it'll only confuse people. "IM" will still only
be "An IETF-endorsed IM Protocol," though. Not only that, but it won't even be
an unambiguous identifier for Jabber, since it's already used as a secondary
identifier for AOL IM. (The IETF can insist from today to next year that IM
means Jabber, but at the end of the day, IM means Instant Messaging, not Jabber,
and everybody knows that. If you can convince Webster to start listing Jabber
as instead of Instant Messaging, you might have a prayer; else, you're wasting
your time and confusing a whole ton of people, with an unreasonable goal.)
We'll then need an IM_Protocol entry in Wikipedia, with a short note explaining
that the disambiguation entry became necessary as a result of the organization
formerly known as the JSF having several identity crises, and marching the name
of the protocol formerly known as Jabber through almost every word in the
dictionary before finally deciding that maximum confusion would probably result
from simply "IM," and thus settling on it.
> When/if SIMPLE becomes widespread, then standard IM applications might
> need to make it clear just which transport protocol they are using, or offer
> the user a choice of which protocol to use. Until then...
The idea isn't to wait for another IETF standard IM protocol to become popular
enough to make your lie a problem, and then start qualifying which apple you're
talking about. Identify early and often: users deserve nothing less than the
More information about the Standards