Excerpts from mail: 22-Sep-91 Re: New-ish idea on non-asc.. Keld J|rn
Simonsen(_at_)dkuug (1700)
Why not explicitely state where in the syntax to allow it.
822 has a rigid definition of syntax, and our enhanced character
support could be applied in the texts, e.g. in "text", "ctext"
and "dtext".
``ctext'' would be OK, except that comments (where ctext is used) may be
used in MTA-generated Received: headers. (An MTA that I wrote years ago
puts comments in its Received: lines.) Does this mean that all MTAs
must check whether comments are to be encoded before printing comments
in the Received: header, and encode the comment text as required?
The use of ``dtext'' has, so far, eluded me.
``text'' would be OK, at least as it refers to text strictly in headers.
All in all, lots of encoders and decoders will get this wrong. More
egregiously, it seems to require that MTAs change overnight. By
contrast, the RFC-ZZZZ proposal requires that MTAs that want to send and
receive 8-bit characters will use a special protocol before doing so,
and therefore the new rules apply only to those MTAs that agree to
accept 8-bit data.
So far, it still seems unworkable. I'm quite opposed to any version of
this that requires changing all the MTAs everywhere. I'm still rather
opposed to a version of this that edits the RFC-822 rules in ways that
will be open to mis-interpretation, or that will be so complex as to
encourage lazy implementation. I see the need, but I don't yet see a
working system.
Craig