Excerpts from mail: 10-Apr-91 Re: text --> IA5 ? Dave
Crocker(_at_)Pa(_dot_)dec(_dot_)com (828)
A body part has several levels of context, or interpretation. In
theory, the number of levels might get quite large, and our attempting
to handle the theoretical maximum, or the possibility of infinite
nesting, will bog us down. But just for the heck of it, let's try the
following:
I've tried it on, and I don't think it fits.
1. How I, the sender, want it interpreted; e.g., run the BP through a
program that is located in file foo/bar
Like, maybe, a program that just knows how to display 8 bit text? 7 bit?
2. BP consists of data generically characterized in a standard
category, and precisely defined by a simple citation
Like, maybe, nroff or TeX sources, as cited by RFC 1049?
3. Data are being sent according to a cited encoding standard.
Like, maybe, "some kind of data" encoded in hex?
The line betwee #1 and #2 is totally fuzzy. #3 is clearly a different
concept, but doesn't stand alone -- you have to know what, precisely,
you have encoded. #1 and #2 are both the kinds of things that
Content-type, as defined by RFC 1049, was designed to handle. An
important point: THAT MECHANISM WORKS VERY WELL. There are lots of
different people using the Content-type header, and have been for
several years now, and the ONLY problems people have had with it, to my
knowledge, are the lack of a standard mechanism for multipart bodies and
the lack of a standard for your case #3, encoding data that can't be
passed in 7 bit mail bodies. These problems were, indisputably, the
motivation for the current effort. The basic notion of "Content-type"
is, however, not broken, so I don't think we should fix it.
It seems to me that we're solving enough issues in this RFC without
trying to change something that works fine as it is. I would strongly
urge us not to tamper with the basic notion of Content-type, which is
the direction I think I sense Dave heading. -- Nathaniel