Hi Adam,
this is the paragraph we are talking about (in Section 8):
The situation with 'multipart/related' is similar. Per [RFC2387], a
UA processing a 'multipart/related' body processes it as a compound
object ignoring the disposition types of the body parts within it.
However, UAs that do not understand 'multipart/related' will treat it
as 'multipart/mixed'. These UAs will not be able to process the body
as a compound object. Instead, they will process the body parts
according to their disposition type.
What you are asking for is not to ignore the disposition types of the
body parts within the multipart/related. If we go down that path, we
will need to describe how multipart/related will be different from
multipart/mixed. That is, we would need to clarify what we mean by
"processing the body as a compound object" if the body parts are still
processed per their respective disposition types, as if they were in a
multipart/mixed instead of in a multipart/related.
Following the "propose text" principle, could you please edit the
paragraph above so that we have a concrete proposal on how to describe
the processing of multipart/related bodies and how it would differ from
the processing of multipart/mixed bodies?
Thanks,
Gonzalo
Paul Kyzivat wrote:
OK Adam. I had the mis-impression that you were advocating the use of
multipart/related *instead* of multipart/mixed for those cases where the
sip message just happened to contain multiple parts.
The examples you cite seem to be cases where there really is a
relationship between the parts. So I have no problem with what you are
proposing there.
Regarding the issue under discussion here, of the applicability of
Content-Disposition to parts of a multipart/related, I'm going to
reserve judgment. We are currently using Content-Disposition differently
than it is used in mail, and some of the needs to satisfies still seem
to exist with multipart/related. But I just don't know enough about the
nuances of mime to sort out the other side of the argument.
Thanks,
Paul
Adam Roach wrote:
On 7/7/08 12:03 PM, Paul Kyzivat wrote:
Adam Roach wrote:
On 7/4/08 1:28 PM, Paul Kyzivat wrote:
Adam,
I have to admit that I still haven't grokked the distinction
between multipart/mixed and multipart/related.
From a data structures perspective, multipart/mixed is an unordered
set, while multipart/related is a tree. The difference is actually
pretty radical.
I just went and reviewed RFC2387 *again*. I think my problem with it
is that I don't know where it was *intended* to be used. It clearly
wasn't *intended* to be used with SIP.
Now that I look again in the context of this discussion, it seems,
IMO, to be *inappropriate* for many cases where we are likely to have
multiple body parts in a sip message.
Consider the case of an INVITE that has SDP and a body part
referenced by an Alert-Info header. These two are not related at all,
and neither is the "starting" body part. They are each independently
related to the sip message itself.
So, what uses do you have in mind for multipart/related? Without some
specific and tangible ones, it is hard to justify making sip-specific
interpretations of it in this general document.
RFC 4662.
In a closely related vein (the one that shows where
Content-Disposition may be necessary), see also
draft-roach-list-subscribe-bodies-00.
/a
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
