W3C home > Mailing lists > Public > uri@w3.org > September 2001

Re: Excess URI schemes considered harmful

From: Mark Baker <distobj@acm.org>
Date: Tue, 25 Sep 2001 13:20:24 -0400 (EDT)
Message-Id: <200109251720.NAA12599@markbaker.ca>
To: robla@real.com (Rob Lanphier)
Cc: uri@w3.org
> On Tue, 25 Sep 2001, Mark Baker wrote:
> > > http://www.ietf.org/internet-drafts/draft-eastlake-cturi-02.txt
> >
> > Registered media types already have URIs.  For example, "application/xml" has;
> >
> > http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml
> >
> > Granted, types that aren't guaranteed to be registered (such as
> > experimental, vendor, or personal tree) don't get URIs of that form.
> > But I don't believe creating new URI schemes is necessary or
> > desirable, when an existing scheme such as "http" would suffice.
> Note that IANA makes no guarantees that these URIs are permanent.
> "isi.edu"?  Please.

I'm not familiar with the details of the relationship between IANA and
ISI, but I wouldn't expect it would be difficult to organize configuring
some HTTP redirects, if and when it's no longer appropriate for ISI to
be controlling those URLs.

>  I'll continue to limp along without this mapping
> before I recommend any of our programmers waste any time chasing down that
> dead end.

That's your prerogative, but I personally find it quite handy to type
in those ISI URLs into my browser so that I can find out which RFC
registered them.

> Besides that, what is the standard way of encoding the optional MIME-type
> parameters?  For example, what is the correct encoding for this MIME-type:
> "Text/Plain; Format=Flowed"

Why does there have to be any correct encoding?  The relationship between
"text/plain" and "text/plain; format=flowed" should be communicated out of
band of any URI naming policy.  For example, performing a GET on the
text/plain URI could return a document describing the parameters of that
type.  Oh wait, that already happens (modulo a redirect). 8-)

Received on Tuesday, 25 September 2001 13:18:28 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:39 UTC