[Sipping] Managing multiple body parts

[Paul Kyzivat <[e-mail]>]

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


_______________________________________________
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