Erik M. van der Poel writes...
OK. So the point is: In much the same way that we have no control over
MTAs out there to try to send 8-bit SMTP through them, we also cannot
control the various pieces of software out there that form a reply to
a message by extracting certain headers, and so on.
Should we then conclude that the From, To, etc headers must be
self-contained?
Well, also in the spirit of reasonableness, I wouldn't go that far.
But RFC822 has two important properties that are taken advantage of by a
lot of software and that bear on this case.
(i) The order of headers is not specified (beyond a recommendation
about a few of them and the usual exception for the transport/trace
headers); they can come in any order.
(ii) Other than the transport/trace stuff, there are *no* interactions
among RFC-822-specified headers. They are *all* self-contained. One
does not need to know the content of one header, or whether it is
present, to sensibly interpret another.
I do think that we should relax or eliminate those properties only very
carefully, with due consideration, and with the implications on
existing, correctly-operating software as clearly understood as
possible.
These kinds of "one header references another" feature *all* involve
some risk. I'm not really suggesting that we don't do it--there may be
no choice--but that we make a sincere and careful effort to understand
the risk and than make engineering decisions as to what is appropriate
and what is not.
It does seem to me, intuitively, that some of these proposals are a bit
risker than others. I guess I'm arguing for "risk level" being taken
into account along with all the other factors as we try to pick on to
adopt.
--john