RE: XRI vote aftermath - 1

Hi Henry & All,

A three year PC replacement cycle at Boeing doesn't work like Henry's

 - People at Boeing get new PCs all the time; some people are getting
new PCs today, and some more on Monday, etc. So while it might take
three years for _everybody_ to get new PCs, approximately a third of the
population will have new PCs in just one year. 

 - Even without getting a new PC, a significant software blockpoint gets
pushed onto Boeing PCs every year or so. If/when XRI savvy software gets
included in a Boeing blockpoint, it will rapidly be pushed out to the
Boeing population of PCs.

 - Boeing-approved software can be downloaded onto users' PCs in a pull
model whenever the user wants to. If/when Boeing approves XRI savvy
software, it will be available for Boeing users to download immediately.

 - Even if deployment of a capability to PCs would rely on a three year
PC refresh cycle, that shouldn't necessarily stop projects that rely on
that capability. For example, even though it took three years for all
the Boeing PCs to get smart card readers, we didn't defer the start of
our smart card program for three years - there was plenty of work to do
before full deployment. Even though we don't yet have approved XRI savvy
software for Boeing PCs, we've already built XRI capabilities into some
of our infrastructure services - there's plenty of work to do before XRI
capability on PCs becomes ubiquitous.

 - Mozilla is an approved browser at Boeing. An XRI savvy plugin for
Mozilla already exists. If/when Boeing approved that plugin, Boeing
users could have XRI savvy software on their PCs the next day.; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Information Security - Technical Controls
(206) 679-5933

-----Original Message-----
From: Henry S. Thompson [] 
Sent: Thursday, June 05, 2008 2:54 PM
To: Schleiff, Marty
Subject: Re: XRI vote aftermath

Hash: SHA1

Schleiff, Marty writes:

> I'll start by asking for help to understand the TAG's stance on 
> introduction of new URI schemes. I understand the part about it being 
> costly to introduce new schemes. What I wonder about is the idea that 
> the http: scheme should be used for everything (I probably didn't 
> state that very well - perhaps you can put it into better words).
> If there existed no mailto:, or ldap:, or https: scheme today (the 
> three I'm most familiar with beyond http:), what would be the TAG's 
> reaction to a request for a new scheme for mailto: or ldap: or https?

I am not speaking for the TAG, only myself, in this, but the core of my
answer is in fact from the IETF [1]:

  "[T]he unbounded registration of new schemes is harmful.  New URI
   schemes SHOULD have clear utility to the broad Internet community,
   beyond that available with already registered URI schemes."

I simply don't think that's true for XRIs.  In trying to explain this to
someone else, before reading your email, I actually used Boeing as an
example:  I believe it's the case that most desktops in Boeing (and
there are a _lot_ of them) are centrally managed and tightly
constrained, with a multi-year roll-out cycle.  That means that no-one
at Boeing will be able to click on an xri: or hdl: or doi: URI for at
_least_ three years, given that IE7 does not support any of those out of
the box.  "So," I said to my interlocutor, "do you really want to
recommend that your users use URIs which no-one at Boeing, or dozens of
other similar companies, can click on for years to come?"

Yes, this is an argument against _any_ new URI scheme where there is
real value to be gained by allowing as many people as possible to use it
to access resources on the Web.  And the network effect (because that's
what we're talking about) is what _made_ the Web.  Using a new URI
scheme when you could use http: is intentionally cutting yourself off
from the network effect.

I think that mailto: is pretty clearly _not_ in that category, and its
non-retrieval semantics makes it a reasonable special case.  And
https: is really just http: with a bit of metadata encoded in the scheme
name.  ldap: is a less clear case -- I'm not really familiar with its
operation, but my superficial understanding is that it is not central to
the functioning of the LDAP system, and that its semantics mean that it
is unlikely that it will appear in general-purpose Web contexts, which
distinguishes it pretty well from http:.

The TAG is working on a detailed exposition of its position in this
matter, which I expect will address your question in more detail -- I
hope this quicker personal reply will be helpful in the meantime.


- --
 Henry S. Thompson, HCRC Language Technology Group, University of
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail:
                   URL: [mail really from
me _always_ has this .sig -- mail without it is forged spam] -----BEGIN
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Friday, 6 June 2008 16:11:20 UTC