I agree with Marshall Rose that we should get rfc-xxxx out ASAP and
let 8-bit transport come along at a later time if possible. The
interaction between rfc-822 extension work and work on transport issues
has been beneficial in understanding what things like base64 encoding
really mean, and this has been helpful to getting rfc-xxxx right.
I agree with Mark that there is no reason for 8 to be a distinguished
number in the definition of network protocols. If we defined things as
sequences of bits instead of sequences of octets then things like the
how-to-represent-a-MAC-address stuff-up would not have happened. However
it has to be said that sequences of octets are the current tradition
including TCP and so there _are_ good reasons why 8 bits is a unit of
data that people will want to transport with particular efficiency.
There is a good reason why rfc-xxxx should describe 8-bit and binary
message formats for messages even if rfc-821 is never enhanced. Other
transport protocols can be defined which use rfc-822+xxxx as the
format of the message they transport. We have seen phonenet in the past,
plus MHSnet in Australia, and also the network news protocols. If we
don't define binary and 8-bit formats for messages then others are
likely to start doing it in an unstandardized way.
As far as finalizing rfc-xxxx and pushing it over the wall, there is
only one undecided matter that I know of: how to represent characters
other than us-ascii in the free-format parts of headers. Whatever
we pick will have to be 7-bit clean: it must comply with the requirements
of rfc-821 when those requirements are expressed in terms of octet
numbers not glyphs. To me there are only 2 possibilities:
1. Use Mnemonic.
2. Allow the header character-set to be specified and either fix the
7-bit encoding to quoted-printable or allow it to be specified as well.
The latter has a key disadvantage: an extra header (or 2). Its advantage
is that the people currently using 8-bit transport + already putting 8-bit
octets in headers will have a slightly easier transition.
A key advantage of the former is that mail going through mailing lists
to people on 7-bit mail-readers will see something much more readable. Of
course with (2) people can still specify Mnemonic and it will be a great
waste of an extra header if they invariably do that. There are quite enough
headers already.
A small disadvantage of using mnemonic as the universal header character set
is that there is a vanishingly small probability of non-fatal but slightly
confusing interaction with mail software currently using Content-type
headers.
An advantage of (2) is that we could recommend the use of quoted-printable
encoding in such a way that the tricky quoting requirements of rfc-821
never need to be invoked: E.g. a double-quote character should be represented
as :22 so that it doesn't have to be quoted. The only problem with this
is that ":" is a special character in rfc-822. So if we go this way it
would be helpful to change the quoted-printable hex lead-in character to
one that is not an rfc-822 special character.
I'm sure that if Marshall Rose wants to get rfc-xxxx finished he might like to
contribute to this debate and help finish it off. He is certainly more likely
than me to be able to speak with authority on practical interoperability
problems that either of these options are likely to cause.
Bob Smart