[4] IETF のプロトコルにおけるロケールは文字コードや言語の指定が中心で、 それ以外の機構に乏しく、 パッケージ化された「ロケール」の仕組みも形骸化した定義がある程度です。
[5] RFC 2277: IETF Policy on Character Sets and Languages, , https://www.rfc-editor.org/rfc/rfc2277#section-5
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 固有の規定は特にありません。
The default locale is the "POSIX" locale.
としていますが、これも POSIXロケールの規定を紹介するまでです。
[8] しかしこれは IETF Policy を説明した文書ですから、 IETF のプロトコルは POSIXロケールを使って設計するべき、 と主張していることになります。
[9] ではそれ以後に IETF から出てきたプロトコルが POSIXロケールを活用してるかといえば、 それは大変怪しいところで、そのような事例はほとんど聞きません。
[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 であることで、まあ生成規則の名前は仕様書内の記述上だけの構造なので、 不透明な文字列でその意味は重要ではないといえばそれまでではあるのですが。 ロケールが言語で、しかし言語と文字コードの組み合わせである、 という混乱した状況をどう理解したらいいのでしょう。