[4] IETF のプロトコルにおけるロケールは文字コードや言語の指定が中心で、それ以外の機構に乏しく、パッケージ化された「ロケール」の仕組みも形骸化した定義がある程度です。

[3] 定義はロケールも参照。

[1]

The default should be the POSIX locale. The specification technique should use the Cultural register of CEN ENV 12005 [CEN] for the values. If headers are used, the header should be 'Content-Locale'.

RFC 2130 - The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 (2011-09-04 12:12:00 +09:00 版) http://tools.ietf.org/html/rfc2130#page-12

[5] RFC 2277: IETF Policy on Character Sets and Languages, 2023-12-02T12:55:29.000Z, 2023-12-02T13:39:56.243Z https://www.rfc-editor.org/rfc/rfc2277#section-5

[6] >>5 は POSIXロケールを説明して

   Note that language and character set information will often be
   present as parts of a locale tag (such as no_NO.iso-8859-1; the
   language is before the underscore and the character set is after the
   dot);

と例示していますが、 IETF 固有の規定は特にありません。

[7] >>5 はまた

The default locale is the "POSIX" locale.

としていますが、これも POSIXロケールの規定を紹介するまでです。

[8] しかしこれは IETF Policy を説明した文書ですから、 IETF のプロトコルは POSIXロケールを使って設計するべき、と主張していることになります。

[9] ではそれ以後に IETF から出てきたプロトコルが POSIXロケールを活用してるかといえば、それは大変怪しいところで、そのような事例はほとんど聞きません。

[10] RFC 4324: Calendar Access Protocol (CAP), 2023-12-02T07:30:13.000Z, 2023-12-02T13:44:06.454Z https://www.rfc-editor.org/rfc/rfc4324.html#section-8.12

[11] CAP の DEFAULT-LOCALE は、

         language = ; Text identifying a locale, as defined in [CHARPOL]

と説明され、実例が

      DEFAULT-LOCALE:en-US.iso-8859-1,POSIX

と示されています。 >>10

[12] [CHARPOL] とは RFC 2277 >>5 のことで、ロケールの識別子がそこで「定義」されていることになっています。

[13] しかし例文を見ると確かに POSIX というPOSIXロケールの識別子らしきものは使われていますが、 en-US.iso-8859-1 というあまり POSIXロケールの識別子らしくない例もあって、なんだかよくわかりません。

[14] もっとよくわからないのは、このロケール識別子の ABNF 生成規則の名前が language であることで、まあ生成規則の名前は仕様書内の記述上だけの構造なので、不透明な文字列でその意味は重要ではないといえばそれまでではあるのですが。ロケールが言語で、しかし言語と文字コードの組み合わせである、という混乱した状況をどう理解したらいいのでしょう。

[2] 関連: <greeting localize>