I did it for part one, so there was no hope that I would refrain from
doing it for part two ....
1- Page 8
This RFC specifies the definition of the charset parameter for
the purposes of MIME to be the name of a character set, as
"character set" as defined in Section 4 of this document.
Should be: document MIME-IMB
2- Page 31
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the encapsulated headers embedded in the bodies
of messages of type "message."
Since this seems to forbid any modification in the headers of an
encapsulated message, should not one add something like: 'On the
other hand, gateways may need to encode non-US-ASCII text in the
headers of an encapsulated message by using the mechanisms
described in RFC MIME-HEADERS.'
3- Page 32
No encoding other than "7bit", "8bit", or "binary" is
permitted for parts of type "message/rfc822". The message
Should be 'bodies' instead of 'parts' (a body of type 'message'
may happen in an message, not only in a body part).
4- 7.2.2. Partial Subtype
It would be a boon for the lisibility to use term 'piece' or 'segment'
or 'fragment' instead of 'part' in this section. 'Part' is already
heavily overloaded in this document. Indeed, when the fragments have
been reassembled, the resulting entity may contain multiple parts.
Also, the terms 'message' and 'entity' are not used consistently in that
section. I am submitting a proposal for a set of corrections to this
section at the end of this message.
5- Page 35
In this example:
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
id="ABC(_at_)host(_dot_)com"; number=2; total=2
... second half of encoded audio data goes here ...
I would put *two* blank lines before '... second half of etc...'. There
is a header there, it just happens to be empty, and so a blank line is
needed to signal its end.
Proposal for corrections to section 7.2.2
7.2.2. Partial Subtype
The "partial" subtype is defined to allow large entities to be
delivered as several separate pieces of mail and automatically
reassembled by a receiving user agent. (The concept is
similar to IP fragmentation and reassembly in the basic
Internet Protocols.) This mechanism can be used when
intermediate transport agents limit the size of individual
messages that can be sent. The media type "message/partial"
thus indicates that the body contains a fragment of a larger
Three parameters must be specified in the Content-Type field
of type message/partial: The first, "id", is a unique
identifier, as close to a world-unique identifier as possible,
to be used to match the parts together. (In general, the
identifier is essentially a message-id; if placed in double
quotes, it can be ANY message-id, in accordance with the BNF
for "parameter" given earlier in this specification.) The
second, "number", an integer, is the part number, which
indicates where this part fits into the sequence of fragments.
The third, "total", another integer, is the total number of
parts. This third subfield is required on the final part, and
is optional (though encouraged) on the earlier parts. Note
also that these parameters may be given in any order.
Thus, part 2 of a 3-part message may have either of the
^fragment ^fragment ^entity
following header fields:
Content-Type: Message/Partial; number=2; total=3;
But part 3 MUST specify the total number of parts:
Content-Type: Message/Partial; number=3; total=3;
Note that part numbering begins with 1, not 0.
When the parts of a message broken up in this manner are put
together, the result is a complete MIME entity, which may have
its own Content-Type header field, and thus may contain any
other data type.
188.8.131.52. Message Fragmentation and Reassembly
The semantics of a reassembled partial message must be those
of the "inner" message, rather than of a message containing
the inner message. This makes it possible, for example, to
send a large audio message as several partial messages, and
still have it appear to the recipient as a simple audio
message rather than as an encapsulated message containing an
audio message. That is, the encapsulation of the message is
considered to be "transparent".
When generating and reassembling the parts of a
message/partial message, the headers of the encapsulated
message must be merged with the headers of the enclosing
entities. In this process the following rules must be
(1) All of the header fields from the initial enclosing
entity (part one), except those that start with
"Content-" and the specific header fields "Subject",
"Message-ID", "Encrypted", and "MIME-Version", must be
copied, in order, to the new message.
(2) The header fields in the enclosed message which start
with "Content-", plus the "Subject", "Message-ID",
"Encrypted", and "MIME-Version" fields, must be
appended, in order, to the header fields of the new
message. Any header fields in the enclosed message
which do not start with "Content-" (except for the
"Subject", "Message-ID", "Encrypted", and "MIME-
Version" fields) will be ignored and dropped.
(3) All of the header fields from the second and any
subsequent messages are discarded by the reassembly