On Jan 15, 11:34pm, D. J. Bernstein wrote:
}
} Bruce Lilly writes:
} > header field order can (and does) change, so there's no way of
} > guaranteeing that a header-encoding header-field would always precede
} > use of any specified encoding
}
} So what? Does your MUA also have trouble displaying From before Subject
} when the From line in the message comes after the Subject line?
As I recall the discussion at the time (circa RFC 1342), the issue was not
the ordering, but rather that each header field needed to be interpreted
in isolation, because assorted transports (and maybe even some MUAs) could
not be counted upon to pass through a header field with an unknown name,
or to pass it undamaged. (It was some while before senders really had any
confidence that the RFC 1341 [no, that's not a typo] headers would reach
all recipients, unless I'm misremembering.)
The interesting feature of RFC 1342/1522/2047 is therefore not that they
maintain a 7-bit encoding, but that they package the character set (and
now language) information in one header field along with the content, in
a form that will not be disrupted by those transports that conform to an
earlier standard and that therefore do not expect a "known" field to be
carrying such a "package."
Of secondary interest, but another reason for not using a separate field,
is that the encoding can represent multiple character sets and languages
in that same single header. (Obviously that's not so significant if a
"universal" character set is available, but language information is still
of interest even if it isn't absolutely essential.)
Its true that the 7-bit encoding was chosen so that the "package" would
pass undamaged through the greatest proportion of intermediary software,
and that some of that software could arguably be called "broken," but
the politics were such that the people who wanted non-ASCII character
sets in headers did not have the clout to force most of the established
players to go along.
Guess what: Those politics haven't changed, though some people are now
on the opposite side of the figurative aisle. A number of posters have
argued that Usefor should recognize that the UTF-8 headers proposal has
no political future, regardless of its technical merits.
However, political arguments tend to encourage an accusatory tone with a
lot of mud-slinging, so I'm going to try to formulate a social position
instead.
Advocates of UTF-8 in usenet headers want to take the same chance that
1341 senders took -- that their content might not get through undamaged
everywhere, particularly when gatewayed -- rather than adopt a workaround
of the kind 1342/1522/2047 represents.
This doesn't seem unreasonable on the face of it, but the difference is
that RFC 1341 had no effect on the mechanics of message transmission;
it introduced no changes in any existing headers, and no syntactically
incompatible changes in the extended headers. The content might become
broken, but the process could not.
Changing existing headers to UTF-8 content *can* break the process; adding
new headers in UTF-8 *is not* syntactically compatible; and it *is not*
possible to predict where that breakage will occur or how the unexpected
syntax will be handled by software that conforms to older standards. Can
anyone refute any of those statements without resorting to probabilistic
arguments? Using anything but 7-bit in headers is a calculated risk.
It's one thing to accept a risk to your own data, but quite another to
standardize on something that imposes that risk on others, no matter how
unlikely you think it is that anything "really bad" will happen, and no
matter how desirable the outcome once all the breakage is "outgrown."
That, in my view, is why the proposal as it stands is not acceptable, and
is the issue that has to be addressed before an acceptable proposal is
possible.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net