[Simple] Re: [Sipping] MESSAGE Exploders draft

[Miguel Garcia <[e-mail]>]

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.


> 
> 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).

> 
> 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.

Thanks,

     Miguel

> 
> 	Paul
> 
> 
> 
> Miguel Garcia wrote:
> 
>>Hi:
>>
>>I have just submitted a draft that discusses a exploder of MESSAGEs.
>>
>>While it appears in the repository, you can download them from:
>>
>>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt 
>>
>>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html 
>>
>>
>>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING 
>>(exploders), I am copying both mailing lists.
>>
>>Regards,
>>
>>     Miguel
> 
> 
> 
> 

-- 
Miguel A. Garcia           tel:[phone]
Nokia Research Center      Helsinki, Finland


_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple