Ned is of course right that all of the funny characters *can* be quoted.
The question is, should they be? Now if we want to put a non-US-ASCII
name in a From field, we have to first encode it in quoted printable,
and then quote it to get it past the 822 rules. Pretty ugly.
Excerpts from mail: 19-Sep-91 Re: New-ish idea on non-asc.. Ned
Freed(_at_)HMCVAX(_dot_)CLAREMO (4744)
I would also like to reiterate that the same problem Nathaniel identifies
here also applies when you're generating the regular headers (from the
Real- headers). You have to choose some subset of whatever 8-bit stuff
appeared on the Real- headers to appear in the regular headers (note
that the syntax of RFC822 does NOT permit the simple omission of all
the fields we're talking about here -- there are some fields, notably
phrases, that are syntactically mandatory.
Pardon me, but I think this is just plain wrong. By my reading of RFC
822, a newly-defined header is constrained only by the definition of
field-body-contents, which comes down to the definition of "text":
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
So I don't think any quoting at all is required for the newly-defined
"Real-XXX" fields. In particular, I think that anything encoded in
either mnemonic or quoted printable will be fine for the bodies of these
fields. Much simpler, isn't it?
I still think that the Real-XXX scheme is preferable to putting
non-ASCII text in the established headers such as From, etc. I think
the latter is at least skirting the edge of serious problems of backward
compatibility. Are there any problems with the Real-XXX scheme? I
haven't really heard of any.
I can live with leaving it out or with puttting in the Real-XXX stuff,
but I'm troubled by the mnemonic-in-existing-fields scheme. --
Nathaniel