Following its definition in RFC 3282, should the Accept-language header field be considered to be an email header field, in the sense of being a recognized extension of RFC 2822. (If so, what does it mean in the context of an RFC2822 mail message?) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
I don't think it makes sense to use the accept-language field, as it's currently defined, with email. partially this is because there's no clear indication as to whose preferences are being described, and partially because a reply to a message (the most likely use of accept-language) might go to the author, the reply-to field, some subset of to and cc recipients, etc.. more generally, I don't think it makes sense to try to add descriptive information about an address in a header field by using other fields that don't explicitly reference that address. (note that these addresses are sometimes changed in transit while leaving the other fields intact) Keith > Following its definition in RFC 3282, should the Accept-language header > field be considered to be an email header field, in the sense of being a > recognized extension of RFC 2822. (If so, what does it mean in the context > of an RFC2822 mail message?) -- Power corrupts; Powerpoint corrupts absolutely. - Vint Cerf
> I don't think it makes sense to use the accept-language field, as it's
> currently defined, with email. partially this is because there's no clear
> indication as to whose preferences are being described, and partially because
> a reply to a message (the most likely use of accept-language) might go to the
> author, the reply-to field, some subset of to and cc recipients, etc..
> more generally, I don't think it makes sense to try to add descriptive
> information about an address in a header field by using other fields
> that don't explicitly reference that address. (note that these addresses
> are sometimes changed in transit while leaving the other fields intact)
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.
As you might expect, I have observed a number of operational problems with
this header:
(1) Far and away the most common problem has been the absence of a single,
recommended field being defined for this purpose. As is so often the
case, this has led to a number of different fields being used, some
supported by some agents and others not. The fields I've observed
operationally are: X-Accept-language, Accept-Language and
Preferred-Language. I've observed X-Accept-Language to be the
most popular, but that's from a small and probably unrepresentative
sample.
(Continue reading)At 09:49 06/04/04 -0700, ned.freed <at> mrochek.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? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
> > 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
In <5.1.0.14.2.20040406210213.02e82d98 <at> 127.0.0.1> Graham Klyne <gk <at> ninebynine.org> writes: >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? This raises a more general problem regarding headers that migrate from one medium to another. AIUI, Accept-Language is already an official HTTP header. Therefore it will appear in the registry already, which itself should act as a strong hint that it is the preferred header-name for a similar feature in other media. But if you want to go further and list it under those other media, then you are required to refer to a defining document, and in such a case the defining document will say nothing about those other media. So is that allowed? I think the answer has to be that you go through the mechanism defined in Graham's RFC-to-be which is to ask the IESG (via their "designated expert"), following discussion in the "desginated email discussion list". Well, none of that machinery is set up yet, so I suppose discussing it on this list is the next best thing (BTW, could this list be designated for that purpose? I doubt the suggested somelist <at> iana.org will receive many subscriptions.) A similar problem arises with the User-Agent header. Currently, this is defined for use in HTTP, but is quite widely used in email and news. In this case, the USEFOR WG has taken it on board and is defining it as an(Continue reading)
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 --(Continue reading)
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: > > [[(Continue reading)
> AIUI, Accept-Language is already an official HTTP header. Therefore it > will appear in the registry already, which itself should act as a strong > hint that it is the preferred header-name for a similar feature in other > media. Why can't people understand that HTTP and email are different protocols that serve very different purposes and operate very differently? It is NOT desirable to encourage people to assume that it's okay to adopt fields from one protocol to another. Even if the fields keep the same syntax, they end up having different uses and different meanings, ambiguities can be introduced, etc. -- -- Regime Change 2004 - better late than never.
At 09:40 07/04/04 +0000, Charles Lindsey wrote:
>This raises a more general problem regarding headers that migrate from one
>medium to another.
I see no great difficulty here. Header fields can be listed under multiple
protocols so that these subtleties can be captured faithfully. The
registration document also notes that an entry may refer to multiple
specifications in cases like this:
[[
In some cases, the same field name may be specified differently (by
different documents) for use with different application protocols;
e.g. The Date: header field used with HTTP has a different syntax
than the Date: used with Internet mail. In other cases, a field name
may have a common specification across multiple protocols (ignoring
protocol-specific lexical and character set conventions); e.g. this
is generally the case for MIME header fields with names of the form
'Content-*'.
Thus, we need to accommodate application-specific fields, while
wishing to recognize and promote (where appropriate) commonality of
other fields across multiple applications. Common repositories are
used for all applications, and each registered header field specifies
the application protocol for which the corresponding definition
applies. A given field name may have multiple registry entries for
different protocols; in the Permanent Message Header Field registry,
a given header field name may be registered only once for any given
protocol. (In some cases, the registration may reference several
defining documents.)
(Continue reading)
RSS Feed1 | |
|---|---|
4 | |
27 | |
2 | |
9 | |
2 | |
21 | |
7 | |
1 | |
1 | |
2 | |
8 | |
37 | |
10 | |
154 | |
1 | |
7 | |
4 | |
16 | |
17 | |
129 | |
26 | |
25 | |
16 | |
4 | |
21 | |
25 | |
50 | |
15 | |
3 | |
4 | |
2 | |
3 | |
2 | |
10 | |
4 | |
8 | |
13 | |
1 | |
2 | |
6 | |
6 | |
7 | |
49 | |
74 | |
123 | |
12 | |
99 | |
104 | |
85 | |
122 | |
118 | |
289 | |
329 | |
273 | |
62 | |
1 | |
16 | |
20 | |
13 | |
80 | |
201 | |
33 | |
40 | |
177 | |
56 | |
32 | |
2 | |
36 | |
16 | |
6 | |
61 | |
280 | |
427 | |
58 | |
56 | |
83 | |
26 | |
95 | |
11 | |
176 | |
235 | |
126 | |
69 | |
240 | |
24 | |
23 | |
31 | |
43 | |
48 | |
10 | |
1 | |
25 | |
114 | |
12 | |
3 | |
19 | |
41 | |
16 | |
15 | |
17 | |
8 | |
2 | |
8 | |
14 | |
15 | |
6 | |
137 | |
2 | |
16 | |
11 | |
22 | |
2 | |
11 | |
13 | |
93 | |
88 | |
50 | |
8 | |
29 | |
50 | |
65 | |
81 | |
3 | |
4 | |
4 | |
82 | |
39 | |
6 | |
75 | |
82 | |
12 | |
2 | |
1 | |
3 | |
1 | |
1 | |
3 | |
6 | |
33 | |
14 | |
8 | |
10 | |
2 | |
11 | |
29 | |
6 | |
21 | |
47 | |
14 | |
1 | |
17 | |
55 | |
46 | |
83 | |
36 | |
23 | |
109 | |
138 | |
187 | |
208 | |
210 | |
100 | |
55 | |
45 | |
23 | |
57 | |
2 | |
18 | |
10 | |
34 | |
52 | |
159 | |
112 | |
141 | |
86 | |
16 | |
104 | |
78 | |
126 | |
324 | |
205 | |
165 | |
96 | |
17 | |
16 | |
13 | |
34 | |
55 | |
57 | |
30 | |
94 | |
201 | |
212 | |
103 | |
186 | |
150 | |
384 | |
293 | |
98 | |
88 | |
136 | |
111 | |
209 |
