Re: Excess URI schemes considered harmful

Roy,

I think a difference in our viewpoints may be here:

>... Since I only use the relative
>parts within the protocol syntax ...

I am interested in information that escapes the confines of its enclosing 
protocol;  then, I am seeking a way to "absolutize" the reference in a way 
that cuts any dependency on the protocol context.

Hence, when you say:

>Personally, though, I don't see any reason to standardize all IANA field
>values as some sort of URI or another.  A media type is simply an identifier
>within a given context, and the Content-Type field name is more than
>sufficient to establish that context.

I agree to a point (i.e. about "*all* IANA field values").  But *some* such 
values, such as content-type, do have reasonable meaning outside a given 
context.

#g
--

At 12:05 AM 9/26/01 -0700, Roy T. Fielding wrote:
> > roy: the worst thing with relative URIs is that at any time, there is only
> > one base. If you have stuff from 2 naming trees at the same time, 
> you're in
> > trouble.
>
>On the contrary, I can have a hundred different bases for which a given
>relative URI can be resolved, just as we can have a hundred different
>repositories for standard MIME types.  Since I only use the relative
>parts within the protocol syntax (unless it is a non-standard extension),
>it really doesn't matter to me what the base is, provided that I pick one
>(or allow the user to configure one) that points to at least one existing
>namespace that is managed by the IETF.  "text/plain" is a relative URI.
>For this type of identifier, I simply don't allow relative names outside
>of those within the standard namespace, and I pick the base according to
>an algorithm that is different from web page retrieval.
>
>Personally, though, I don't see any reason to standardize all IANA field
>values as some sort of URI or another.  A media type is simply an identifier
>within a given context, and the Content-Type field name is more than
>sufficient to establish that context.
>
>....Roy

------------
Graham Klyne
GK@NineByNine.org

Received on Wednesday, 26 September 2001 06:55:28 UTC