I am bothered by the comments shown below (with > prefixes).
It seems to me that multi-part adn multi-media parts are very
different beasts, whcih we should understand. We sho9uld avoid mixing
them to gether too much.
I don't see any point in trying to make out multi-part mechainsm into
ODA where I can mix all sortsof theings to gether in a single body
part.
What I want is to be able to carry an ODA body part when I need such a
thing, and to carry other body-parts when they suit my needs, but I do
not want to convert all of RFC822bis into a new form of ODA, or even a
partial form of ODA. A half baked RFC822oda is not of much value as I
see it.
Lets abandon trying to too far beyond hierarchical multi-part
structures. Best...\Stef
However, would it be reasonable to have inline parts as
part of multipart messages? You could use some flag to indicate that the
part should be positioned right after the previous EOL, not starting a
new line.
I suppose that if one wanted to do something with "content order" (I'm
not sure what happened with that thread) it would be quite natural to
attach this sort of thing to it, along with very precise language about
where the embedded part actually stopped and ended, possibly by adding
some special bracketing characters that would not be EOL sensitive.
E.g.,
a Content-order: 3,delimiter=/
Content-type: ASCII
/The ancient symbol /
Content-order: 4, delimiter=/
Content-type= GIF
Content-encoding: HEX
/010.../
Whether it is worth the trouble and complexity is another question.
Clearly a lot of overhead to put in a single "character".
john