A group that is working on Vietnamese character set encoding has
mentioned to me that they plan to use part of the C0 space of US ASCII
for Vietnamese precomposed characters. They wish to be conformant
with the RFC-XXXX and RFC-ZZZZ requirements.
Arggh. Putting graphics there would violate both X3.4 ("US ASCII")
and the ISO646 and ISO8859-n norms. It is a bad idea, independent of
the Internet, and will probably lead them into trouble.
One could read RFC-822 and interpret it to mean that US ASCII meant
US ASCII, including control characters -- and hence that a MUA would
be within its rights to interpret them accordingly.
Yes, one certainly can.
On the other hand, are there mailers that do that ?
The answer to this question differs depending on how you define
"mailer" and "do that". Let's take the broad definition and assume that
"mailer" encompasses the whole set { user, message composing software,
mail user agent, originating mail transfer agent } and symmetrically at
the far end, substituting "message presentation software" for "message
composing software". In that case, the answer is "certainly there
are". The C0 positioning controls (HT, VT, FF) are heavily used in mail
messages, and almost everything things that they should go through in a
reasonable way. I even think (but I don't have it in front of me and
might be confused) that RFC822 mentions these and suggests doing
something intelligent with them. More broadly, and whether it is a good
idea or not, some software assumes that it is appropriate to send and
expect the receiver to interpret, X3.64 device control sequences ("ANSI
terminals").
It seems counterproductive to be more restrictive than we need to be.
There are several characters in the C0 set that could probably be
safely seized, but not a lot. And some receiving MUAs, out of concern
for electronic message bombs, will filter any C0 character whose
interpretation they are not sure of. That behavior would be unhealthy
for graphics also.
I'd like to see the RFC-XXXX draft revised to make this issue
clearer in the text of the draft, regardless of what the "correct"
interpretation turns out to be.
I don't want to disagree with this, but it may be that RFC-XXXX is
ultimately going to need, in parallel with, e.g., subtypes for "image",
either a series of appendices or supplemental RFCs that say, more or
less, "this is the name by which a character set is called, this is the
associated reference to, e.g., an ISO Standard, and these are the
special rules about how it is to be used". In other words, while I'd
love to generalize about C0, there may be some character sets that one
would like RFC-XXXX to carry for which the generalization might not
work. 2ndDIS 10646 might be one of them, so this is not a purely
theoretical issue.
--john