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

At 08:01 PM 7/14/97 +0200, Koen Holtman wrote:

>>* Section 3.8:
>>
>>(A) In "Summary of the indicated dimension of negotiation", I am
>>uncomfortable with your use of the term 'dimension' in this context.  I
>>think what you are describing is the range of values associated with a
>>dimension.
>
>The trouble is that some dimensions can be described nicely in terms
>of their values, while for other dimensions, where the values are yes
>and no, a description in terms of the `meaning' of these values must
>be given.
>
>I plan to change "Summary of the indicated dimension of negotiation"
>to "Summary of negotiation with this feature tag", or something.  I am
>not sure I want to use the word `dimension' in the form.

I think that approach would be consistent with the motivations indicated in
your response to my point (B).

>>Underlying this comment is my feeling that I don't think sufficient
>>distinction is drawn between identification of a dimension of negotiation
>>(the feature tag) and the values which are associated with that dimension
>>(feature values?).
>
>Do you mean in the form or in the text around it?

A bit of both.

I think the word 'dimension' gets a bit overloaded in the draft.

>>I would suggest:
>>
>>(1) A yes/no choice
>>(2) A choice of one value from a finite enumeration of (possibly numeric)
>>values
>>(3) A choice of multiple values from a finite enumeration of values
(powerset)
>>(4) A value selected from a finite or infinite range of some scalar type
>>(integer, real)
>>(5) A compound value (e.g. MIME Content-type, range of numeric values)
>>
>>[I also note that these values relate to a specific message which is
>>transferred: the feature negotiation mechanism would have to deal with
>>multiple values for any of these value range types.]
>
>?? If there were not multiple values to choose from, there would be no
>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?




>Here is a rewrite of the first part of the form, please say if you
>like this better.  Note that I'm trying to avoid the `dimension'
>terminology.
>
>3.8 Registration template
>
>   To: ietf-feature-tags@iana.org (Feature tags mailing list)
>        (or directly to iana@iana.org)
>   Subject: Registration of feature tag XXXX
>
>    | Instructions are preceded by `|'.  Some fields are optional.
>
>   Feature tag name:
>
>   Summary of negotiation with this feature tag
>
>    | Include a short (no longer than 4 lines) description or summary
>    | Examples:
>    |   `Negotiation on whether to use the xyzzy feature of ...'
>    |   `Negotiation on the MIME media type of the data which
>    |    is transmitted for ...'
>    |   `Negotiation on whether to use colors in displaying ...'
>    |   `Negotiation on the number of colors to use in displaying ...'
>
>   Number of alternatives in (sub)negotiation with this tag:

?? (sub)negotiation -- I don't know what you mean by that.

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

>
>     [ ] 1. Two alternatives
>     [ ] 2. More than two alternatives
>
>   For case 1: nature of the two alternatives:
>
>     [ ] 1a. A particular feature is used/invoked/enabled, or not
>     [ ] 1b. Other
>
>   For case 2: Is there a natural way to identify every possible
>               alternative?
>
>     [ ] 2a. Yes
>     [ ] 2b. No
>
>   For case 2a: How is a single alternative naturally identified?
>
>     [ ] 2a.1 With a name, keyword, label, or tag (e.g. a language tag)
>     [ ] 2a.2 With an integer value
>     [ ] 2a.3 With a numeric value of a non-integer type (e.g. float)
>     [ ] 2a.4 With a non-numeric (non-scalar) value (e.g. a piece of code)
>     [ ] 2a.5 With a record or tuple of values
>     [ ] 2a.6 With a set of values
>     [ ] 2a.7 Other
>

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.

2a.3: bounded/unbounded alternatives (e.g. real numbers <= 1.0)?.  Again,
I'm just asking the question.

2a.4, 2a.7: don't these amount to the same thing?

2a.5, 2a.6: to provide complete coverage of structured types, union should
be included.

Given that this is not intended to be used by programmers, I would suggest
collapsing 2a.4..2a.7 into a single 'other' category (possibly singling out
2a.6 as a 'common' case).



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.

Maybe the summary of negotiable features I posted a while back could
provide a yardstick for what should be explicitly offered?  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).

GK.
---

------------
Graham Klyne
GK@ACM.ORG

Received on Tuesday, 15 July 1997 12:59:04 UTC