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: Thu, 15 May 1997 10:12:48 +0200 (MET DST)
Message-Id: <199705150812.KAA05310@wsooti08.win.tue.nl>
To: "David W. Morris" <dwm@xpasc.com>
Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3271
David W. Morris:
>On Wed, 14 May 1997, Koen Holtman wrote:
>>    A short-ftag-scheme-URI "U" is equivalent to the absoluteURI
>>    "ftag:U".  Equality comparison for feature tags MUST be done by
>>    first extending any short-ftag-scheme-URI to an absolute URI by
>>    prefixing it with "ftag:", and then doing a case-insensitive
>>    octet-by-octet equality comparison.  Any ""%" HEX HEX" encodings
>>    in the tag MUST NOT be processed.
>I still seriously question this approach unless you define much more
>precisely when %xx coding MUST / MUST NOT be used.

The above text intends to imply that a %xx encoding MAY be present.  A
rewite of the last line above would be

 A feature tag MAY contain % characters, but these need not denote 
 ""%" HEX HEX" encodings.  Recievers MUST NOT attempt any escape
 sequence decoding before doing a comparison,

I don't want to place any needless limitations on the kinds of URIs
that may be used; this will just make people unhappy.  The rule that %
encodings must not be processed discourages use of these encodings to
some extent, but it does not prevent their use if there is no other

>  Otherwise, the
>only comparison rule that makes sense is:
>   each URI to be compared must first be converted to lower case 
>   and then any %xx codes must be converted to the actual octet.
>   Then compare octet-octet.

This is another option for a rule.  I prefer the one which does no %
decoding because this could make it easier to map feature tags onto
future metadata naming schemes.

>Dave Morris
>(I also like larry's proposal for domain name based feature tags. I repeat
>and endorse his assertion that ANY GROUP who is going to define feature 
>tags is going to be a significant enough organization to have a domain
>name assigned by the appropriate TLD assignment authority.

I don't agree with this assertion at all.

If your browser supports adding user-specified tags to its feature set
(and I see no reason why it should not), this could be used in a very
localised context to negotiate on some preferences.

Every content author needs to have the power to define a new feature
tag which represents a preference.  Every shareware plugin developer
needs to have the power to define a new feature tag which represents a
capability.  This rules out using the DNS namespace.

>  Given the
>basic domain name assignment, is should be trivial to acquire a unique
>host name from the local network administrator.

This is a non-option for most people who author via an ISP account.
Most ISPs do not allocate DNS names for users, and those that do will
likely ask a huge fee for doing it.

Received on Thursday, 15 May 1997 01:16:28 UTC

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