I have a need to localize the human-readable text inside of DSN's and
other automated responses to 822-format messages. Here is a proposal I
would like to float here, prior to issuing an internet-draft.
Rough definition:
Define an "Accept-Language" header with the following syntax.
accept-language = "Accept-Language" ":" 1#Language-tag
; Language-tag as defined in RFC 1766
This header discloses the language preference(s) of the sender.
Languages listed earlier in the list are preferred.
I agree with Larry that use of Accept-Language: in this fashion, which doesn't
correspond to the HTTP semantics, is a showstopper. The IETF has both critiqued
and modified HTTP usage where that usage conflicts with MIME, and I think the
IETF was correct in doing this. But it is only fair that when the shoe is on
the other foot, and we're defining stuff for MIME-based but non-HTTP-based
protocols like Internet mail, that we pay attention to HTTP usage and not do
things that conflict with it.
There are two ways to solve this problem. One is to use the same field
name and keep the semantics the same. The other is to define a new field
with limited semantics.
I see problems with both approaches. The first seems excessive for the
stated application. And the second only solves this one problem without
providing a basis for other sorts of capability discovery (e.g. discovery
of support for things other than langauge, support for different capabilities
for different sorts of messages like notifications, receipts, replies, or
new mail).
Capability discovery in email should either be done right or not done at all.
A point solution specifically for this one limited application is a good
idea if and only if we decide right her and now that this is the only
sort of capability discovery we ever intend to do. And since I do not believe
that this is the only sort we want I don't think this is a good idea.
The existence of this header also indicates that the sender is capable
of handling text encoded in the utf-8 charset [RFC 2044], when properly
MIME labeled.
I agree with Larry about this as well -- the issue of language and character
set are largely orthogonal, and as such should not be coupled in this bizzarre
way. I have no problem with a mechanismm that lets you say you want responses
to be in UTF-8 per se; however, such a mechanism should be part of a more
general capability discovery system and not coupled to language like it
was an afterthought as this proposal does.
Does not necessarily work correctly if the message goes through list
expansion. The language preferences of the list maintainer can be
different than those of the original sender, so if the list expander
does not know to strip or replace the Accept-Language header, the list
maintainer could get DSN's in a language and charset they don't
understand.
This is exactly why such a mechanism has to be done right -- there's
clearly a distinction between what the list moderator wants in notifications
and what a message originator wants in a reply. And don't think for a
minute that should you define a field like this that it won't end up being
used to control other sorts of automated and even manual replies -- it will.
Ned