WIth the exception of the issues below, I agree with the editors'
position on the issues.
A. 1: Audio formats.
I support the "content=audio info+audio data" proposal. One can
implement either. However, the problem is when you go to store the
content. If the audio info is kept in the Content-Type: field, then you
can't just store the content, you also have to store the headers in
order to make sense of it. A loser. If the audio info is kept in the
content, then you can simply store the content to disk and nothing else!
A. 2: Checksums.
I require a concrete proposal on how to do this before I can agree to
its inclusion. That is, I want to see BNF, references to RFCs, an FTP
pointer to the code, etc.
A. 3: Non-ASCII Headers.
Do not include this in the current draft as they don't deal with message
content, and frankly that's all the current draft should aspire to.
A. 5: Modification of the encoding model to treat it as a pipe. In
particular, a mechanism for specifying compression should be added.
Forget it.
B. 2: Where do body parts start & end?
Fine. (though it does complicate the FSN that recognizes body parts a
fair bit.)
B. 4: Alphabet for boundary markers:
You need to include the space character as something that's OK (as long
as it isn't a trailing blank).
/mtr