- From: Roy T. Fielding <fielding@ebuilt.com>
- Date: Wed, 26 Sep 2001 00:05:43 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Al Gilman <asgilman@iamdigex.net>, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, "'Rob Lanphier'" <robla@real.com>, uri@w3.org, Dan Connolly <connolly@w3.org>, Tim Berners-Lee <timbl@w3.org>, Larry Masinter <LMM@acm.org>, Dan Zigmond <djz@corp.webtv.net>, Rich Petke <rpetke@wcom.net>
> 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
Received on Wednesday, 26 September 2001 03:09:34 UTC