Re: Accept-language in permanent email header field registry?
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.
#g
--
PS:
Current published I-D for initial registrations is:
http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-02.txt
Current unpublished work-in-progress is at:
http://www.ninebynine.org/IETF/Messaging/draft-klyne-hdrreg-mail-03.html
http://www.ninebynine.org/IETF/Messaging/draft-klyne-hdrreg-mail-03.txt
I hope to publish a version ready for last call review in the next few
days, pending a decision on this question.
At 14:46 06/04/04 -0700, ned+ietf-822(_at_)mrochek(_dot_)com wrote:
> Let me start by pointing out that the accept-language is currently in
fairly
> widespread use in email. A number of very popular clients generate these
> headers and a fair number of automatic response agents honor them. Strong
> customer demand led us to support them in the autoresponses our product
> generates a few years ago, which means I have a fair amount of
> experience with
> them and the problems they do and do not have.
Notwithstanding the operational problems you mention, this suggests to me
that Accept-language should be included in the initial (permanent) registry
of email message headers, possibly carrying a warning about the operational
issues you note?
To the extent that having a single, standardized header for this would
create a
trend towards using a single field name and would prevent additional field
names from being used for this purpose, I support having this in the registry.
OTOH, I have more important things to do than engage in a protracted wrangle
about how this field binds to addresses or anything similar. The market
appears
to have decided on a "good enough" solution to this problem; the IETF can
either back this solution with a particular field name or not. It isn't going
to be able to effect more change than that.
Ned
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact