Some questions, which may imply a need for clarification in the document:
(1) Multipart prologues and epilogues (editorial)
In the Multipart common syntax section (7.2.1, page 27 of the
PostScript version) preambles and epilogues are briefly discussed in a
paragraph starting "There appears to be room" and the subsequent note.
Partially because the NOTE stands out as much as it does, there is an
apparent near-contradiction between the "NOTE", which says "not used"
and the paragraph, which says "generally should be left blank".
I would recommend that we change "not" in the note to the
"generally should not be" language of the paragraph (just inserting
"generally" would do it). and
That we add an additional note explicitly calling out the sorts of
places that we have found it advantageous to take advantage of the fact
that MIME-readers are expected to not look at preambles, e.g., the "if
you see this, you don't have a MIME reader" statements that have become
popular for Multipart/Alternative cases.
This combination would make the reasons why we say "generally left
blank" rather than making a strict prohibition clear, as well as making
it clear why MIME readers can safely ignore what is there.
(2) Multipart/digest and Message/rfc822 (possibly also editorial)
Multipart/digest points to Message/rfc822. Message/rfc822 says
"syntax of an RFC822 message" and little else. Now RFC822 requires the
presence of certain fields-- normally From/ To/ Date -- and, without
them, one doesn't have the [valid] "syntax of an RFC 822 message".
If we intend to enforce this restriction, the example in 7.2.4 is
wrong.
My vague recollection is that we explicitly discussed this the first
time around, and that our conclusion was that the Message/digest use of
encapsulated components did not require any RFC 822 fields other than
From and/or Subject (an application I've been studying involving using
this mechanism for a multi-topic newsletter suggests "or" would be more
appropriate). I don't remember whether we applied this relaxation to
"rfc822" messages in general.
Action proposed: Modify the definition of text/rfc822 to permit body
parts containing only one of "From", "Subject", or "Date".
Alternative 1: Modify the definition of text/digest to permit body
parts containing only one of "From", "Subject", or "Date" as an
exception to the normal text/rfc822 rules.
Alternative 3: Modify the definition to text/rfc822 to explicitly
point out that "the syntax of an RFC 822 message" implies that author,
time, and at least one destination field must be present and fix the
example in 7.2.4 (multipart/digest) to reflect that.
(3) Multipart/digest applications and the preamble. (questions about our
intent--requires clarification at most)
If one examines existing uses of RFC 934 for digests, one of the more
common forms is:
table of contents
---
item 1
---
item 2
etc.
If one had an adequately smart MIME reader, the TOC can be dispensed
with since the reader can scan the encapsulated Subject lines to
generate that information.
Question 1: Is that our intent? Am I the only one who thinks it
would be useful to say so in 7.2.4?
Now, if one *doesn't* have an adequately smart reader, one model is
that this situation is a little like the multipart/alternative case
mentioned above. It would seem to me to be consistent with our general
approach to encourage the use of of the preamble for TOCs that would be
surious in the presence of competent MIME readers, rather than either:
o forcing the TOC into the first body part of the digest or
o building (vertical space squeezed out to save space)
Content-type: multipart/mixed; boundary="TOC Body"
--TOC Body
TOC
--TOC Body
Content-type: multipart/digest; boundary="---- next message ----"
------ next message ----
item 1
etc.
Question 2: Is using the preamble that way consistent with our intent?
Does anyone else think it would be useful to mention it as part of the
clarifying note suggested under (1), above?
--john