Re: Opacity and mailto: in conflict

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