Nathaniel Borenstein writes:
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 was not being clear. As you read it my message was certainly incorrect. But
what I meant to say is still a problem with the Real- proposal. Let me try
again...
Suppose you're constructing an message with fancy stuff in one or more of the
phrases in front of the route-addrs. Nathaniel's proposal is to simply go ahead
and put this stuff in the Real- version of the headers. Fine. But now the
old-style headers have to be generated, and they have to contain something that
reasonably matches what the Real- headers contain. The phrase in front of the
route-addr is not optional (well, it was made optional in RFC1123, but there
are still plenty of mailers that have not caught up to this). So you have
to generate something to fit that slot as well. And how, pray tell, do you
do this? Well, mnemonic comes to mind as a reasonable approach, as does
quoted-printable.
But this then causes the exact same problems that you get if you just generated
the regular header lines without doing the encoding! In other words, you have
solved nothing by adding the extra headers -- you still have to generate the
original required set of headers. Yes, you can omit comments since they are
never needed. But phrases cannot be ommitted, I for one would not like seeing
Real-Subject: without a corresponding Subject:
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.
The problem with the Real- scheme that I see is that it only adds additional
information and leaves the underlying problem (what to put on the regular set
of headers) untouched.
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. --
If you're troubled by mnemonic-in-existing, the Real- approach offers
no solution. You still have to generate something for the existing headers,
and what is that going to be?
Ned