Re: comments on draft-eastlake-cturi-01.txt

At 05:18 PM 1/22/01 -0500, Roy T. Fielding wrote:
>On Mon, Jan 22, 2001 at 10:16:30PM +0000, Graham Klyne wrote:
> > At 09:25 PM 1/18/01 -0600, Dan Connolly wrote:
> > >Let's not pretend that a different URI scheme
> > >will somehow magically provide more stability
> > >than http/dns; stability depends on
> > >social practices, not just technology.
> >
> > I agree.  In which case, it seems reasonable to use a form of URI whose
> > very form carries a clear signal of stable intent.  To my mind, that is 
> the
> > big advantage of using a URN form.
>
>But that is a myth.  The only reason that the URN form appears
>to be stable is because almost nobody is using it, and therefore it
>hasn't been subjected to the social pressures of useful names.

That was not my point.  I wasn't arguing stability of the mechanism:  I 
think both DNS and IANA registration have similar and relatively short 
histories there (in social terms).

I was arguing that a URN in its very purpose conveys (of should convey) a 
clear intent of stability, unlike http: URLs which many of us have got used 
to coming and going.  It is my view (based in part on some initial 
confusion I experienced when first encountering http: URLs used as 
identifiers) that having such a clear signal of intent will help to cement 
whatever social mechanisms are used to achieve stability.

[Snipped:  technical discussion of naming authority delegation mechanisms, 
which I'm not arguing about.]

>This whole debate is irrelevant.  Protocol tokens are names that
>are assigned by some naming authority or left to chaos (x-prefix).
>The fact that there exists a naming authority, combined with a
>name, implies that there exists a URL which can be constructed
>(at invocation-time, if necessary) to form a unique name that can
>be imbued with the semantics of any given protocol.  The only
>thing that is required is that all parties of the communication
>share the same context with which to interpret the tokens such
>that they can be resolved into an absolute URI that is the name.

I don't disagree, except with the first sentence.  In many ways, the web 
(in my understanding of its architecture) rises above any single 
protocol.  I am encountering real situations in which the universality of 
URIs is a useful naming tool for dealing with concepts away from the 
context of the protocol with which they are most closely associated.  Also, 
we are seeing more works to define protocol elements that are not specific 
to a single protocol operating context.  These have given rise to some 
specific requirements to embed some registered protocol elements into URI 
space.

Examples:
(a) use of RFC2506 media feature tags in CC/PP
(b) distribution of message header information in RDF

>For example, there is a protocol called HTTP/1.1 that has semantics
>defined by the IETF and an associated set of tokens.  I therefore
>claim that there exists a URI
>
>     p://ietf.org/http/1/1/request/method/GET
>
>with which I can establish unique naming within an application
>and interoperate consistently with other applications provided
>that I trim off the prefix implied by the context whenever I use
>it within a protocol exchange.  The exact absolute URI can even
>differ between applications, provided that they all mirror the
>same semantic namespace.  HTTP applications get that context from
>the Protocol-Version included with every message.

In principle, sure (though I'm not quite sure that the name of a protocol 
operation has much relevance outside the context of the protocol).  I fully 
accept is that a protocol context may allow a URI prefix to be implied, or 
even irrelevant.  But when one rises above that context...

>Think about it.  We already do the above internally when an
>application is developed.  We look to a naming authority (IETF)
>to define a standard protocol (HTTP) with a standard namespace
>for use in each semantic context of interoperable communication.
>All this does is rephrase that shared context into an imaginary URI.

Fine.  All we're trying to do is suggest a tangible URI for use in contexts 
that require it.

>Now, imagine that rather than assuming a protocol token is always
>relative to the context, we change the protocol parser to allow each
>value to be a URI reference.  Every protocol element that calls for
>a token must then be parsed as a URI reference relative to a base URI
>defined by the protocol context (which is, of course, defined by the
>protocol-version field given at the beginning of each message and may
>itself be an absolute URI).  In other words, the only change to a
>standard ascii-based protocol exchange is that certain characters
>(":" and "/" in particular) need to have reserved meanings within
>the token name syntax.
>
>The effective difference is that when someone wants to define an
>extension token value that is not part of the base standard,
>they have to include the whole URI or convince the protocol's
>naming authority to add it within the base namespace.  The claim
>is that this method of extension is more meaningful and less
>susceptible to collisions than both the "wait til the working
>group gets around to it" and the chaotic (x-prefix) method
>that do not work well today.

I think that's just great.  In fact I'm working on a protocol proposal that 
does just that.

>And all of this is without discussing the possible benefits
>of being able to retrieve a description of semantics by performing
>a GET on that currently-imaginary URI.
>
>But this is all just a philosophical argument.  There just aren't
>many protocols for which the benefit of long token names (let alone
>absolute URI) is worth the expense of bits-on-the-wire.

I'm not quite sure what you mean by that -- it seems to me that there is an 
explosion of such protocols:  every application that uses XML and XML 
namespaces to exchange information.

#g
--

Received on Tuesday, 23 January 2001 07:12:20 UTC