I don't have a lot of spare time to spend educating people who seem to
not want to listen. One thing.. please move the discussion out of
the ietf list since it belongs over here in ietf-822.
Others, especially Mark Crispin's note, have said most of what I want to
say. I want to elucidate a few particular things.
[This is primarily directed at Al and Robert..]
(me)
- mixes the concepts of body part type and encoding type into one
pile of names.
(Al)
This is an important concept. If you see a problem with this please be more
specific. The "pile of names" are keywords, these word define what a body
is encoded as. The type of encoding may have a seperate set of keywords that
further define a part or section of a part. This allows one keyword or
nested keywords suffice in the "Encoding:" header field.
Yes it is an important concept. Too bad y'all are getting it wrong. Rather,
that you have a not-terribly-useful point of view from which to start.
The particular `encoding' something happens to be in at the moment is
pretty darned irrevelant. It *is* useful for getting the bits through
the network undamaged, but that is exactly as far as its usefullness
extends. Using the encoding name to label the type of the thing does
no good to the user.
Just a minute ago I wrote a message to someone else on this topic. He's
an MIME implementer and I saw a message a user of his had sent structured
like so:
multipart/mixed
text/plain
application/UUencode;..;name="ugly\ms-dos\filename.jpg"
In other words, taking the same standpoint as RFC-1154 does in making
the encoding the principle labeling.
This violates a number of principles of MIME.
- Mixing metaphors of `encoding' versus `type'.
- Using non-standard things without marking them as such.
- Ignoring existing type names to explicitly label the type of the thing.
One of the most important and useful things which MIME does is provide
an way to explicitly label what kind of data is there. The encoding
is not important. It is there merely to make sure the data is safely
transported from end to end. MTA's are quite free to rip a message apart
and re-encode them, but they are expected to not do so gratuitously.
If the type/subtype is named from the encoding used then you break
all of those assumptions.
The message should've been:
multipart/mixed
text/plain
image/jpeg
(with a Content-Description giving the file name?)
The Content-Transfer-Encoding could have been x-uuencode, and is
the ONLY place where an encoding name should have been mentioned.
With the body part labeled clearly the UA is able to have a table
containing mappings to a couple of actions. These are to viewer
and/or editor programs. On Unix, the entry might be:
image/jpeg xv (dunno what the editor for jpeg is..)
since xv is a fine viewer of jpeg's. With this table the UA can
realize what to do when the user asks to view that thing. It (1)
decodes from whatever the current encoding is, and (2) runs the
viewer program.
If it is labeled `application/Uuencode' all the UA can do is decode it.
It has no idea what to do beyond decoding the thing.
Therefore isn't the user more satisfied with the result when you
use image/jpeg from when you use application/uuencode?
- only supports the "full range of the ASCII character set"
What is the problem here?
There is a large part of the world for which ASCII is a completely
foriegn language. How do you expect to exchange mail with them?
- has no body part structuring other than `message' body parts
Please show me a need and I will consider it.
The document announcements the IETF sends out are pretty cool. With
a small message you're able to send out a SHORT announcement describing
the thing. The user can read it. Then it contains multiple alternative
ways of giving direct access to the thing. A cooperating UA can nicely
and easily present these alternative access methods giving nice and
automagic access to the documents.
This should be really important for people connected to the net
via slow modems. Something happening more often with the explosion
of laptops out there.
(Robert)
The authors of 1154 realized quite early on that there was a basic
difference in philosophy, and the people arguing loudly for (what
would become) MIME had entirely different objectives from Encoding.
Like I said above. Encoding is merely armor coating to make sure
the data gets through. It is much more useful to use types to describe
the type and encodings to describe them.
<- David Herron <david(_at_)twg(_dot_)com> (work)
<david(_at_)davids(_dot_)mmdf(_dot_)com> (home)
<-
<- "That's our advantage at Microsoft; we set the standards and we can change
them."
<- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.