Re: draft-ietf-http-feature-reg-01.txt

Graham Klyne:
>
>
>I think the word 'dimension' gets a bit overloaded in the draft.

You may be right.  When writing the draft, I fluctuated between using
the terms `area of negotiation' and `dimension', and chose for
`dimension' eventually.  But maybe I should have chosen for `area of
negotiation'.

[...]
>I phrased that badly.  I was trying to indicate the ability to specify
>multiple instances of each value.  E.g.
>(1)  {Yes,No}
>(2)  {1,2,3,5,7,11} or {Red,Green,Blue}
>(3)  {{1},{1,5},{1,5,11}}
>(4)  {1.1,3.3,7.7,100}
>(5)  {text/plain,text/html,application/word} or {[1.5-2.5],[2.0-20.0]}
>
>Another thought: for item (4) should there be a distinction between
>open/closed intervals?

I guess the problem is to find the right level of detail.  I'm trying
to stay away from things like open/closed intervals.  I don't think
that the _result_ of negotiation in a dimension will often be an
interval, though intervals may be used in the exchange which
establishes the result.

>>   Number of alternatives in (sub)negotiation with this tag:
>
>?? (sub)negotiation -- I don't know what you mean by that.

Oops, some more terminology I did not introduce.  Chop off the (sub).

>How about:
>"Number of alternative values for the feature identified by this tag"?

I think that would not work: values are not always `for' a feature.

[...]
>>     [ ] 2a.2 With an integer value
[...]
>2a.2: bounded/unbounded alternatives?  I am thinking that there might be
>known limits on the value of an integer used as an enumerated value.  I am
>not saying this is a Good Idea, just asking the question.

I don't know how often there would be known limits at registration
time.  I think that, when negotiating, the added value of knowing the
overall min. and max. values beforehand would be small: parties in a
negotiation process would presumably have to exchange their own
specific min. and max. values anyway.

Also, the trouble is that `always big enough' often turns out to be
`too small' 5 years later.  The 640K barrier in PCs is a good example.
If there are lots of deployed negotiation mechanisms which `know' that
the max. value is 640, these may end up blocking progress beyond 640.

[...]
>To answer your question, I like the earlier paragraphs better than the
>original, but I am uneasy about the technical depth implied by the
>alternatives for 2a.  If you follow this approach I do not think there is a
>single correct answer -- just a judgement as to what is appropriate.

I think you are right, I'll reduce the categories in the next version.
I think I'll just delete 2a.4 - 2a.6.

>Maybe the summary of negotiable features I posted a while back could
>provide a yardstick for what should be explicitly offered?  

If I remember correctly, this summary has *lots* of different types of
values.  Offering them all explicitly would make the list very long,
I think.

>I don't think
>there is a reason why the form should not be extended later if new feature
>value types start occurring frequently in the future (as this would simply
>represent a refining of the 'other' category, not the addition of new
>information).

Yes, so it makes sense to keep the initial list limited.

>GK.

Koen.

Received on Saturday, 19 July 1997 12:04:02 UTC