D. J. Bernstein wrote:
Keith ``7 bits forever!'' Moore writes:
your naivete is showing even worse than usual -- about what was
technically feasible at the time, what was politically feasible at the
time, what would interoperate with the installed base at the time
The ietf-smtp archives aren't a secret, Keith.
We can all see that, early in 1991, Robert Ullmann and Andre Pirard and
others proposed requiring 8-bit-clean mail software. This requirement
should have been adopted.
We can all see that the only objection to that requirement was the claim
that 8-bit support would take a long time to be deployed. You were aware
of the massive long-term benefits; you simply refused to plan ahead.
For example, Paul Vixie said that he had some seven-year-old sendmail
binaries, and concluded ``with near-certainty'' that ``any changes to
the SMTP spec will take at least a decade to reach 90% of the critical
server population.''
If knowledgeable people are asked to name those who can speak authoritatively
about sendmail and SMTP, Paul Vixie's name is one of the three that are likely
to top the list (others being Allman and Avolio). If that was 1991, and here
we are "at least a decade" later and 90% (possibly more) of SMTP software
still doesn't comply with RFC 821 (which requires a space character immediately
preceding the semicolon which delimits the time stamp in a Received header),
the conclusion is that Paul's predictive ability is quite good -- and (N.B.)
that's a fundamental aspect of the syntax, clearly given in ABNF, and one
which hasn't changed until recently (2821 relaxes the requirement to mandatory
CFWS before the semicolon). Indeed, there is some software that fails to
comply with even the *basic* requirements for an RFC-821 time-stamp line,
such as the *required* "from" and "by" clauses,
e.g.:
Received: (qmail 13349 invoked by uid 1016); 15 Jan 2003 02:09:13 -0000
The ietf-smtp archives aren't the only things which aren't secret...
Similarly, UTF-8 support should have been required in all mail software
when RFC 2277 was published five years ago.
Untagged UTF-8 is incompatible with section 4 of 2277. 2047/2231 (which
predate 2277) are compliant with 2277. Before invoking RFC 2277, you might
try reading it.
For those still advocating untagged utf-8; note RFC 2277 section
3.1:
All protocols MUST identify, for all character data, which charset is
in use.
"identify" and "untagged" are diametrically opposed.
and section 4.2:
Protocols that transfer text MUST provide for carrying information
about the language of that text.
> Instead, according to your
so-called ``standards,'' it's perfectly acceptable---in 2003---to deploy
a mailer that throws away everything other than ASCII.
No, according to standards-track RFCs and BCP RFCs it is unacceptable to
have untagged, unencoded non-ASCII (and some ASCII) content in Internet
text message headers and MIME-part headers. One cannot speak of "throw[ing]
away" something which cannot be there in the first place.
According to your half-baked ideas, it's perfectly acceptable to ignore the
Best Current Practice RFC 2277 -- the very one that you are trumpeting -- which
clearly and unambiguously states that charsets MUST be identified and that
there MUST be provision for carrying language information.