With quoted printable, this message can be sent in such a way that it
is essentially readable in its "raw" form, on any ASCII terminal. If
we encoded it in base64, it becomes gobbledygook in the absence of
decoding software. This is the primary rationale (there are others)
for the existence of quoted-printable, and I think it's a darned good
one...
If we encoded it in quoted-printable, it becomes gobbledygook in the
absence of decoding software. This is the primary rationale (there
are others) for the existence of mnemonic, and I think it's a darned
good one... :-)
Seriously, I doubt that quoted-printable will catch on for such things
as German text. Maybe for Makefiles, but not for German text.
This is all fine and dandy if you know what character set is being used. You
definitely should know this if you're talking about text/plain messages. But
there are lots of other sorts of things we send via mail. Many of them don't
break down cleanly into a single character set. Others involve multiple
character sets and cannot be characterized by a single external character set.
The utility of mnemonic methodology is, in my opinion, very high. I have always
supported it very strongly. But mnemonic is only appropriate when a message has
a 1:1 mapping from its bytes into a single character set definition. You don't
have to go very far past plain text before this condition no longer holds.
Material containing complex escape sequences is an example of a type of object
where a mnemonic encoding won't work terribly well. And don't bother to claim
that it is possible to recognize and exclude escape sequences from character
set conversion. This is only possible if you comprehend the syntax of the
sequences themselves, and many uses of escape sequences are not even vaguely
related to ANSI or ISO specifications. (I see escape sequences that involve the
use of 8-bit characters quite frequently, so the impact of this on encoding
methodologies is obvious.) If you want to experiment with a system that tries
to exclude escape sequences from conversion you might want to look at Kermit.
This approach is valuable in certain restricted circumstances, but it has
proven to break down quite often too.
In conclusion, then, it is definitely true that mnemonic has its place in the
scheme of things. Given the current nature of messaging, which is
overwhelmingly biased towards text/plain, mnemonic may well become a dominant
encoding, if we can ever reach closure on it. But mnemonic in no way obviates
the need for quoted-printable, which is the encoding of choice for text objects
that cannot be conveniently categorized as being in a given character set.
If we just took the small step of defining the mnemonics of *only* the
Latin-1 set, we would satisfy quite a great need. I feel that it is
much more likely to reach closure on something like this than the
humungous set being proposed by Keld, for which we have no clear "OK"
signals from the myriad user communities directly affected by such a
proposal.
I'm not sure what the size of Keld's proposal has to do with anything.
Certainly none of the objections I've heard about have had much to do with the
size.
The first significant problem with closure, as I see it, is the reliance on the
character naming conventions of 10646. I personally don't have a problem with
this, but there appears to be a procedural problem with citing a DIS document.
Since I am not the one with a problem here I don't really have much more to say
about this point -- it has to be handled as an issue between the author and
IESG/IAB folks who see this as an issue.
The second significant problem with closure is a bit more nebulous. It
basically has to do with conformance. What does conformance to RFC-CHAR mean? I
don't see any really good way to measure conformance to RFC-CHAR. RFC-CHAR
is a tabulation of the characters in a bunch of different character sets. It
also defines useful mnemonics drawn from a restricted invariant subset that
can be used to represent characters in a more-or-less readable form.
Of course the notion of conformance is also a procedural matter, and as such
it is not a matter for me to tackle either.
If you have additional problems with RFC-CHAR I'd like to hear what they
are. But issues of scope are not a valid area of concern for the Working
Group, in my opinion. The scope can be reduced on review by the IESG if that
is a problem for them.
I have been told that ISO 8859-7 (i.e. 8-bit) is just fine in Greece.
Stay tuned for the next version of the multilingual encoding draft,
which will take into account some of the realities that we have bumped
into lately.
I won't comment on this apart from saying that I'm reluctant to pursue two
mnemonic approaches at once. If you could work out your differences with what
Keld has proposed and come up with a unified result I think we'd all be a lot
happier. (I have found that Keld is more than willing to listen to suggestions
on how to modify RFC-CHAR to make it a better specification.)
I also feel that this group has basically given Keld the go-ahead to continue
the development of RFC-CHAR, with the stated goal that it will become a
standard. If the group has changed its mind on this point I'd like to hear
people say so in so many words. I quite frankly don't like what I see happening
here -- I see a possibility that RFC-CHAR will be abandoned, and I think this
is a huge mistake.
Ned