There seem to be two contradictory points being made:
1) Some transports/user-agents which claim to be 8bit cannot in fact
deal with octet values in the 1-255 range.
This would appear to be an argument that 8bit should be more
restricted than 1-255. If this argument is being made, I would like
to see examples of such transports/user-agents.
That's what Keith tried to make. Isn't he in your camp?
2) Transports/user-agents that cannot pass NUL are "broken".
This would appear to be an argument that 8bit should be 0-255 and/or
that 7bit should be 0-127. Given the large body of mail software
(both transport and user-agent) that currently cannot deal with NUL
and given the widespread use of NUL-terminated strings in such
software, the cost of taking such an approach would be enormous.
Do you think these transport, in the future, should support true
binary?
Or, do you think we should avoid using NULL even with binary just
because there are widespread use of NUL-terminated strings?
I would like to see more concrete arguments of the advantages of
allowing NUL, to offset these costs.
If you drop NULL this time, we will see the argument of "the widespread
use of NUL-terminated strings" again for binary.
If 0-255 binary SHOULD be supported, 0-255 requirement for 8bit means
no extra cost.
Masataka Ohta
PS
It's OK to document that there may be broken implementations, which
is totally different from writing a broken specification.