This really scares me. I can see lots of circumstances in which this
might break. For example, the act of forwarding mail, of bouncing mail,
of creating a mail digest....
The conversion of BinHex to multipart/appledouble comes to mind as well.
All of these are going to at least embed
the original multipart inside a larger multipart, which will confuse the
numbering scheme, and there's nothing in the MIME spec that ensures that
the layers of multipart won't be "collapsed" at some point.
It happens all the time when gatewaying through PC LAN mail systems that only
support one top-level sequence of parts. This does tend to preserve the offset
of the multipart, assuming you don't count the multiparts themselves. However,
there are also cases where you end up having to expand one part into two, such
as when you want to preserve the nested headers on a message/rfc822 as it
passes into an environment without the concept of nested messages. (The concept
of nested messages is quite distinct from the concept of nested multiparts
in general.)
This will
break all references to a part by its relative ordering. I think we
have "Content-ID" for a very good reason in this case... -- Nathaniel
Another issue is when there are several parts that could be used to satisfy the
reference, such as in a multipart/alternative. MIME calls for the same
content-id to be used for all such parts for precisely this reason. This
mechanism effectively gives you a facility comparable to http's type selection
scheme.
Ned