Re: Fwd: I-D ACTION:draft-hoffman-char-lang-media-00.txt

At 08:48 27/04/99 -0700, Paul Hoffman / IMC wrote:
>It's short; maybe it's even uncontroversial. :-)

Well... I have some comments for your consideration.

A general comment:  I note the draft was submitted only <LF> line
separators as opposed to <CR><LF>.  I find I have to convert such files
before I can use them or paste them into e-mail -- I imagine many Windows
users have similar problems.  (This is clearly not the place to discuss
such issues -- I'm just making the observation in case you weren't aware .)

And so to the content...

>     Registration of Charset and Languages Media Features Tags

>Abstract
>
>This document contains the registration for two media features:
.......................................................[------]
Suggestion:  "feature tags".

(I think this helps to underline that this is not creating a new
charset/language registry, a concern expressed on this list when the matter
of a charset feature tag registration was raised.)

>"charset" and "language". These media features allow specification of
>character sets and human languages that can be understood by devices
>and the devices' users. The templates in this document are derived from
>[TAG-REG].
                                   
>1. Registration for charset
[...]
>Media feature tag name:
>    charset
>
>ASN.1 identifier associated with feature tag:
>    None requested

One of the early goals of 'conneg' was to provide a protocol-independent
registry.  In recognition of the fact that some protocols are not
text-based, it seemed an inexpensive option to have OIDs issued for feature
tags so the same registrations could also be used with ASN.1-based protocols.

Given that this bis presented as a "common-use" feature tag, I'd suggest
requesting an IANA OID assignment:  past registrations have done this by
placing the text "[[[New assignments by IANA]]]" or similar in this field:
the value has then been filled in by the RFC editor.

>Summary of the media feature indicated by this feature tag:
>    Ability to display particular charsets as defined in [CHARSET]
>
>Values appropriate for use with this feature tag:
>  [x] 2. The feature has an associated numeric or enumerated value.
>   [x] 2e. String (equality relationship)
>
>(Only for case 2) Detailed description of the feature value meaning,
>and of the format and meaning of the feature tag values for the
>alternative results.
>    The values are strings as defined in [CHARSET]. The values can only
>	be compared for equality.

I think this has retained an confusing amount of boilerplate commentary
from the registration template.  Using previous registrations as a model,
I'd suggest the following is siufficient:

#Values appropriate for use with this feature tag:
#
#    The values are strings as defined in [CHARSET]. The values can only
#	be compared for equality.

>The feature tag is intended primarily for use in the following
>applications, protocols, services, or negotiation mechanisms:
>    Any protocol that used media tags
..........................^ "s"?

>Examples of typical use:
>    (| (charset=utf-8);q=1.0 (charset=iso-8859-1);q=.9
>       (charset=utf-16);q=.5 )

Nit: RFC 2533 does not permit the leading zero of q-values to be elided.
Hence, use "q=0.9" and "q=0.5".

(If you wonder why: that syntax was lifted from HTTP.)

>Related standards or documents:
>    "IANA Charset Registration Procedures", RFC 2278
>
>Considerations particular to use in individual applications,
>protocols, services, or negotiation mechanisms:
>    None
>
>Interoperability considerations:
>    None

I checked the charset registry RFC, and could see nothing nothing about
whether charset names are case sensitive.  However, charset names permit a
range of characters not allowed in CONNEG token syntax, so the value really
needs to be a string.  This in turn means that charset name matching is
case sensitive (due to the matching rules in the syntax specification):  if
the underlying charset registry name matching is reckoned to be case
insensitive then I think there should be a recommendation that values of a
charset  feature tag should be expressed in all-upper or all-lower case.
For example, my proposal for a MIME content type feature tag says:

# String feature matching is case sensitive, so 
# consistent use of case for content type values and 
# parameters is essential if content type value matching 
# is to be achieved in a fashion consistent with MIME 
# content type matching.
#
# Similarly, white space must be used consistently.
#
# This registration specifies a canonical form to be used 
# for content type values:  lower case letters and remove 
# all whitespace.


