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

Re: Rewrite of feature tag syntax rules

From: David W. Morris <dwm@xpasc.com>
Date: Thu, 15 May 1997 09:02:27 -0700 (PDT)
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SOL.3.95.970515084312.3013A-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3274

On Thu, 15 May 1997, Koen Holtman wrote:

> 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
> option.
> >  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.

The problem with the no decoding rule is it requires that the encoding
rules applied be identical. I guess it would be sufficient to state
that % is not a special character and thus the %xx is three characters in
the URI used to map features. My concern is that %xx encoding has a long
history of imprecise application rules because the it has been reasonably
well understood that the %xx values must be decoded before the encoded
value is used. You are proposing to allow a familiar construct but change
the processing rules. If this is to be successful, usage of %xx encoding
must be much more complete in definition and there will still be a problem
where users/implementors didn't read the details because the thought they
understood %xx handling in URLs.

I guess my objection is the use of an old name for a new / variant
concept. It always results in confusion.

Note: I do not object to the % encoding, I just believe the usage rules
should match. Unless a switch is made to the more arbitrary token approach
such as the DNS scheme, I believe internationalization issues associated
with use of URIs require % encoding.

> >
> >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.

This scheme doesn't require the name to be resolved by a DNS ... is is
simply a way to generate a name that is unique enough to avoid confusing
conflicts.  Such a user could easily just make up a name.  Easy engough
to for a convention to develope where the local administrator defines
a dummy feature host to which a user would prepend their userid with a '.'
and then add additional feature descriptors.
> 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.

So extend the domain name a tad to allow a simple variant of a simple
email address:


Otherthan the parsing rules for the feature id tag, all that should matter
is the ability of the user generating the tag to be reasonably confident
of uniqueness.  somestring above would be required to conform to the rules
for the userid in dwm@xpasc.com.
Received on Thursday, 15 May 1997 09:10:34 UTC

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