Mumble. I've always been opposed to the idea of a registry that would
endorse the decisions that the market makes, because while the market
might serve as a rough indication of what features are needed, the market
sucks at protocol design. And yet I do to some degree accept the argument
that once the market has chosen a particular feature, it's very difficult to
get the market to adopt something that is significantly different.
Another way of saying this is that if we fail to produce a good design
sufficiently early, the market will produce a bad design in our place.
Still, I'd rather have a published statement that says
"Accept-language wasn't designed for email, but has been found to be useful
as input into the generation of automatic replies. It should apply to the
SMTP MAIL FROM or Return-Path address rather than some other address."
than a published statement that, by failing to specify usage, encourages
even more variant use than we're currently seeing. Because even if we
claim that the registry is just documenting current practice, it's going
to be cited as an authority for desirable practice.
Keith
Personally, I'm neutral about its inclusion. So far I have a very small
sample of opinions that are 2:1 in favour of inclusion, but clearly there
are some concerns. To the extent that the registry is intended to document
actual behaviour, not define new behaviour, I suggest inclusion as
"informational" with a comment along the following lines:
[[
Indicates a language that the message sender requests be used for responses.
This header field [[[Accept-language]]] is commonly used in email, but some
problems have been noted, including but not limited to: determination of
the email address to which it refers; use of different field names names
by some mail agents for the same purpose; lack of consistent recognition
and use by receiving agents; cost and lack of effective
internationalization of email responses; problems with interpretation of
language subtags; problems determining what character set encoding should
be used (UTF-8 is not universally supported).
]]
But if it proves difficult to quickly find an acceptable form of words to
accompany its inclusion, I propose to withdraw it from an *initial* set of
header field registrations, so as to not hold up the inclusion of standard
header fields for which there should be no dissent.