Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP

From: Ben Laurie <[email-masked]>
Date: Sat, 18 Mar 2006 18:11:25 +0000

McDonald, Ira wrote:
> Hi Ben,
> 
> With respect to "scarce":
> 
> Although I have mixed feelings about the logic, the brand
> new RFC 4395 "Guidelines and Registration Procedures for 
> New URI Schemes" argues that the bar should be very high
> for a new 'Permanent' URI scheme, because so many browsers
> and other bits of client software will have to updated for
> the URI scheme to become widely deployed and used.

I guess that DIX is an example of a proposal that drives a truck through
that argument. Clearly all that s/w has to be changed _no matter how_
you represent DIX. It seems likely to me that this is generally true,
too, but I'm not planning to make a stand against 4395 on that basis :-)

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 18 Mar 2006 08:32:15 -0800

Hi Ben,

Note that RFC 4395 also defines and allows registration of
'Provisional' URI schemes with a fairly low bar.

Anyone defining or attempting to register a new URI scheme
needs to carefully read RFC 4395 and understand the new
guidelines.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ben
> Laurie
> Sent: Saturday, March 18, 2006 8:39 AM
> To: Digital Identity Exchange
> Cc: [email-masked]
> Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP
> 
> 
> 
> Dick Hardt wrote:
> > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote:
> > 
> >> ntroducing a new URI scheme just for DIX is not a good use 
> of scarce
> >> community resources;
> 
> What is scarce? n-letter combinations? This seems unlikely!
> 
> >> let's not do the DAV: thing again.
> >>
> >> Instead of
> >>   dix:/homesite
> >> just use something like
> >>   http://dixs.org/terms#homesite
> > 
> > Thanks for the input Dan. Sorry you won't make Dallas. I'm 
> not familiar
> > with what happened with DAV: -- is there somewhere you can point for
> > enlightenment?
> 
> Hmmm. Not sure what happened, but the outcome was that DAV 
> uses the HTTP
> namespace and adds extra headers and methods to the requests.
> 
> > Agree that we need to make good use of scarce community resources.
> > 
> > Not being a standards guy, I am sure that I will be butchering
> > terminology -- please correct me!
> > 
> > The reasoning behind introducing a new scheme was we need an escape
> > sequence for processiFrom [email-masked] Sat Mar 18 21:54:56 2006
From: "McDonald, Ira" <[email-masked]>
To: "'Ben Laurie'" <[email-masked]>, Digital Identity Exchange
	<[email-masked]>
Subject: RE: [dix] on the dix: URI scheme for DIX/SXIP
Date: Sat, 18 Mar 2006 08:32:15 -0800
Cc: [email-masked]
Reply-To: Digital Identity Exchange <[email-masked]>

Hi Ben,

Note that RFC 4395 also defines and allows registration of
'Provisional' URI schemes with a fairly low bar.

Anyone defining or attempting to register a new URI scheme
needs to carefully read RFC 4395 and understand the new
guidelines.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ben
> Laurie
> Sent: Saturday, March 18, 2006 8:39 AM
> To: Digital Identity Exchange
> Cc: [email-masked]
> Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP
> 
> 
> 
> Dick Hardt wrote:
> > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote:
> > 
> >> ntroducing a new URI scheme just for DIX is not a good use 
> of scarce
> >> community resources;
> 
> What is scarce? n-letter combinations? This seems unlikely!
> 
> >> let's not do the DAV: thing again.
> >>
> >> Instead of
> >>   dix:/homesite
> >> just use something like
> >>   http://dixs.org/terms#homesite
> > 
> > Thanks for the input Dan. Sorry you won't make Dallas. I'm 
> not familiar
> > with what happened with DAV: -- is there somewhere you can point for
> > enlightenment?
> 
> Hmmm. Not sure what happened, but the outcome was that DAV 
> uses the HTTP
> namespace and adds extra headers and methods to the requests.
> 
> > Agree that we need to make good use of scarce community resources.
> > 
> > Not being a standards guy, I am sure that I will be butchering
> > terminology -- please correct me!
> > 
> > The reasoning behind introducing a new scheme was we need an escape
> > sequence for processing the name/value pairs and to 
> differentiate data
> > from constants etc.. Anything starting with "dix:" is known to be a
> > constant. Anything else is not. :) -- one of the reasons for this is
> > that we want to be able to pass through name/value pairs that a web
> > application may be using to preserve state. We think the 
> likelihood that
> > any existing app have strings that start with "dix:/" to be, well,
> > really really small.
> > 
> > One might think that we could just use "http://dixs.org" as 
> the escape
> > sequence, but we wanted anyone to be able to extend DIX, so 
> having a new
> > scheme allows the scheme to be the escape, and the 
> namespace and hence
> > the definition of properties that can be stored and retrieved to be
> > distributed rather then centralized. We reserved the use of dix:/foo
> > style constants (no name space) for ones that are defined 
> in the DIX spec.
> > 
> > Does this make sense? Do you have a suggestion for another 
> approach that
> > provides an escape mechanism and allows decentralized property
> > /capability extension?
> 
> It sounds to me like you could do this all with HTTP headers. 
> Obviously
> that doesn't help with other protocols, of course!
> 
> Cheers,
> 
> Ben.
> 
> --

---

From: [email-masked]
Date: Mon, 20 Mar 2006 21:49:34 -0500

Ira McDonald writes:

> Although I have mixed feelings about the logic, the brand new 
> RFC 4395 "Guidelines and Registration Procedures for 
> New URI Schemes" argues that the bar should be very high for a 
> new 'Permanent' URI scheme, because so many browsers
> and other bits of client software will have to updated for the 
> URI scheme to become widely deployed and used.

FWIW, I think that's sometimes among the reasons for viewing scheme names 
as scarce, but not the only reason or even the most widely applicable.  As 
noted later in this thread, there are many potential schemes for which the 
required scheme-specific software would likely by quite isolated.

As far as I'm concerned, the scheme names that are ultimately scarce are 
the ones that are simple to type and easy to remember, and especially 
those likely to be suggestive of particular real world concepts.  If 
someone wanted to argue for schemes like:

        a1324987123904873209487:
        a8976872648574368573469848765:
        a3487687683687463874683:

I would say they have a variety of important downsides, but scarcity isn't 
among them.  (I'm showing scheme names with the trailing ":" even though 
that's not technically part of the name).  On the other hand, if someone 
wants to have a scheme:

        phone:

then that's it for all time.  We can't come back in 20 years and decide 
we'd like to use the word phone for some more robust abstraction of 
phones, or for something entirely different. 

The situation with scheme names is aggravated by the fact that, like top 
level domain names, they are not fundamentally hierarchical per RFC 3986. 
One could build a hierarchical convention within scheme names (Roy 
occasionally suggests xxx.yyy), but then the xxx becomes the limited 
resource. 

Of all the potential uses of the three letters "dix" for a scheme name, is 
the proposed use likely to be among the most important over a period of, 
say, 50 years?  If not, I think assignment of the scheme is suspect.  It's 
in that sense that I see scheme names as scarce.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------