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.ORGReceived on Tuesday, 15 July 1997 12:58:31 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:02 UTC