Excerpts from internet.ietf-822: 14-Oct-91 2 points for rfc-xxxx Bob
Smart(_at_)mel(_dot_)dit(_dot_)csiro(_dot_) (1340)
1. RFC-822 specifically says that cntl-H should be used to give overstrike
semantics. In fact I don't know of any mail readers which obey this aspect
of rfc-822 except perhaps when used on an LA34. So I think in the section
which discusses the meaning and non-meaning of control characters it should
explicitly cancel this aspect of rfc-822 which is in abeyance, particularly
as rfc-xxxx provides much better mechanisms for representing things like an
O with a / through it.
Actually, I've seen it used pretty often for underlining -- so often
that this year, after years of being annoyed by it, I patched Andrew so
that it could turn such sequences into real underlining. So it isn't as
completely in abeyance as you imply.
2. RFC-821 describes a mechanism for transporting a message with a line with
a single "." in it. Putting that in rfc-821 now looks wrong. The correct
approach is for rfc-821 to say "this mechanism can only be used to transport
messages in which a single period on a line by itself is encoded away or
is not allowed." The act of dot-doubling to comply with this is an
encoding rule in the 7bit Content-TransportEncoding of rfc-xxxx (and of
the 8bit encoding). This encoding rule is not needed in base64 or
quoted-printable encodings.
Oooh, that sounds like a major can of worms. There's no reason to
think, though, that this needs to change. 821 or any other transport
protocol can define any mechanism it wants for moving an 822 (or XXXX)
message from point A to point B. It could specify that every character
be converted into Baudot codes, transported, and convert back, if this
could be done without loss of information. It could specify that lines
with just a single dot on them could only be transported if a special
telephone call is automatically placed to an IETF 900 number. As long
as what comes out the other end ENDS UP being the same as what went in,
it isn't relevant to something at the level of 822 or XXXX. And, since
it ain't broken, I don't want to fix it.
It is pretty important that we distinguish carefully between the encoded
and unencoded messages if things like John Klensin's SIZE command are
to be introduced into SMTP. However you don't have to support the SIZE
command to support the idea of making this distinction in this way.
If the SMTP layer doesn't have to worry about the encoding when
transporting the mesage, then there's no ambiguity here at all: size
refers to the number of bytes (or whatever) on the wire. Even a smart
SMTP that did encoding conversions would still have no problem here --
the SIZE command would refer to the number of bytes on the wire,
regardless of any encoding or unencoding that might happen on either end.
Again, I don't think it's broken and I don't want to fix it. -- Nathaniel