Ned & Nathaniel,
What a wonderful list. It's always useful to have explicit lists and
detail, to give a solid target at which to shoot...
In particular, I like the effort to stay at the level of concept and function,
rather than minor nits with syntax.
First question is what is missing from the list?
While I believe that the current Type/subtype set of values can work,
I have some continuing discomfort with aspects of them. To some extent,
it feels a bit like a shopping list, rather than an organized framework.
(Not completely random, but not as tight as would be nice.) To the extent
that an extremely rigid and rigorous framework can be developed, it will
make it easier to decide how to make additions and to explain the
categories.
I have increasingly come to believe that there should be the absolute
minimum of defaults. Only if there is fundamental benefit to the
default should it be included. (At the least, please use this as the
starting framework and give ground only grudgingly.) The bytes saved
by not explicitly listing defaults simply are worth it. Defaults are
an opportunity for two systems to lose synch.
I now believe that Type should ALWAYS require a Subtype. It makes the
model cleaner and it shies away from defaults.
Getting more specific, I think that a Type of File should exist, separate
from Binary. I also suspect that External should be its own Type. It
fits into the theoretical framework of Application, since you have to run
a (file transfer) process, before using the data in the mail, but I think
that is stretching the model a bit. External has a very different feel,
to me, than any of the other content types.
Now for comments on what is already in your list:
A.2 Checksum: Sigh. This seems like it ought to be easy, but...
I see two different approaches to checksum. One is "link level" and the
other is "end to end". The link level one is part of Content-Encoding
and the end-to-end is Content-Type. That is, a Content-Encoding
checksum is created by whatever entity puts the content into its current
encoding and is based on the RESULT of the encoding. The one that is
used in Content-Type is computed by the content creator and is based upon
the ORIGINAL version of the content.
Both can be useful, but I think the major benefit is in end-to-end
checksums and want to STRONGLY suggest that it be placed on -Type, rather
than -Encoding.
I have an emotional bias towards puting the checksum value on the
header, rather than after the content, but that is a relatively minor
syntactic issue, compared with the basic point.
I also believe that checksums should not be optional, at least for any
of the content-types that are machine-oriented, such as audio, or binary.
A.3 Non-ASCII headers. Gee. I don't understand why an item about
RFC822 headers is being discussed in a document intended to specify
message body format... In other words, I strongly second Marshall's
observation that this otherwise very important topic has no business
in this, particular, document. Really.
B.4 Alphabet for boundaries. I suggest restricting the list of
graphics characters further, to eliminate any that are major special
characters in other systems, such as asterisk and question mark.
B.5 Regularizing the syntax. I applaud you on this, very, very strongly.
B.6 Character sets. Sounds like a good clean-up.
B.7 Text-plus. Hmmm. Sounds interesting. I had wondered whether
this was possible and still am not sure whether it is the right thing
to do, tho it certainly is a good goal. The issue, to me, is whether
Text-plus fits into the model differently than plain text. Since,
text-plus is intended for processing, in order to reach a 'final' form,
whereas plain text is complete and stable, one could argue that it is
better to keep them separate. On the other hand, the fewer -Types
the better.
B.8. Incomplete character sets. I strongly encourage eliminating anything
from the spec which is fuzzy, incomplete, mal-understood, or likely to
change out from under you soon. The document should attempt to be
a useful spec and reference for 10 years. The area of character
sets is, clearly, a mess at the international level and none of the
efforts of this working group have changed that. (ooops. I'll get off
the soap box, now.)
B.11 'binary' to 'file'
I think they are separate beasts. I do think that 'file' should exist.
---
Again, many, many thanks for producing your list.
Dave