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

[Alexey Melnikov <[e-mail]>]

Hi Adam,

On Thu, Aug 17, 2017, at 10:54 AM, Adam Roach wrote:
> 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").

Good point. Content-Language is defined for language tags, we didn't
change that. I don't think the above difference was intentional.
Authors?

> 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

Yes, good idea to use better examples.