ietf-822
[Top] [All Lists]

Re: MIME message/partial

1995-02-22 10:18:55
In the current MIME spec. the following paragraph is included
discussing message/partial reassembly:

   (2) Only those header fields in the enclosed message which start
   with "Content-" and Message-ID", "Encrypted", and "MIME-Version"
   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 "Message-ID", "Encrypted", and
   "MIME-Version") will be ignored.

(on Page 40)

First of all, this isn't the current version of the text. Here's what the
current text says:

  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 observed:

  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.

  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.

  All of the header fields from the second and any subsequent messages are
  discarded by the reassembly process.

Why is this restriction made?

Because there are basically two sorts of headers: Those involved in the
desribing the message itself and those involved in describing the message
content. For the most part RFC822 defines the former sort; MIME exclusively
describes the latter sort.

When building a message/partial structure care must be taken to separate the
two sorts of headers. Headers describing the outermost message need to remain
at the outer level so that they can be processed by transports and gateways. (I
don't agree with all the things transport agents do to these headers, but that
doesn't change the fact that a lot of people depend on such processing,
especially in the gateway case.) 

Similarly, headers describing the inner content have to be removed from the
outer level since they no longer describe it and so headers that properly
describe the message/partial object can be added.

The specific restriction you're talking about applies because copying
non-content-related headers that were not visible to the transport and
gateways back into the outer level isn't a good idea.

Why should the other headers be
ignored and why does the "order" of the headers have to be
maintained??

Personally, I think the general ordering requirement here is stupid. What does
it mean to preserve the order of a subset of headers that are being injected
into another group of headers? However, at the time this was written there was
a strong feeling that header munging was Evil and should be minimized.

It *is* important to preserve the order of multiple occurrences of the same
header, of course. Yet the specification doesn't mention this at all. (There
are currently no content- headers where multiple occurrences make sense, but
this is guaranteed to change in the future.)

By the way, I don't bother to implement this fully -- I do preserve the order
of the copied headers but I weave them into the existing headers to get the
order I like rather than keeping them in a block somewhere. It isn't clear
whether this is "in order" or not according to the specification -- one reading
would be that it isn't.

I would have no problem replacing this requirement with one where the
ordering of multiple occurrences of the same header has to be preserved. The
handling of multiple occurrences should also be clarified.

Anyone else have any feelings about this?

                                Ned

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