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

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.

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: imcdonald@sharplabs.com

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Ben
> Laurie
> Sent: Saturday, March 18, 2006 8:39 AM
> To: Digital Identity Exchange
> Cc: uri@w3.org
> 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.
> 
> -- 
> 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
> 
>

Received on Saturday, 18 March 2006 16:32:47 UTC