[Sipping] Re: Managing multiple body parts

[Gonzalo Camarillo <[e-mail]>]

Hi Paul,

typically you either tag the body with a content disposition tag, or 
have a pointer somewhere in the message pointing to the body part... or 
both.

What sort of things do you have in mind, besides the ones I mentioned?

Thanks,

Gonzalo

Paul Kyzivat wrote:

> I changed the subject of this because it is generalized.
> 
> See below for details. The general question is:
> 
> Is there a need for some sort of draft (beyond what is already in 3261) 
> explaining how body parts are to be arranged and tagged so that they 
> will be found and processed in an interoperable way?
> 
> I think there is. I have spent time working on sip stack support for 
> managing body parts, and I came up with all kinds of questions about 
> what is valid and what is not.
> 
>     Paul
> 
> Miguel Garcia wrote:
> 
>> Hi Paul:
>>
>> Thanks for your comments. Answers inline.
>>
>> ext Paul Kyzivat wrote:
>>
>>> Miguel,
>>>
>>> In general the approach in the draft seems reasonable to me.
>>>
>>> I see one area of ambiguity, having to do with how multipart bodies 
>>> are handled. The draft says to remove the list and include everything 
>>> else. But even your example doesn't do that - it also removes the 
>>> multipart/mixed wrapper. Of course in this particular example that 
>>> makes perfect sense, but it goes beyond what the draft says to do.
>>
>>
>>
>> We start from the the fact that there will be as a minimum, two 
>> bodies, the list, and the actual payload. There might be more bodies, 
>> such as multiple payloads, S/MIME signatures, etc.
>>
>> I guess the algorithm should be:
>>
>> - If there is any kind of security body for the exploder (e.g., signed 
>> with the public key of the exploder), then remove that body.
>>
>> - Remove the list itself (in a typical use case, unless an extension 
>> says the oposite; I am referring to Ben's suggestion to allow it).
>>
>> - If there is only one body left, then remove the multipart/mixed 
>> wrapper.
>>
>> - Send the remaining stuff.
> 
> 
> This seems like the ad hoc approach. It will probably work in a lot of 
> cases. In the absence of more general rules this is probably a pragmatic 
> approach to take.
> 
> But I think there is a more general problem - not specific to message 
> exploders, or exploders, or message - that applies to management of body 
> parts in general.
> 
> Part of it is just:
> - in a hierarchy of mime entities, how do I identify the body parts that 
> interest me?
> 
> And the flip side of that is:
> - How do I arrange the body parts that I need to convey into a hierarchy 
> of mime entities so that the recipient will find and process them 
> correctly?
> 
> This is then further complicated by servers in the signaling path that 
> are permitted to mess with body parts. (That currently is only B2BUAs, 
> but with the m2m and m2e discussions it may eventually include proxies.) 
> For them there are the following additional questions:
> 
> - Should I (and if so how) modify the mime entity hierarchy to remove 
> body parts that I have processed?
> 
> - How should I modify the mime entity hierarchy to add additional body 
> parts that are to be processed further downstream, so that the recipient 
> will process them correctly?
> 
>>> There are more complex cases:
>>>
>>> - for security there could be signed body parts.
>>>
>>>    - The signature could be on the multipart containing the message
>>>      and list. It would have to be removed.
>>>
>>>    - The signature could be on just the message. Presumably
>>>      it should remain.
>>
>>
>>  >
>>
>> I agree.
>>
>>>
>>> - There could be other body parts referenced by cid: urls in
>>>    other headers in the message.
>>
>>
>>
>> Yes, they should remain.
>>
>>>
>>> I think there needs to be a more prescriptive way of defining what 
>>> gets passed on in the exploded messages. This is really just a 
>>> manifestation of a more general problem of how to decide how 
>>> different body parts should be processed. It potentially exists in a 
>>> normal, unexploded, MESSAGE.
>>>
>>> I think at least part of the answer lies with Content-Disposition. I 
>>> think there should be clarity about the content-disposition should be 
>>> for the body part(s) that MESSAGE interprets as message content. 
>>> Probably "render" (which is default for sip) would be an appropriate 
>>> content-disposition for message content.
>>
>>
>>
>> Agree so far. It may happen that some of this stuff is generic enough 
>> (not MESSAGE specific).
> 
> 
> Yes, very much so.
> 
>>> Also, I think there should be some clarity about what the 
>>> content-disposition should be for various kinds of multipart 
>>> containers when used in the various ways they may be used in sip. I'm 
>>> not quite sure what the answer is here.
>>>
>>> The list itself is of course referenced from a cid: url. It is the 
>>> url and its placement that determines how the corresponding body part 
>>> should be processed. For these, the content-disposition should be 
>>> some value that doesn't imply some other sort of processing. I think 
>>> it can't be any of "session", "render", "alert", or "icon". Maybe it 
>>> could be "attachment".
>>
>>
>>
>> I will be happy to have a very clear deterministic way to find out 
>> what to pass and what to keep to the other side of the exploder, base 
>> on presumabley the content-disposition. Let's see if I can come up 
>> with something.
> 
> 
> I'm interested in this. Do you think this is suitable as a new work 
> item? (Probably for sipping at first.)
> 
>     Paul

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland                   http://www.hut.fi/~gonzalo


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP