- From: Mark Baker <distobj@acm.org>
- Date: Tue, 25 Sep 2001 13:20:24 -0400 (EDT)
- 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-) MB
Received on Tuesday, 25 September 2001 13:18:28 UTC