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

From: John Merrells <[email-masked]>
Date: Fri, 17 Mar 2006 15:17:02 -0800

On 17-Mar-06, at 1:29 PM, Dan Connolly wrote:

> Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt
> says "This document has no IANA Actions." but section 3.2.6. DIX  
> URI Namespace
> introduces a new URI scheme.

My understanding of this is that because the document is an individual
submission and not a working group document that there can be no
IANA actions from it. If it were a working group document then this
document would have to call out 'dix' registration as an action.

I'm happy to add a comment to the draft to make that clearer though.

> Introducing a new URI scheme just for DIX is not a good use of  
> scarce community resources;
> let's not do the DAV: thing again.
>
> Instead of
>   dix:/homesite
> just use something like
>   http://dixs.org/terms#homesite

This issue then becomes who owns that domain.

> There are some IANA considerations around dixs.org; IANA should
> make sure that name is reserved for this purpose in perpetuity if this
> spec is adopted. Or the DIX profile should use iana.org or ietf.org .
> (There's a BCP that says to use urn:ietf , but I recommend against  
> that;
> I intend to renew the internet draft that argues for http/dns rather
> than urn:ietf: .)
>
> The draft charter also doesn't say that DIX is introducing a new  
> URI scheme.
>   http://dixs.org/index.php/DIX_Charter
> Please add something to the charter about getting review for the  
> dix: scheme.

Note that draft-merrells-dix-01 (aka dmd1) is a write up of an  
example solution
to the problem space we're considering here.

If a WG were to be created then dmd1 would just be source material  
for another
set of documents written to describe the WG's collective solution to  
the problem.
The consensus of the group may or may not be to base that work on  
dmd1 and
may or may not want to use URI's in that way and may or may not want to
register a new scheme.

John

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

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 17 Mar 2006 18:40:27 -0500

> -----Original Message-----
> From: John Merrells [mailto:[email-masked]] 
> Sent: Friday, March 17, 2006 6:17 PM
> To: Dan Connolly
> Cc: [email-masked]; [email-masked]
> Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP
> 
> 
> > says "This document has no IANA Actions." but section 
> 3.2.6. DIX URI 
> > Namespace introduces a new URI scheme.
> 
> My understanding of this is that because the document is an 
> individual submission and not a working group document that 
> there can be no IANA actions from it. If it were a working 
> group document then this document would have to call out 
> 'dix' registration as an action.
> 

Individual submission drafts can have IANA actions.  It happens all the
time.

I do agree that minting a URI scheme is probably not a good idea if other
alternatives are available.

-Scott-

---

From: John Merrells <[email-masked]>
Date: Fri, 17 Mar 2006 15:42:44 -0800

> Individual submission drafts can have IANA actions.  It happens all  

My misunderstanding then. I'll add a required action to the next draft.

John

---

From: Norman Walsh <[email-masked]>
Date: Fri, 17 Mar 2006 16:47:01 -0500

/ Dan Connolly <[email-masked]> was heard to say:
[...]
| Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt
| says "This document has no IANA Actions." but section 3.2.6. DIX URI
| Namespace
| introduces a new URI scheme.
|
| Introducing a new URI scheme just for DIX is not a good use of scarce
| community resources;
| let's not do the DAV: thing again.
[...]
| Please add something to the charter about getting review for the dix:
| scheme.

+1

                                        Be seeing you,
                                          norm

-- 
[email-masked] / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dan Connolly <[email-masked]>
Date: Fri, 17 Mar 2006 16:29:55 -0500

I learned at a W3C authorization workshop this week
   http://www.w3.org/2005/Security/usability-ws/program
that there's a SXIP/DIX BOF at the IETF next week.
   http://www3.ietf.org/proceedings/06mar/agenda/dix.html

I'm pretty excited about DIX/SXIP and related web-like authorization 
mechanisms,
but I don't think I can swing the trip to Dallas.

Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt
says "This document has no IANA Actions." but section 3.2.6. DIX URI 
Namespace
introduces a new URI scheme.

Introducing a new URI scheme just for DIX is not a good use of scarce 
community resources;
let's not do the DAV: thing again.

Instead of
   dix:/homesite
just use something like

