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

[Adam Roach <[e-mail]>]

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