Re: [Sip] WGLC for draft-ietf-sip-body-handling

[Gonzalo Camarillo <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip