To follow up a bit more on Nathaniel's response to Bob Smart...
-- Yes, BackSpace overstriking is used, and several mail readers/
writers support it, both for character format and for overstrikes.
Regardless of what one thinks of it, I don't think it is reasonable for
rfc-xxxx to "cancel" *any* provision of RFC 822. Conforming RFC 822
processors have to remain conforming, period. RFC-XXXX can impose
additional restrictions if they are needed, but those restrictions become
enforcable iff there is explicit agreement between sender and receiver
that XXXX, and not 822, is being used.
I know that view imposes a very strong restriction, but I think it is
needed. Anything else launches us down the slippery slope toward "just
declare new systems more functional and older ones disfunctional" (which I
gather is the approved new way to say "broken"). Let's just take whatever
RFC-822 says as a boundary constraint and work within it. If one doesn't
like what it appears to say, that is an HR matter, not an RFC-XXXX one.
Similar comments apply to 821. A mail transport mechanism has to have a
definition that permits it to figure out when the end of the message is
encountered. If it distinguishes between false end-of-message and real
ones with a doubling or quoting convention, that is its problem; the
message format should not care. The double-period stuff is the one case
where 821 specifies the convention and the MTAs do the coding and decoding
as needed. If 821 had specified other coding issues as MTA problems, we
wouldn't have the nested encoding issues. But it didn't, which turns
those problems into delicate engineering problems.
Those of you who have had the misfortune to look at the current RFC-ZZZZ
document know that it explores the end-of-line and end-of-message concepts
in fairly general ways. That exploration should, if nothing else, help to
reinforce the idea that these are transport problems.
And similar comments also apply to "SIZE" issues, whether in an extended
SMTP commands or elsewhere. You hand something to a transport-beastie and
say, more or less, "get this to there, paying as little attention to what
is in it as possible and please don't lose or make up anything". What
envelopes it uses, and how it structures those envelopes, are not your
concern, at least as long as it works. I don't see any interactions here
and I think that we would get ourselves into deep conceptual trouble by
trying to invent them.
Regards from Munich and a network connection that closely resembles the
other end of a wet string with two cans.
john