Subject: draft-ietf-conneg-feature-reg-03.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:47:17 +0100

Folks,

I'm sorry for the rather delayed posting of my comments.

#g

>                    Media Feature Tag Registration Procedure
>
>                     draft-ietf-conneg-feature-reg-03.txt
>

[...]
>2.1 Media feature tag purpose
>
>  Media feature tags represent individual and simple characteristics
>  related to media capabilities or properties associated with the
>  resource to which they are applied.  Examples of such features are:
>  
>  * the color depth of the screen on which something is to be displayed
>  * the type of paper available in a printer
>  * the support of the `floating 5 dimensional tables' feature
>  * the fonts which are available to the recipient
>  * the capability to display graphical content

I would prefer to see more neutral wording here with respect to the thing
described by a feature tag. This wording seems to focus entirely on feature
tags used to describe recipient capabilities, but they can also be used to
describe other entities as well.  For example:

#  * the number of colors used by a document or which can be displayed by a
recipient
#  * the type of paper on which a document may be printed
#  * the `floating 5 dimensional tables' feature
#  * the fonts used in a document or available to the recipient
#  * the type of document content (e.g. text, graphical, etc.)
  
[...]
>  Further examples of media feature tags are defined in detail 
......................................................<-------> delete?
>  elsewhere [4].  
>
>  Feature collections may be composed using a number of individual
>  feature tags [2]. Composition of feature collections is described
>  elsewhere [2].  Examples of feature collections requiring multiple
>  media feature tags are:

I think this paragraph confuses "feature collections" and "feature sets".
I suggest:
#  Combinations of features may be composed from individual feature tags,
#  and is described elsewhere [2].  Examples of feature sets composed from
#  multiple feature tags are:

(The intention is to use the terminology consistently with other documents
without getting bogged dowm in explaining it here.)

>  * teh set of all fonts used by a document
>  * the width and height of a display
>  * the combination of color depth and resolution a display can support

For the above, I suggest:
  
#  * the set of all fonts used by a document
#  * the width and height of a display (thus the range of document sizes
#    that can be displayed)
#  * the various combinations of color depth and resolution a display can
support

>  This registry presumes the availability of the MIME media type
>  registry, and MIME media types MUST NOT be re-registered as
>  media feature tags.  Media feature tags which are currently in use by 
>  individual protocols or applications MAY be registered with this 
>  registry if they might be applied outside of their current domain.

I think we will need some way to incorporate registered MIME content types
into an expression that describes media capabilities.

Maybe this document should register a feature tag called "Content-type",
which is a string containing a MIME content-type, so the whole range of
media characteristics is covered by the registry?

[...]
>2.3 Media feature tag values
>
[...]
>  At the time of registration, each tag must be associated with
>  a single data type.  If that data type implies a defined
>  comparison or an ordering, the registrant must define the ordering
>  or comparison.  For ordered tokens, this may be by full enumeration
........................<----------------------------------
...------------------------------------------------------------------
...------------->
I suggest:
#  If a feature value ordering is required that is not implied by the
#  associated data type, the comparison procedure must be defined by
#  the registrant.

>  of the tokens and their order or by reference to an ordering
>  mechanism.  For defined comparisons, a full description of the
>  rules for comparison must be provided or included by reference.

I might also add a note:
#    NOTE:
#    If a special ordering relation is defined for a given feature tag,
#    not all protocol processors may know how to perform the comparison.
#    Therefore, these should be defined and used sparingly if the feature
#    might be applicable across a range of protocols or applications.

>  Media feature tags related to spatial or temporal characteristics
...^ Insert "Numeric"
(for example, this paragraph doen't need to apply to papersize,
which is defined by token)

>  must be registered with a single canonical unit.  It is strongly
>  preferred that units be in the SI system; where current practice
>  has defined units in other systems (such as pixels per inch),
>  a conversion method to SI units must be provided.  Conversion
>  methods should include a defined rounding practice.
>
>2.3  ASN.1 identifiers for media feature tags
>  
>  Certain protocols use ASN.1 identifiers rather than human-readable
>  representations for capability exchange.  In order to allow both 
>  systems to interoperate, registrants may provide an ASN.1 identifier 
>  or ask that IANA assign an ASN.1 identifier during registration.  
>  These identifiers are not required for registration, but may provide
>  assistance to those building gateways or other cross-protocol
>  systems.  Note that ASN.1 identifiers assigned by IANA will be
>  treated as tokens, not as elements from which sub-delegated 
>  identifiers may be created or derived.

In view of some comments that have been made elsewhere, I suggest adding a
note:

