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

[Paul Kyzivat <[e-mail]>]

Adam,

I have to admit that I still haven't grokked the distinction between 
multipart/mixed and multipart/related. I gather this discussion is 
specific to related, not mixed. So would the issues you raise not be of 
concern if we used mixed rather than related to carry the multiple parts?

	Thanks,
	Paul

Adam Roach wrote:
> On 07/04/2008 02:26 AM, Gonzalo Camarillo wrote:
>> the problem with redefining stuff that was already defined in email is 
>> that we may lose the ability to use it as originally defined. For 
>> example, if I want to send you a MESSAGE request with the html page in 
>> your example (which includes images), I would probably use 
>> multipart/related (as in the email in your example). If we redefine 
>> multipart/related, we may face problems because I may not be able to 
>> use it like that any longer.
> 
> I'm not proposing that we redefine it -- I'm proposing that we relax a 
> restriction that makes sense for email but not for SIP.
> 
>> In any case, do we have any existing extension that sends 
>> multipart/related in a different context than the one above?... 
>> because we may not need to use it in other contexts after all.
> 
> RFC 4662 does.
> 
> The need for clear Content-Disposition differentiation is highlighted by 
> the exchange Robert and I had a few days ago (subject line "Possible 
> semantic confusion w/ bodies in subscribes"); in particular, look at the 
> examples in 
> <http://www.ietf.org/internet-drafts/draft-roach-sip-list-subscribe-bodies-00.txt>. 
> If we can't put content dispositions on the individual parts of 
> multipart/related documents, the disambiguation of 
> application/resource-lists+xml bodies becomes tricky.
> 
> 
>> The real question is whether or not we need the ability to have 
>> extensions that use multipart/related where the content disposition of 
>> the multipart/related plus the content types of the body parts are not 
>> enough to understand how to process the extension.
> 
> I believe that the draft I cite above provides an existence proof of a 
> case in which that is necessary.
> 
>> The thing is that, when I talked with the apps folks (they reviewed 
>> the draft), they stressed the fact that they do not like it when we 
>> redefine stuff that they had previously defined because they expect it 
>> to work in a certain way when it actually works in a different way. 
>> The guideline we got was that, if we need to define something new, we 
>> should really do that instead of redefining an old mechanism. So, if 
>> we really have the requirement above, maybe it is better to define 
>> something new than to reuse multipart/related.
> 
> In practice, the thing that SIP has redefined here to be substantially 
> different from MIME isn't the use of multipart/related -- it's the use 
> of Content-Disposition. Because Content-Disposition really does mean 
> something quite different in SIP than it does in email, the 
> email-specific restrictions on it just don't make any sense here. If we 
> could go back and do it over, I would suggest that the proper thing to 
> do would be defining a new MIME header -- something like 
> "Content-Context" -- but that ship has sailed.
> 
> /a
> 
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>>
>> Adam Roach wrote:
>>> This document largely looks good to me. I have only one substantive 
>>> comment to make.
>>>
>>> Section 8 has the following text:
>>>
>>>>    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.
>>>
>>> This is, indeed, consistent with RFC 2387. However, RFC2387 is geared 
>>> towards content in email messages. The constraint, in that context, 
>>> makes a lot of sense -- it would be bizarre to, for example, have an 
>>> HTML page (disposition inline) with subservient images tagged as 
>>> attachments. In an email context, it makes sense to treat the whole 
>>> multipart/related document as monolithic.
>>>
>>> When we consider the kinds of things we're doing with 
>>> content-disposition in SIP lately, this logic falls apart. We're no 
>>> longer simply indicating whether something should be shown as part of 
>>> an email or saved as a local file; we're indicating fairly complex 
>>> semantics that help disambiguate uses of MIME types that might 
>>> otherwise be confused with each other -- see, for example, my message 
>>> a few hours ago talking about how we disambiguate ad-hoc list 
>>> subscriptions from XCAP diff subscriptions (which use the same MIME 
>>> type by default).
>>>
>>> In that context, the use of Content-Disposition on individual parts 
>>> of a multipart/related document makes a *huge* amount of sense. I 
>>> think the sip-body-handling document needs to take into consideration 
>>> the needs of the SIP protocol in this case, rather than reinforcing 
>>> restrictions from RFC 2387 that really only make sense for email.
>>>
>>> /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
> 
_______________________________________________
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