--
Ruth Moulton ruth(_at_)muswell(_dot_)demon(_dot_)co(_dot_)uk
Consultant,
65 Tetherdown, London N10 1NH, UK. Tel: +44 181 883 5823
--------------
Hi - I don't know if these are the appropriate places to send this
query - but if someone could help, or point me to another source of
knowledge, I'd be gratefull....
I'm implementing a MIME/X.400 gateway (both '88 and '84), and have
been puzzeling over a paragraph in RFC1494, Section 5.2, para (6),
which says 'any header fields starting tiwh "Content-" in the
MIME boy part is placed in the optional other-header-fields structure'.
The paragraph points out that this can only occur 'when the MIME content-type
occurs as part of a "multipart" content-type' - quite rightly.
But what does it really mean -
If I have an multpart message of unknown subtype, then I would generate
a mime-body-part, which has the original content-type line information
in the parameters part. What goes in the body part ?
(a) the whole of the multipart body - i.e. all the parts plus
their rfc822 heading lines (if any) ? - and then are there
copies of any content_ lines in the parameters as well ?
(b) - no body part, but each of the multipart bodies goes in its
own body part according to it's particular type/subtype ? - and
in this case do their content_ lines (if any) also go in the parameters
of the first body part ?
I think the latter makes sense, but then why not have a multi-part type
of 'unknown' and use the multipart IPMS Heading Extension, as described
in RFC1495 3.2.2 instead ?
If I have a multipart message, of known subtype, then I would use the
heading extensions as in 1495 3.2.2, and put each message in it's own
x.400 body, (sorry that's each PART of the message, not each message),
and if one of these were of unknown type/subtype, then I would adopt the
mime-body-part solution just for that part.
Any ideas ?
ruth