W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Rewrite of feature tag syntax rules

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 16 May 1997 10:05:22 +0200 (MET DST)
Message-Id: <199705160805.KAA15403@wsooti08.win.tue.nl>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3286
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

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

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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC