<draft-hoffman-char-lang-media-01.txt>

Paul,

I cannot remember if I got round to responding to your -00 version of this
draft, so please forgive any repetition.

You don't indicate a specific forum for discussion of this proposal, so
I've assumed the CONNEG list is appropriate for such a general-purpose
proposal.

I'll also note that some recent comments on this list suggest that
achieving registration of these tags is really quite important.


>     Registration of Charset and Languages Media Features Tags


>1. Registration for charset
>
>To: [email protected] (Media feature tags mailing list)
>Subject: Registration of media feature tag charset
>
>Media feature tag name:
>    charset
>
>ASN.1 identifier associated with feature tag:
>    New assignment by IANA
>
>Summary of the media feature indicated by this feature tag:
>    Ability to display particular charsets as defined in [CHARSET]

Also:

# When used to describe a document or data resource, indicates that
# the character set is used by the resource.

>
>Values appropriate for use with this feature tag:
>    The values are strings as defined in [CHARSET]. The values can only
>	be compared for equality. Comparison is not case sensitive.

For a case insensitive comparison, the matching rules of the CONNEG syntax
[RFC 2533] require that the values be tokens.  (RFC 2506 appears to be
silent on this.)  Also, your examples use token syntax.  Thus, I suggest:

#Values appropriate for use with this feature tag:
#    The values are tokens, with the permissiable values defined in [CHARSET].
#    Values can tested only for equality (which for token values is not
#    case sensitive).

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

.... +  to describe text data handling capabilities?

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

This uses RFC 2533 syntax, but does not cite that document.  I'd suggest
including a citation.

It might be more hepful to include a slightly more substantial example --
the following is an example describing text, HTML and TIFF options (though
the following example does assume progress with another CONNEG draft):

# (| (& (type="text/plain") (charset=us-ascii) )
#    (& (type="text/plain") (charset=utf-8) )
#    (& (type="text/html") (charset=iso-8859-1) (color=limited) )
#    (& (type="image/tiff") (color=full) ) )

Do you feel the use of q-values is important to your example?

>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:
>    Even though charset names are not case-sensitive, values should be
>	expressed as all lowercase letters to increase the liklihood of
.............................................................^ e
>	interoperability.

If expressed as tokens within an RFC 2533 feature expression, this is not a
problem.  Though use in other contexts is theoretically possible.  How about:

# Comparison of charset names should not be case-sensitive, particularly
# when expressed as token values RFC 2533 feature expressions.  To increase
# the likelihood of interoperability in other contexts, values should be
# expressed using lower case letters only.

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

Also:

# Displaying text using an incorrect character set can significantly
# alter the perceived meaning (e.g. currency symbols or unit designators).

Also:

# Use of this tag might disclose personal information about an individual
user.

>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:
>    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:
>    New assignment by IANA
>
>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.

Hmmm... I'd be wary about making statements like "most often".  Another
possible use might be in a text translation environment, e.g. as available
for the results of some AltaVista searches.

Also:

# When applied to a document (or data resource), indicates that the indicated
# language is used within the document.

>Values appropriate for use with this feature tag:
>    The values are tokens, with allowable values defined by
>	registration 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. 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 uses media tags

.... + to describe handling of language-sensitive material ?

>Examples of typical use:
>    (| (language=no-nynorsk);q=1.0 (language=no-bokmaal);q=0.9
>       (language=i-sami-no);q=0.5 )
>
>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
>
>Interoperability considerations:
>    Even though langage tags are not case-sensitive, values should be
>	expressed as all lowercase letters to increase the liklihood of
>	interoperability.
>
>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.

Also:

# Use of this tag might disclose personal information about an individual
user.

>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:
>    IETF
>
>Requested IANA publication delay:
>    None
>
>Other information:
>    None


#g

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