One additional issue that no one has raised and that I hope Dave Crocker
will comment on. Dave, you listening? ...Followed by a few smaller
issues...
While the language of RFC822 somewhat obscures it, the intent of the
phrase <mailbox(_at_)domain>
syntax was, at least in part, to permit routing, by means other than
RFC821/822, to multiple distinct individuals who share the same mailbox.
This is in spite of the fact that some UAs (including the one I'm using
:-( ) can't get this syntax right.
While no resolution emerged that was clear enough to justify a
SHOULD/MUST statement, there was discussion in HR about whether some
sending agent that was cleaning things up to avoid multiple delivery
could/should construe
a <mailbox(_at_)domain>
and
b <mailbox(_at_)domain>
as equivalent, i.e., if one or the other could be deleted and which one.
The relationship of this problem to, e.g., the "Real-XXX" proposal is
that one cannot treat this phrase subfield, as distinct from "(...)"
comment fields, as information-free for addressing purposes. Some clear
convention is needed, either that the phrase in the RFC-XXXX address is
the critical one and the corresponding Real-XXXX header becomes "correct
spelling if anyone is interested" or that removes the phrase and points
to "Real-XXX".
For the latter, one might require
From: "*" <user(_at_)domain>
Real-from: ...
or something similar, rather that permitting arbitrary text in the
"From:"-phrase.
I think it is important to not lose track of this particular bit of
interoperability in the process of solving broader problems.
-----------
I want to add my support to those who are distrustful of the ability of
systems to properly handle RFC-822 quoting conventions when those are
used intensely. That is an argument against "just use mnemonic or
quoted-printable in the primary headers". Please keep in mind that we
have mail systems around that will bounce mail because they don't like
certain headers, even headers that are none of their business. These
problems are also the sources of some elegant and user-friendly error
messages of the "Unknown error N" persuasion.
That said, the notion of a lot of headers that have subtle
interactions and that must all be considered together doesn't appeal to
me very much either. In the present RFC822, if I find a From field, it
is plausible and rational for me to assume that it contains the "From"
information. A proposal that says, "but, hey, you also have to scan all
of the other headers looking for Real-From in case there is
supplemental information there" is scary. If nothing else, it feels
subjectively as if it is one of those slippery slope problems, e.g., we
might want to evolve to
From: ??? <user(_at_)domain>
Real-From-phrase: @#$%^&
Read-From-Address: /ADMD=Internet/SU=User/...
It does have its attractions, but...
And that is an argument against the "Real-XXX" strategy. So I agree
with what I understand Nathaniel to be saying: there may be no really
clean solution here.
---------------
If we are going to do Real-From, Real-to, etc., we also need
Real-Resent- and all of those, and maybe Real-Forwarded-... and all of
*those*. Also Real-reply-to, which I don't remember seeing listed.
The other concern is that there are a number of commonly-used, but not
RFC-822-specified, headers that one might want to represent using this
model. For example, would one expect to want to see:
Organization: some ASCII-ized spelling
Real-organization: organization name in mnemonic or quoted-printable.
----
The other arguments against variations on "put mnemonic into the phrases
themselves", supplemented by a "Header-charset" header, are that unless
ordering is imposed, the headers may need to be scanned twice and we
violate the "try to not dump garbage on the user" principle for 822 (but
not XXXX-conforming) mail receiving/reading systems.
--john