Re: Rewrite of feature tag syntax rules

> Yes.  But feature tags are not ASCII strings just because it is easier
> for `debugging and programming'.  The authors of negotiable content
> will have to type in feature tags when making variant lists, and these
> authors will generally not be programmers. Even worse, end users will
> in some cases look at feature tags in variant lists when deciding
> which variant to get (though one would hope that variant list authors
> use {description xx} a lot).

Koen, it's quite evident that you're trying to solve a different
problem than I thought you were trying to solve. So I guess
we need someone to actually work on the problem we established
originally, which is how browsers and servers might automatically select
the "tuned for Netscrape 12.7" pages when running "Netscrape 12.7"
but not requiring some new browser to write "User Agent: Netscrape 12.7
(compatible)", and deal with expressing preferences for content
tuned for different kinds of screen resolutions, devices, etc.,
when such negotiation is necessary.

However, you're description above has the client actually
presenting the feature tags (not some textual description
of the feature tag, but the feature tag itself) to the user.
This is nonsense. If the server wants the user to select among
many different representations, the server can send the user
a page with links to the different representation. "Choose Frames", "No
frames". Of course, pages in French might say that in
French, instead. Unless you want to also require that feature
tags written in different languages be marked as equivalent,
it doesn't work.

> So feature tags have a very wide human interface.

Any design that requires that is a bad design.

Feature tags should be similar to, but orthogonal to,
the space of Internet Media Types; the observation is
that content negotiation needs to talk about characteristics
and preferences of the recipient of a message
independently of the media type that represents the message.

> I agree it is cute, maybe too cute, but the W3C seems to be firmly set
> on this course (not just in PEP, it also pops up in some Cougar stuff,
> for example).  I feel we will need to have _very_ good reasons to go
> out of sync with the W3C's approach.

"Voodoo design" is the practice of making what you're designing
look like some other design even though the function and purpose
of the designs are different.

> URIs are fundamentally enumerated values too. 

It is the _use_ of a string that determines its role. The role
of a URL as a Uniform Resource Locator is not an "enumerated value"
role. While a cache might apply an equivalence function
between two URLs to decide whether one might represent the
same resource as another for the purpose of caching, in general,
it is not required to be able to compare two URLs for equivalence.
You might contrast this with 'entity tags', which, while they
are not 'enumerated values', _are_ used for equality.

> This brings me to a point about limiting the syntax of feature tags

The question is not about 'limiting the syntax', it's about
defining equivalence relationships.

> 
> - feature tags are strings of legal tag characters, legal characters are
>   letters, numbers, and a small number of other things like . / : - _ .
> 
> - tag comparison is case-insensitive.  There is no escape mechanism.
> 
> - all tags without : in them are in the IANA-maintained feature tag
>   namespace
> 
> - prefixes in this namespace are registered/allocated by IANA
> 
> - all tags with : in them SHOULD be valid representations of 
>   members of the URI namespace, and MAY be dereferenced by a browser
>   capaple of doing so.  Creation of these tags must follow the rules
>   (if any) of the corresponding scheme.
> 
> - tag values are octet sequences with % HEX HEX encoding.  Comparison is
>   case-sensitive octet-by-octet after decoding.
> 
> - [we may also do this, more input requested:] the ftag: scheme
>   mirrors the iana-managed namespace of tags without : in them.
>   before comparing feature tags, any ftag: prefix must be deleted.


I think that feature tags should be handled using the same
(not just similar, but the same) mechanism used for media type
registration: register with IANA under various 'trees', establish
an IETF tree for those things that are standards track, and
a vnd. and pers. and x. tree for vendor, personal, and experimental,
respectively.

Regards,

Larry



 
Larry
--
http://www.parc.xerox.com/masinter

Received on Monday, 19 May 1997 10:19:04 UTC