[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIME Multiple body parts (Was Re: uid...)
"Shannon J. Clark" wrote:
> Just a thought along these lines:
> 1 - are we discussing a MULTIPART composed of iCalendar related objects?
> (some encrypted, some not perhaps?)
> 2 - are we discussing a MULTIPART composed of a text or text/html object +
> an iCalendar object?
> Also - if the iCalendar object has say an Attachment - are we considering
> allowing that ATTACHMENT to be bundled as part of the MULTIPART message,
> and/or for that ATTACHMENT to be encrypted in some manner?
We allow attachments (AKA body parts) because we allow CID's and MID's
as URL's in the vCalendar object. That means that one MIME message as
MULTIPART/RELATED can have N-number of body parts, one of which
is the vCalendar object (text/calendar).
A CID is a CONTENT-ID, and means that one URL in the text/calendar
body part refers to the contents of another body part in the same MIME
(note: I may not have correctly shown a CID or MID url, but
you'll get the idea).
A MID is a MESSAGE-ID to a MIME body part. That means that
a text/calendar body part can refer to any body part in any other
MIME message. Example:
Also, the WG agreed that MULTIPART/ALTERNATE was expected to
be allowed. (one part text/calendar, others any other representation
of the object text/plain, text/html, ...). Example:
MIME-header ... MULTIPART/ALTERNATE
<body-body-part-one ... text/calendar>
<body-body-part-two ... text/plain>
You have been invited to a party
Starts at: ....
Ends at: ...
This DOES NOT mean that a CUA or a CS MUST implement the code
to process these. It mean that we agreed not to limit ourselves
and allow CID/MID's.
NOTE: MULTIPART/<whatever> may be combined/mixed and contain
Again we are not mandating that a CUA or CS MUST do this, we
are simply not restricting them from using all of MIME.