W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

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

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 19 Jul 1997 19:37:25 +0200 (MET DST)
Message-Id: <199707191737.TAA17578@wsooti08.win.tue.nl>
To: Graham Klyne <GK@acm.org>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3823
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

>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

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


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC