- From: Graham Klyne <GK@acm.org>
- Date: Tue, 15 Jul 1997 20:53:21 +0100
- To: Koen Holtman <koen@win.tue.nl>
- Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
At 08:00 PM 7/14/97 +0200, Koen Holtman wrote: >>> draft-ietf-http-feature-scenarios-00.txt >>> `Feature Tag Scenarios' >>> Discusses why we need feature tag registration. >>* Section 4.3, item t+2.5: >> >>This implies another requirement: it must be possible for content authors >>to specify feature tags and associated values in authored content (this has >>possible implications for representability within HTML, for example). > >Yes. This is why < and > are not allowed in feature tags, and why >feature predicates have the syntax paper!=A4, not paper<>A4. Isn't there a conflict here with <draft-mutz-http-attributes-02.txt>? >>* Section 4.4, para 2: >> >>I think there is a potential problem more pernicious than 'dead' tags, >>etc., which is use of different tags by different vendors to mean the same >>thing. This could cause unecessary negotiation failures -- maybe some >>alias mecchanism could be defined within the registration procedures? > >TCN takes the viewpoint that, in the end, it is up to the content >authors do decide whether A and B are interchangeable in a particular >case at hand. See section 19.1 in draft-ietf-http-negotiation-02.txt. >Like with dead tags, I do not assume that content authors will directly >go to the registry, but that there will be third parties who make >lists of useful aliases, describing for each alias the necessary >boundary conditions under which the alias relationship holds. OK -- I accept that an alias mechanism is probably not a Good Idea. I think your comment suggests a possible requirement on a generic negotiation framework is the ability to treat some set of features as interchangeable in the context of some specific negotiation exchange, as your 'fpred-bag' does for indicating the quality of a variant. GK. --- ------------ Graham Klyne GK@ACM.ORG
Received on Tuesday, 15 July 1997 12:58:31 UTC