Re: Excess URI schemes considered harmful

On Wed, 26 Sep 2001, Al Gilman wrote:
> Rob, I don't know if you will find this helpful or still too theoretical.  But
> I'll give it a whirl anyway.

Thanks for your patience.  I think we may agree much more than I
originally thought.

> So a normalization or equivalently comparison scheme for the space of
> registered MIME types including the registered parameters is readily
> achievable
> as is the preservation into URI syntax of sufficient information to perform
> this comparison on the URIs without recovery.
>
> A general normalization or comparison for URIs or types-indicated-via-URIs is
> much less readily achievable.

I think that the former is all that is needed, even when used in a
generalized mechanism.  In the case of systemComponent, and I suspect in
many other contexts, it will work to have scheme specific information.

The reason for this is that the default answer to the query "Do you
support feature xxx?" is false.  No domain specific information is needed
to return "false".  The only time domain specific information is needed is
when the answer is "true".  The good news here is that, if an
implementation supports a particular feature, it also has some knowledge
about the different ways that particular feature can be expressed.

As an example, let's say that an author wants to check for png support in
an implementation, and let's say the specification for the URI is pretty
loose (case-insensitive, multiple orderings on parameters, etc).  Now, the
author can say "ContentType:IMAGE/PNG", or
"ContentType:IMAGE/PNG;version=1", or "ContentType:image/png",  As an
implementor, this may seem a little difficult, but entirely tenable.  Part
of what goes with the territory of supporting PNG in this particular
context is supporting the "ContentType" URI, and the various permutations
that support can be expressed.  If the feature isn't supported, there's no
need to support the various permutations.

Now, I'm not arguing that the ContentType scheme should be loose, but I'm
just pointing out that if it is, it's not the end of the world.

> All this says is that in URI land, the MIME types should be their own
> name-sub-space with their own subdomain-private normalization and comparison
> rules.
>
> This can be done either with a dedicated top-level scheme name or with an URN
> subspace.

Great, I think we agree here, then.  I'm more partial to the dedicated
top-level scheme name for a couple of reasons:

1.  Content types have a very long legacy, and trying to cram a legacy
format into an existing format with lots of conflicting rules leads to
more complexity than any sort of commonality eliminates.

2.  Addressing Tim BL's original concern, I don't think this opens the
floodgates for an endless stream of new URI schemes.  Content-types are
arguably just as fundemental to Internet architecture as URIs (perhaps
more so), and thus can be afforded much higher status than
BillyJoeBobsFineURIScheme:how-do-you-do.

(Of course, the fact that new protocols create new potential URI schemes
blows a rather large hole in the idea that we can stop the universe of URI
schemes from expanding.)

Rob

Received on Thursday, 27 September 2001 12:36:59 UTC