Re: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT)

[Adam Roach <[e-mail]>]

On 8/17/17 4:29 AM, Alexey Melnikov wrote:
> Hi Adam,
>
> On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote:
>> Adam Roach has entered the following ballot position for
>> draft-ietf-slim-multilangcontent-13: No Objection
>> I note that this mechanism uses only language tags and implicitly leaves
>> aside
>> any discussion of script or region tags.
> Actually this is not true. Language Tags as specified in RFC 5646 can
> optionally include all of these things.
>
>> I'm going to assume this was a
>> intentional decision that was considered by the group with the end result
>> being
>> that there was no perceived need to distinguish between (e.g.) Latin and
>> Jawi
>> scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'.
>> (If
>> this was not an explicit decision made by the WG, I would ask that it be
>> posed
>> to the WG for an explicit decision -- the current mechanism seems
>> somewhat
>> deficient in this regard from my admittedly brief analysis of the
>> situation.)
>>
>> I'm a little worried that an imprecise reading by implementors of the
>> citation
>> to RFC5646 may lead them to believe that script and region tags may be
>> included
>> in the Content-Language header fields.
> They are absolutely allowed.

Wow. If I had gone to implement this, I would have gotten it 100% wrong, 
and argued with anyone who told me as much. The document says:

    The Content-Language MUST comply with RFC 3282 [RFC3282] (which
    defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646]
    (which defines the structure and semantics for the language code
    values).


What is worth taking note of here is the fact that this says "language 
*code* values," not "language *tag* values." RFC 5646 defines a Language 
_Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _Code_ (e.g., 
"sr") followed by an optional Script Code (e.g., "Latn") and an optional 
Country Code (e.g., "RS").

As if to reinforce this, the examples then show values of the 
Content-Language header field that consist exclusively of language 
codes, even though it predominantly uses two languages with regional 
variations (en and es): to my eye, "en" by itself looks strange, as I'm 
used to always seeing that language written as either "en-US" or "en-GB".

So I would suggest (a) the passage above be changed to say "...for the 
language tag values...", and (b) the examples be amended to show more 
than simple language codes; e.g.:

    Content-Language: en-US

    Content-Language: de

    Content-Language: es-ES, fr

    Content-Language: sr-Cyrl


/a