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

[Nik Tomkinson <[e-mail]>]

Hi,

Thanks for your comments.

I will try to address these (and the other comments) and respond later
today.

Nik.

On 17 August 2017 at 11:15, Alexey Melnikov <[e-mail]> wrote:

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



-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

-----------------------------------------------------------------