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

From: Adam Roach <[email-masked]>
Date: Wed, 16 Aug 2017 16:50:00 -0700

Adam Roach has entered the following ballot position for
draft-ietf-slim-multilangcontent-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I note that this mechanism uses only language tags and implicitly leaves aside
any discussion of script or region tags. 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. If the assumptions I discuss above are
true, please add text making it clear that script and region tags are forbidden.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 10:29:35 +0100

Hi Adam,

> 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
> in the Content-Language header fields. 

They are absolutely allowed.

> If the assumptions I discuss above
> are

Best Regards,
Alexey

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Aug 2017 04:54:47 -0500

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 11:15:08 +0100

Hi Adam,

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

>     Content-Language: sr-Cyrl

Yes, good idea to use better examples.

---

From: Nik Tomkinson <[email-masked]>
Date: Thu, 17 Aug 2017 14:21:05 +0100

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 <[email-masked]> wrote:

> > >> I note that this mechanism uses only language tags and implicitly
> leaves
> > >> aside
> > >> 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

-- 

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

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

---

From: Nik Tomkinson <[email-masked]>
Date: Thu, 17 Aug 2017 21:07:17 +0100

Hi Adam,

thanks for your comments.

The usage of the phrase 'language code' in that paragraph was certainly
unintentional and now I understand how much difference it makes, I will of
course update that.

I'll also update the examples.

We originally had a paragraph that recommended using the highest level of
categorisation for language tags to get an improved interoperability but
this was later removed. I think the original assumption was that matching
preferred languages with the tag values would be difficult if script codes
and country codes were also included. This is probably not the case.

Thanks again,

Nik.

On 17 August 2017 at 14:21, Nik Tomkinson <[email-masked]>
wrote:

>> > >> this was not an explicit decision made by the WG, I would ask that
>> it be
>> > >> posed
>> > >> to RFC5646 may lead them to believe that script and region tags may
>> be
>> > >> included

--