RFC 3282 (rfc3282) - Page 2 of 8
Content Language Headers
Alternative Format: Original Text Document
RFC 3282 Content Language Headers May 2002
A prerequisite for any such function is a means of labelling the
information content with an identifier for the language that is used
in this information content, such as is defined by [TAGS]. This
document specifies a protocol element for use with protocols that use
RFC 822-like headers for carrying language tags as defined in [TAGS].
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. The Content-language header
The "Content-Language" header is intended for use in the case where
one desires to indicate the language(s) of something that has RFC
822-like headers, such as MIME body parts or Web documents.
The RFC 822 EBNF of the Content-Language header is:
Content-Language = "Content-Language" ":" 1#Language-tag
In the more strict RFC 2234 ABNF:
Content-Language = "Content-Language" ":" [CFWS] Language-List
Language-List = Language-Tag [CFWS]
*("," [CFWS] Language-Tag [CFWS])
The Content-Language header may list several languages in a comma-
separated list.
The CFWS construct is intended to function like the whitespace
convention in RFC 822, which means also that one can place
parenthesized comments anywhere in the language sequence, or use
continuation lines. A formal definition is given in RFC 2822
[RFC 2822].
In keeping with the tradition of RFC 2822, a more liberal "obsolete"
grammar is also given:
obs-content-language = "Content-Language" *WSP ":"
[CFWS] Language-List
Like RFC 2822, this specification says that conforming
implementations MUST accept the obs-content-language syntax, but MUST
NOT generate it; all generated headers MUST conform to the Content-
Language syntax.
Alvestrand Standards Track