Re: New feature tag registration drafts available

Graham Klyne:
>
>At 10:43 PM 7/7/97 +0200, Koen Holtman wrote:
>>
>> draft-ietf-http-feature-scenarios-00.txt 
>>     `Feature Tag Scenarios' 
>>     Discusses why we need feature tag registration.
>
>Koen,
>
>Following a first read-through the feature secanarios draft, I have some
>comments for you.
>

My second batch of responses is below.  I left comments about simple
things I will resolve in editing unanswered.

[...]
>* Section 3.1:
>
>A nit-pick...
>
>I agree with the point you are making but I question the example you choose.
>
>I understand HTTP negotiation to be extensible, in that server-side
>negotiation can depend upon *any* of the supplied request headers,

There are a number of things in HTTP you could call `negotiation
mechanisms', and I was talking about the `4 Accept header mechanism'
only.  I am not claiming that HTTP as a whole is inextensible.  I'll
try to rephrase.

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

>* 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?

There is some `comments on tags' and `declare OBSOLETE' stuff in the
registration procedure which could be used for alias cases, among
other things.  But I don't think that a crisp alias registry would
address all alias problems.

The trouble with aliases is: who is allowed to declare that A and B
are really the same thing?  If Bob registers a tag B which is the same
as the A tag registered before by Alice, then Bob will generally not
know about the A tag, else Bob would have just used A.  So there would
have to be a third person Chris to register the alias relationship
after the fact.  But then Alice or Bob might disagree with Chris and
say that their implementations are not entirely identical, so Chris is
making things less interoperable by declaring A and B equal, etc.

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.

>GK.

Koen.

Received on Monday, 14 July 1997 11:04:27 UTC