[Top] [All Lists]

MIME draft, part 2, the nits.

1995-04-18 05:17:55
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:
  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.

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
^fragments                                           ^fragment
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;

  Content-Type: Message/Partial;

But part 3 MUST specify the total number of parts:
    ^fragment                               ^fragments

  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
         ^fragments ^entity
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.  Message Fragmentation and Reassembly

The semantics of a reassembled partial message must be those
of the "inner" message, rather than of a message containing
               ^entity                   ^entity
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
      ^entity                                     ^entity
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
       ^entity                                     ^entity
       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


<Prev in Thread] Current Thread [Next in Thread>