I was not at the Atlanta meeting. I have three comments about the reported
minutes:
1. I strongly urge that nested transport encodings be abandoned. The first
so-called `advantage' (allowing 8-bit text in a message header) only
assists an encapsulated message. It's the wrong mechanism. The second
`advantage' assists gateways at the cost of enormous expense to the UA. I
believe that the burden properly belongs with gateways, which after all
don't have human users.
I understand that the Atlanta meeting did not want to solve this issue given
the absence of a number of key players. This is acceptable. However, this
issue is not going to go away and we should plan on confronting it ASAP.
I am on the record as vehemently objecting to nested encodings.
2. Re: Keld Simonson's documents, I think it is very important that we get
some additional East Asian input. I know that Taiwan is not happy with
either Unicode or the ISO proposals. I can imagine objections coming
from Japan, Korea, and China as well. Someone should make some attempt
to get in touch with the various standards organizations of those countries
(I think we can ignore north Korea; they seem to use mostly Japanese-made
products which use the ROK national system) and get some input from them.
It makes no sense to design something to accomodate their character sets
if they will refuse to use it.
I think that the Atlanta meeting did the right thing in approving both
documents as informational/experimental. It's just that I urge that we get
more input before committing ourselves, and not just from a few people with
East Asian e-mail addresses.
3. Type/subtype. I feel this distinction is important, and that all UA's be
required to understand all Types. The purpose of a Subtype is to introduce
a finer granularity.
I would like to see all types that are forms of a human-readable text be
coalesced under the heading of the Text type. Further distinctions may or
may not be relevant to a UA, but the fact that it is not unreasonable for a
dumb UA to `cat' text to the terminal is enough. Similar things apply to
other types as well.
My biases are perhaps showing here. I am expressly *not* working on a multi-
media mailer. That's a fun project to be started after everything else is
taken care of. What is crucially important at my end is textual mail with
attachments. I believe this Proposed Standard is the way to go, but I confess
at times being bewildered with "what does this mean in the context of what I'm
doing?" questions. There are open ends which I would like to see closed.
I expressly want to avoid what I call "silly behavior". I do not want to see
a new flavor of human-readable text appear that my program treats as binary
data. This is silly behavior; as is misinterpreting binary as text.
Another form of silly behavior is failing to recognize something I support
because of some trivial subtyping detail that I can ignore. For example,
suppose that of all the other funny stuff I support FAX. I know there is lots
of stuff out there I don't support, so the default behavior is to treat as
unsupported. I don't want a new form of FAX to appear that has some minor
difference and hence a new name, yet would work perfectly well if I treated it
as the regular form of FAX.
It was for these reasons that I advocated a heirarchical system, with the
notion being that you could stop at a particular point in the heirarchy and
support at that level and things would work as well as can be expected at that
level. Too much sophistication and complexity exists at the top.
These sorts of loose ends *must* be tied down.
-- Mark --