Dave Crocker writes:
Puting in the count of parts doesn't seem necessary, since the
multipart syntax bounds the aggregation. Hence, the count is redundant
and therefore an opportunity for error.
Ok, that makes sense.
Same for the type parameter you suggest. It's redundant with the
information in the subordinate content-type.
Don't you get problems when decoding the multipart message then?
(I might be too "locked" with the functionality of Metamail)
Example:
multipart/header-set
text/plain
application/applefile
A have an external decoder for "application/applefile", but that
decoder also need the text/plain part of the message. I see
implementation problems here. Am I wrong? You suddenly have to
handle (in this case) the text/plain part of the message as
a "subpart" of application/applefile. How would one know if
it isn't application/applefile which is a "subpart" of
text/plain?
paf