I'm still not convinced on the "Codeset" issue -- it seems to me that
the set of cases where the content-type does not specify a character set
is very small, and can be handled, if necessary, by multiple
content-types, e.g. "troff-iso-10646".
I like the "822-message" and "audio" content-type ideas.
I think that a natural analogy to the 822-message you propose is a
"compressed-message" content-type, which contains a compressed
encapsulated message which may, using its own content-type, contain any
other content-type. If we take this approach, we can keep
content-encoding simple *and* avoid separate compression-related headers.
I'll let Ned comment on your X.400 body part question.
I am by no means wedded to preserving the hexadecimal content-encoding.
Indeed, since I've argued strongly for minimizing the number of
content-encodings, it would be hypocritical of me to advocate keeping
it. How do other people feel?
I think Vincent's distinction between transport-dependent and
data-dependent encodings is a very clarifying notion. I have always
thought of the Content-encoding as a transport-dependent encoding, and
that data-dependent encoding can be fully specified with the
content-type header. Do we yet have any evidence that this is not the
case? In the absence of a compelling argument, I'd prefer to avoid the
additional complication of a Content-conversion field.
As far as parallelism in multipart messages goes, I don't really see it
as "half a solution". Given that multipart messages can include
multipart messages, you can do some extremely powerful things with the
simple distinction between parallel and serial multipart messages.
Moreover, it is explicitly stated that implementations are free to
ignore the request for parallelism. Given this, it strikes me as
harmless, and potentially very useful.
Excerpts from internet.ietf-822: 23-Apr-91 Comments on Draft RFC Vincent
Lau(_at_)eng(_dot_)sun(_dot_)com (6094)
2. From the previous lengthy dicussions about "prefix" area, there were
some strong reasons that "prefix" and "postfix" areas should be
dropped.
They *were* dropped. Or am I misinterpreting your use of the terms?
I had actually written a version of the RFC that included the
Content-Label proposal, but then I got rid of it when I realized that
one could easily use the established Message-ID field for this purpose.
Is there any advantage to defining a Content-label rather than using
Message-ID in the encapsulated parts?
Most of your other comments strike me as non-controversial, and I'll
certainly try to work them into the next draft. Thanks! -- Nathaniel