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
Fixed.
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.'
If the agent is *generating* the RFC822/MIME message to begin with there is no
ordering to preserve and it is required to encode any 8bit material in any
header it generates. If, on the other hand, an agent receives an RFC822/MIME
message containing 8bit material in a header, then the message is clearly
illegal in format and the agent is free to do with it as it pleases. Either way
this requirement doesn't apply so there is no issue to resolve. In fact by
making this statement you create an issue where none actually exists.
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).
Actually, it should be body part. Bodies refers only to the data, and that's
not where the encoding is specified.
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.
Agreed. I've changed most of them to fragment per your suggestions, but in some
places piece sounds better so I used it instead.
5- Page 35
In this example:
From: Bill(_at_)host(_dot_)com
To: joe(_at_)otherhost(_dot_)com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
MIME-Version: 1.0
Message-ID: <id2(_at_)host(_dot_)com>
Content-type: message/partial;
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.
Incorrect. There is no header here so there is no need for an additional
blank line, and it is misleading to suggest that one is present.
-----------------------------------------------------------------------
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
message.
^entity
Corrected.
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
^fragments
Changed.
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
^fragment
Changed.
indicates where this part fits into the sequence of fragments.
^fragment
Changed.
The third, "total", another integer, is the total number of
parts. This third subfield is required on the final part, and
^fragments ^fragment
is optional (though encouraged) on the earlier parts. Note
^fragments
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
Fragment is awkward here so I used "piece" instead. In this specific example
we're talking about a message, not an entity, so I've stuck with the more
specific term.
following header fields:
Content-Type: Message/Partial; number=2; total=3;
id="oc=jpbe0M2Yt4s(_at_)thumper(_dot_)bellcore(_dot_)com"
Content-Type: Message/Partial;
id="oc=jpbe0M2Yt4s(_at_)thumper(_dot_)bellcore(_dot_)com";
number=2
But part 3 MUST specify the total number of parts:
^fragment ^fragments
Again used "piece".
Content-Type: Message/Partial; number=3; total=3;
id="oc=jpbe0M2Yt4s(_at_)thumper(_dot_)bellcore(_dot_)com"
Note that part numbering begins with 1, not 0.
^fragment
Changed.
When the parts of a message broken up in this manner are put
^fragments ^entity
Changed.
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.
7.2.2.1. Message Fragmentation and Reassembly
These rules are specific to messages. As such, the change to the word
entity isn't appropriate in this section.
Thanks for the feedback.
Ned