- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 24 Sep 2003 18:13:05 +0100
- To: Tim Bray <tbray@textuality.com>
- Cc: Norman Walsh <Norman.Walsh@Sun.COM>, www-tag@w3.org
In general, the URI spec licenses certain conclusions, and indirectly authorizes other specifications to themselves license other conclusions. I suppose the thing is to be aware of that process and to just not make assumptions that are not licensed by the specs. The TAG needs to say this "stick to the channel" in general, and then go around putting buoys noteworthy points, be they center-channel fairway buoys ("The character encoding you can rely on, it must be correct") or markers of notorious rocks ("any .html on the end of a URI path means nothing - do not use it"). Tim On Monday, Sep 22, 2003, at 22:57 Europe/London, Tim Bray wrote: > > Norman Walsh wrote: > > >> Yes, if that's what we mean, I think we need to be clearer about what >> part of the URI is opaque. What you're saying is that the scheme part >> is NOT opaque, but everything else is. Adopting that position begs a >> couple of questions: > > Hmm, I don't think I'm saying that. I'm that the scheme governs the > semantics of the rest of the URI. For example, in mailto: URIs, the > bit before the @ is opaque, the bit after isn't at all. HTTP URIs are > explicitly opaque after the host part. > >> - - If the scheme specification explicitly identifies other parts of >> the URI, >> does that make those parts transparent as well? For example, >> suppose that >> mailto: says that the string that follows it is an email address. >> Does >> that mean I can infer that any-damn-fool@nwalsh.com is an email >> address >> if I'm presented with this URI: mailto:any-damn-fool@nwalsh.com ? > > I think so. > >> - - Does the HTTP spec constrain the range of HTTP URIs to things >> that are >> documents (or information resources or whatever we're calling bags >> of bits >> the end of a wire these days)? > > Nope. All HTTP tells you is that the HTTP protocol may be used to > obtain representations. -Tim >
Received on Wednesday, 24 September 2003 13:23:17 UTC