>Security considerations:
>    If it is known that there is a security bug in the display
>    of a particular charset in a particular environment, knowing
>    that a device can accept that charset may slightly help an
>    attacker.
>
>Additional information:
>    None
>
>Name(s) & email address(es) of person(s) to contact for
>further information:
>    Paul Hoffman <[email protected]>
>
>Intended usage:
>    COMMON
>
>Author/Change controller:
>    Paul Hoffman <[email protected]>

We discussed the issue of change controller for features that are
registered in the IETF feature tree by RFC publication with out AD, and the
conclusion we came to at that time was that the change controller for such
registrations should be "IETF".

>Requested IANA publication delay:
>    None
>
>Other information:
>    None
>
>2. Registration for language
>
>To: [email protected] (Media feature tags mailing list)
>Subject: Registration of media feature tag language
>
>Media feature tag name:
>    language
>
>ASN.1 identifier associated with feature tag:
>    None requested

(See comments per 'charset')

>Summary of the media feature indicated by this feature tag:
>    Ability to display particular human languages as defined in [LANG].
>    Note that "display" in this case will most often mean speech
>    by a computer.
>
>Values appropriate for use with this feature tag:
>  [x] 2. The feature has an associated numeric or enumerated value.
>   [x] 2e. String (equality relationship)
>
>(Only for case 2) Detailed description of the feature value meaning,
>and of the format and meaning of the feature tag values for the
>alternative results.
>    The values are strings as defined in [LANG]. The values can only
>	be compared for equality. As described in [LANG], language tags
>    are always handled as a single token, and "subtags" are not
>    used for comparison.

RFC 1766 explicitly says language tags are case insensitive, and the syntax
given conforms with the allowed syntax for a conneg token, so I think a
token value is appropriate here.

Hence, I suggest:

#Values appropriate for use with this feature tag:
#
#    The values are tokens, with allowable values defined by registration
#    per [LANG]. The values can only be compared for equality. As described
#    in [LANG], language tags are always handled as a single token, and
#    "subtags" are not used for comparison.  Comparison is not case sensitive.

>The feature tag is intended primarily for use in the following
>applications, protocols, services, or negotiation mechanisms:
>    Any protocol that used media tags
..........................^

>Examples of typical use:
>    (| (language=no-nynorsk);q=1.0 (language=no-bokmaal);q=.9
>       (language=i-sami-no);q=.5 )

Again: "q=0.9", "q=0.5" here.


>Related standards or documents:
>    "Tags for the Identification of Languages", RFC 1766
>
>Considerations particular to use in individual applications,
>protocols, services, or negotiation mechanisms:
>    None

I note that HTTP defines what amounts to extended matching rules for
language tags (RFC 2068, section 14.4).  To achieve a similar effect using
content features, a provider that associates a language tag with a resource
should also associate the prefix tag with that resource.  For example, a
resource described by the feature:
    (language=en-us)
might be represented as:
    (| (language=en-us) (language=en) )

Then the HTTP header
    Accept-Language: da, en-gb;q=0.8, en;q=0.7
corresponding to the
following content feature:
    (| (language=da) (language=en-gb);q=0.8 (language=en);q=0.7 )
would achieve equivalent resource selections.

However, I'd also note that this behaviour is at odds with RFC 1766, which
indicates that no relation between tags with the same leading subtag should
be inferred:

   There is no guaranteed relationship between languages whose tags
   start out with the same series of subtags; especially, they are NOT
   guraranteed to be mutually comprehensible, although this will
   sometimes be the case.

   Applications should always treat language tags as a single token; the
   division into main tag and subtags is an administrative mechanism,
   not a navigation aid.

>Interoperability considerations:
>    None
>
>Security considerations:
>    If it is known that there is a security bug in the display
>    of a particular language in a particular environment, knowing
>    that a device can accept that language may slightly help an
>    attacker.
>
>Additional information:
>    None
>
>Name(s) & email address(es) of person(s) to contact for
>further information:
>    Paul Hoffman <[email protected]>
>
>Intended usage:
>    COMMON
>
>Author/Change controller:
>    Paul Hoffman <[email protected]>

(See comments per 'charset')

>Requested IANA publication delay:
>    None
>
>Other information:
>    None
>
[...]



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