#    NOTE:
#    The use of ASN.1-based media feature representations is not required.
#    A primarily goal of this memo is to define a text-based vocabulary
#    for describing media feature values.  But this work attempts
#    to be protocol-independent, and ASN.1 representations are allowed
#    in recognition of the fact that there do exist a number of Internet
#    protocols that use ASN.1-derived representations.

>3 Media feature tag registration
>
>  Media feature tags can be registered in several different registration
>  trees, with different requirements as discussed below.  The
>  vocabulary for these requirements is taken from [5]. In general, a
>  feature tag registration proposal is circulated and reviewed in a
>  fashion appropriate to the tree involved.  The feature tag is then
>  registered if the proposal is accepted.  
>
>  Review of a feature tag in the URI tree is not required.

Move the above statement to section 3.1.3?

[...]
>3.1.2 Global tree
>
>  Tags in the global tree will be distinguished by the leading facet
>  "g.".  An organization may propose either a designation indicative
>  of the feature, (e.g., "g.blinktags") or a faceted designation
>  including the organization name (e.g., "g.organization.blinktags").
>  Organizations which have registered media types under the MIME
>  vendor tree should use the same organizational name for media
>  feature tags if they propose a faceted designation. The acceptance 
>  of the proposed designation is at the discretion of the IANA.  
>  If the IANA believes that a designation needs clarification
>  it may request a new proposal from the proposing organization
>  or otherwise coordinate the development of an appropriate
>  designation.

From "The acceptance..." onwards, I recall that somewhere (RFC2409?) there
is a slightly different form of words that I think more clearly signals the
intention here, along the lines of:

#  IANA has the right to reject obviously bogus feature registrations.

I offer this because, as I read it, the -IANA-considerations- draft seems
to discourage requiring too much "discretion" to be exercised by IANA.
  
[...]
>3.4 Registration template

[...]
>   Values appropriate for use with this feature tag:
>
>     [ ] 1. The feature tag is Boolean and may have values of
>          TRUE or FALSE.   A value of TRUE indicates an available
>          capability.  A value of FALSE indicates the capability
>          is not available.

I suggest deleting the text that talks about "availability".  In my view, a
Boolean value simply expresses two possibilities.  So I'd also delete the
following...

>    | If you wish to indicate two mutually exclusive possiblities
>    | that cannot be expressed as the availability or lack of a
>    | capability, use a two-token list, rather than a Boolean value.
>
>
>     [ ] 2. The feature has an associated numeric or enumerated value.

I'd also suggest separating the numeric and other values.  My proposal for
the complete feature tag data type section follows.

#   Values appropriate for use with this feature tag:
#
#     [ ] 1. The feature tag is Boolean and may have values of
#          TRUE or FALSE.
#
#     [ ] 2. The feature has an associated numeric value.
#
#   For case 2, indicate the type of numeric value:
#	  [ ] 2a. Signed Integer
#        [ ] 2b. Signed Rational number
#
#     [ ] 3. The feature has an enumerated token value
#
#   For case 3, indicate:
#        [ ] 3a. (equality relationship only)
#        [ ] 3b. (defined ordering, and indicate the order of token values)
#
#     [ ] 4. The feature has a string value
#
#   For case 4, indicate:
#        [ ] 4a. (equality relationship only)
#        [ ] 4b. (defined ordering, and describe the comparison rule)
#
#    |IMPORTANT: You may only chose one of the above data types.
#
#  Detailed description of the feature value meaning,
#  and of the format and meaning of the feature tag values
#  for the alternative results. 
#
#    | If there is a limited useful numeric range of result (case 2)
#    | indicate the range.
#    |
#    | If you have selected 3b you must provide the ordering mechanism
#    | or a full and ordered enumeration of possible values.
#    |
#    | If you have selected 4b you must provide a defintion of the
comparison.  
#    | Definitions by included reference must be to stable and readily
#    | available specifications.
#    |
#    | If the number of alternative results is small, you may
#    | enumerate the identifiers of the different results and describe
#    | their meaning.
#    |
#    | The identifiers of the alternative results could also be
#    | described by referring to another IANA registry, for example
#    | the paper sizes enumerated by the Printer MIB.

[...]

------------
Graham Klyne
([email-masked])

---

From: [email-masked] (Koen Holtman)
Date: Tue, 15 Sep 1998 19:24:22 +0200 (MET DST)

>Boolean value simply expresses two possibilities.  So I'd also delete the

I would be against deleting the text about availability.  Note that we
had a long discussion about this before. The discussion centered
around negotiation protocols which assign default 'safe' values to
tags that are unknown to the recipient.  The above text is supposed to
ensure that 'false' is the safer value in general.

This is a rather tricky point, and I'd really hate to repeat the whole
discussion, so please tell me if the above refreshes your memory.

Koen.