RE: [httpapi] Adding language and direction metadata to RFC 9457 [I18N-ACTION-106]

Hi Rich,

 

I’m pretty familiar with the IETF process (I am one of the authors of the current BCP47, I have chaired a group~10 years ago). My email was probably not specific enough about how this might be actually approached (either I-Ds to supersede 9457 or, if sufficiently contained, via the errata process). Partly I want to gauge the reaction. I corresponded previously with Mark Nottingham, who cautioned me that late breaking suggestions might face challenges in getting support.

 

String-Meta’s status on the Note track should not affect how groups use it. The core recommendations are stable, although we continue to gather additional materials (Section 2.6 was published this month)

 

* I did not see what should be done if the data in the JSON disagrees with the HTTP header fields.

 

In general, data close to the string should win over document-level data for the purposes of presentation. One reason is that the sending process might not have complete information about the contents of static resources. It’s also the case that a given `Content-Language` response is sometimes the “best effort” for the requested locale while the actual content has fallen back to some other language (such as English). The closer the label is to the content, the more accurate it tends to be. That doesn’t invalidate metadata on another level. This is why, for example, we suggest that document level defaults be overridable with local values—even allowing for language overrides inside language maps, as described in the second note in [1] as a kind of super-rare case.

 

Hope that helps,

 

Addison

 

[1] https://www.w3.org/TR/string-meta/#language-maps

 

 

 

From: Salz, Rich <rsalz@akamai.com> 
Sent: Wednesday, July 31, 2024 2:07 PM
To: Addison Phillips <addisoni18n@gmail.com>; httpapi@ietf.org
Cc: public-i18n-core@w3.org
Subject: Re: [httpapi] Adding language and direction metadata to RFC 9457 [I18N-ACTION-106]

 

Thank you for writing.

 

The IETF does not modify RFCs, we develop new ones that can modify, extend, or overall supersede previously published ones. You could submit an erratum suggesting that the human-oriented text fields could be either text or an object containing the fields described in your note.  (See  <https://www.rfc-editor.org/info/rfc9457> https://www.rfc-editor.org/info/rfc9457 and click on the submit-errata link.)

 

I am not familiar with W3C processes. Do you have a timetable for when the Draft Note would become a full Group Note? And is the difference between those states meaningful to outsiders?

 

On a technical, as opposed to process, matter: I did not see what should be done if the data in the JSON disagrees with the HTTP header fields. I could have missed it in my quick skim of your document.

 

Thanks again!

-Rich Salz, HTTPAPI WG co-chair