(There's a BCP that says to use urn:ietf , but I recommend against that;

The draft charter also doesn't say that DIX is introducing a new URI 
scheme.
   http://dixs.org/index.php/DIX_Charter
Please add something to the charter about getting review for the dix: 
scheme.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Mar 2006 22:52:52 -0800

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  

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?

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?

-- Dick

---

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

Dick Hardt 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!

> 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.

> 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

---

From: Dick Hardt <[email-masked]>
Date: Sat, 18 Mar 2006 13:18:06 -0800

Anyone else here (Hilton Anatole) that is interested in dinner tonight?

-- Dick

---

From: Larry Masinter <[email-masked]>
Date: Sat, 18 Mar 2006 18:43:05 -0800

> differentiate data

---

From: Larry Masinter <[email-masked]>
Date: Sat, 18 Mar 2006 18:43:05 -0800

I'm just having a hard time figuring out what 'dix:' URIs
are supposed to mean and how they're intended to be used.

What does 'dix:/core#1' mean? What is the namespace for
'core', and where is it registered? Can I make up one
of my own? What if two people decide to do so but
assign different meanings? Or is there just a limited
set of these things, all listed in the 'dix' document?

It really looks like you're defining an authentication
protocol and trying to pack all of the parameters of
authentication requests into a URI. But it's not really
clear you need a URI scheme at all. What if you just
got rid of the four characters 'dix:' and used the rest
of the string everywhere that expected a dix? Wouldn't
it work just as well? In which circumstances might I
find a URI which would possibly be a 'dix:' and possibly
be something else?

As a side note, the document contains a lot of trademarks
'google.com', 'amazon.com', 'yahoo.com', 'homesite'
which you might want to avoid.

Larry

f.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

I'm just having a hard time figuring out what 'dix:' URIs
are supposed to mean and how they're intended to be used.

What does 'dix:/core#1' mean? What is the namespace for
'core', and where is it registered? Can I make up one
of my own? What if two people decide to do so but
assign different meanings? Or is there just a limited
set of these things, all listed in the 'dix' document?

It really looks like you're defining an authentication
protocol and trying to pack all of the parameters of
authentication requests into a URI. But it's not really
clear you need a URI scheme at all. What if you just
got rid of the four characters 'dix:' and used the rest
of the string everywhere that expected a dix? Wouldn't
it work just as well? In which circumstances might I
find a URI which would possibly be a 'dix:' and possibly
be something else?

As a side note, the document contains a lot of trademarks
'google.com', 'amazon.com', 'yahoo.com', 'homesite'
which you might want to avoid.

Larry

---

From: Dick Hardt <[email-masked]>
Date: Sat, 18 Mar 2006 19:43:12 -0800

> are supposed to mean and how they're intended to be used.

 From dmd1: (http://dixs.org/index.php/Draft-merrells-dix-01.txt)

    The DIX protocol uses DIX URI Names for:

    o  Capability Names

    o  Property References

    o  Message Parameters

    o  Constant Values

> set of these things, all listed in the 'dix' document?

 From dmd1:

Extensibility stems from the authority. Anyone with a registered
    domain name can create DIX URI Names using their own domain name as
    the authority in the URI.

...

To elaborate, anything starting with dix:/ would be reserved for  
identifiers in the DIX standard. eg. dix:/core#1
Anyone with a domain name can define their own. eg. dix://acm.org/foobar

> authentication requests into a URI.

DIX is NOT a authentication protocol. The parameters are NOT in a URI.

> But it's not really

Having the scheme allows the string values to be globally unique so  
that DIX values can be recognized.

I think we are getting ahead of ourselves here as we still don't have  
a WG for DIX.

-- Dick

---

From: Sandro Hawke <[email-masked]>
Date: Sun, 19 Mar 2006 20:48:35 -0500

> Dick Hardt scripsit:
> It looks like the tag: URI scheme would be appropriate: it's used for
> identifying 
> rather than locating, and anyone with a domain name or email address
> can assign one. 

Indeed, if it's important to have the URIs not be dereferenceable, tags
URIs (RFC 4151, which I co-wrote) are a fine choice.  On the other hand,
it's often very useful to provide information about the identified
thing, via URI dereference, so I strongly recommend using an HTTP one,
even though it can feel like like a strange approach.

   -- sandro

---

From: John Cowan <[email-masked]>
Date: Sun, 19 Mar 2006 19:57:37 -0500

-- sandro

---

From: John Cowan <[email-masked]>
Date: Sun, 19 Mar 2006 19:57:37 -0500

> Anyone with a domain name can define their own. eg. dix://acm.org/foobar

It looks like the tag: URI scheme would be appropriate: it's used for identifying
rather than locating, and anyone with a domain name or email address can assign one.

-- 
Mark Twain on Cecil Rhodes:                     John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                http://www.ap.org
buy a piece of the rope for a keepsake.        [email-masked]

6 00:40:46 -0500
Cc: Larry Masinter <[email-masked]>, [email-masked], [email-masked]
Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <[email-masked]>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

> Anyone with a domain name can define their own. eg. dix://acm.org/foobar

It looks like the tag: URI scheme would be appropriate: it's used for identifying
rather than locating, and anyone with a domain name or email address can assign one.

-- 
Mark Twain on Cecil Rhodes:                     John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                http://www.ap.org
buy a piece of the rope for a keepsake.        [email-masked]

---

From: Tim Bray <[email-masked]>
Date: Mon, 20 Mar 2006 07:42:57 -0800

> Agree that we need to make good use of scarce community resources.

On top of which, using an "http:" URI has the huge advantage that you  
can put something useful there that a human being can point their  
browser at and learn something about what this string means.

I'd advise those who are promoting the new URI scheme to check out  
the remarks about URI schemes in http://www.w3.org/TR/webarch/ and in  
particular http://www.w3.org/TR/webarch/#URI-scheme - when you are  
doing something that flies in the face of a SHOULD recommendation in  
the "Architecture of the World Wide Web", you need to have really  
thought it through.

> 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.

You're saying that you need a reliable way to ascertain that this  
identifier contains name-value pairs that should be processed per  
DIX?  Can this be established by context?  Any other signaling  
mechanisms?

If not, then why are you buying into all the expectations and culture  
that go with using a URI, why not just use an opaque string or a  
chunk of XML or ";"-separated name-value pairs or whatever?  A URI is  
supposed to identify a resource, and a common expectation is that one  
way or another, you can use it to retrieve information.  If you avoid  
specifying one particular scheme, you leave the door open for  
different modes of information retrieval down the road.

> that provides an escape mechanism and allows decentralized  
> property /capability extension?

In general, naming things with URIs is a good and Web-friendly thing  
to do; as you point out, the use of the authority field allows  
distributed authority over parts of the namespace.  In particular,  
HTTP URIs have a lot of advantages.

-Tim

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Mar 2006 10:57:17 -0700

Tim Bray wrote:
> I'd advise those who are promoting the new URI scheme to check out the
> remarks about URI schemes in http://www.w3.org/TR/webarch/ and in
> particular http://www.w3.org/TR/webarch/#URI-scheme - when you are doing
> something that flies in the face of a SHOULD recommendation in the
> "Architecture of the World Wide Web", you need to have really thought it
> through.

Agreed. See also RFC 4395:

http://www.ietf.org/rfc/rfc4395.txt

Peter

---

From: Dick Hardt <[email-masked]>
Date: Wed, 22 Mar 2006 17:51:00 -0600

On 20-Mar-06, at 9:42 AM, Tim Bray wrote:
>
>> Does this make sense? Do you have a suggestion for another  
>> approach that provides an escape mechanism and allows  
>> decentralized property /capability extension?
>
> In general, naming things with URIs is a good and Web-friendly  
> thing to do; as you point out, the use of the authority field  
> allows distributed authority over parts of the namespace.  In  
> particular, HTTP URIs have a lot of advantages.

Thanks everyone for the feedback on the URI scheme for DIX.
A likely shift in the architecture removes the requirement for the  
URI scheme to double as an escape sequence, so we can use HTTP.

A couple examples of what we are doing are:

	http://sxip.net/contact/internet/email
	http://sxip.net/media/image/32x32

> you can put something useful there that a human being can point  
> their browser at and learn something about what this string means.

Tim: what would you suggest that we put at that URLs above? An HTML  
file that describes it for people? Perhaps some metadata that is  
machine readable for typing? Suggestions welcome!

-- Dick

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Mar 2006 16:11:53 -0800

> machine readable for typing? Suggestions welcome!

Ideally, both (e.g. see http://www.rddl.org/) but there aren't any  
agreed-upon standards; if you want to have something there that SXIP- 
savvy software can read that might be useful; failing anything  
automated, having something human-readable to explain what's going on  
to the puzzled programmer is good citizenship. -Tim