W3C home > Mailing lists > Public > uri@w3.org > March 2006

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

From: Ben Laurie <ben@algroup.co.uk>
Date: Sat, 18 Mar 2006 11:14:53 +0000
Message-ID: <441BEBAD.5000506@algroup.co.uk>
To: Digital Identity Exchange <dix@ietf.org>
CC: uri@w3.org

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!



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 13:39:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:10 UTC