Re: Rewrite of feature tag syntax rules

Larry Masinter:
>
>> How is this for a compromise:
>> 
>> - a feature tag is a member of the URI namespace
>> - a feature tags MUST be chosen in such a way that every % in the tag
>>   is the start of a %HH encoding
>> - tag comparison MUST be done by decoding all %HH encodings, then doing a
>>   case-insensitive octet-by-octet comparison.
>
>    ftp://host.dom/%2ftest%2fbar
>
>is actually a *different* resource from
>
>   ftp://host.dom//test/bar
>
>Defining a "feature tag equivalence relationship" which bears
>no actual semantic relationship to the "URI equivalence relationship"
>is "bad". Do I really need to spell out why?

You need to spell out why decoding is worse than the other
alternatives.

We are making an engineering compromise here.  We have a number of
options

1. decode when comparing
2. do not decode when comparing
3. limit the schemes people may use
4. do not use URIs for feature tags
5. etc

All of these options have something bad going for it.  To make
progress, we need to agree on which is the lesser evil.

Combining all the bad things people have said about URIs in this
thread, we might conclude that the URI namespace is so broken that new
protocols should not attempt to re-use it.  This seems like a strange
conclusion to me, but then I am not a URI specialist.

>Larry

Koen.

Received on Friday, 16 May 1997 01:06:48 UTC