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

Graham Klyne:
>
>Koen,
>
>A couple of comments regarding your feature registration draft...
>
>
>* Section 3.6, item (3):
>
>In conflict with section 2.2 final paragraph, this item does seem to place
>prior restrictions on the things can be identified by a feature tag.
>
>Specifically, the wording suggests the range of a feature value must be a
>scalar type (enumeration, number range, etc.).  Compound values seem to be
>excluded; e.g. sets (multiple choices), cartesian products
>(multidimensional values).

I did not intend it to suggest that dimensions must be scalar, quite
the contrary.  I plan to add some examples which make this more clear.

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

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


>(B) I feel your list of "Result in the indicated dimension of negotiation"
>is rather arbitrary.

It is.  It is supposed to reflect increasing complexity, both from a
human viewpoint and from the viewpoint of an extensible negotiation
mechanism.  For example, not all extensible mechanisms may support

     [ ] 4. A choice for a non-integer value among several

>  Why separate items (1) and (2)?

I think (1) is a very frequent, and simple case, so separating it out
would make it easier to fill in and read the forms.

>  Similarly (3) and
>(4) in that they both represent a choice from an enumeration of
>values.

No, (4) is also supposed to represent choice values without a natural
enumeration.

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


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:

     [ ] 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


>GK.

Koen.

Received on Monday, 14 July 1997 11:05:08 UTC