Subject: [Sipping] MESSAGE Exploders draft

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Apr 2004 10:32:56 +0300

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:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 02 Apr 2004 16:07:03 -0600

(Comments to self inline)

Ben Campbell wrote:
[...]
> Saying the exploder MUST NOT include the URI list in the outbound 
> messages seems a little severe. I can imagine applications where I want 
> the recipients to know the list. This could be useful for "reply to all" 
> sort of functions. But if we do allow this, we would need to give the 
> sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. 
> "bcc" thing.)

This sort of functionality seems to be required by REQ-GROUP-2 and 
REQ-GROUP-4 from the advanced IM reqs draft.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 02 Apr 2004 15:57:28 -0600

I like this approach overall.

A couple of comments and questions. Apologies if these have already been 
discussed.

Is it legal for the list parameter to point to something other than a 
body part? That is, can I have external lists?

Instead of saying that message exploders must always send message 
requests, we might consider saying the outbound request method must 
match the outbound method. This would allow for exploders that know how 
to explode more than one method.

When condidering DoS issues, it might be worth suggesting behavior if 
the exploder finds duplicate URIs on the list. For example, I could put 
the same URI in a bunch of times, and have a nice DoS amplifier.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Apr 2004 18:06:20 -0500

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.

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.

- There could be other body parts referenced by cid: urls in
   other headers in the message.

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.

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

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 20 Apr 2004 17:30:32 +0300

Ben:

Thanks for your comments. Sorry for my late answer. See my inline comments

> body part? That is, can I have external lists?

I believe this question lies in the field of the URI list draft 
(draft-camarillo-sipping-uri-list-02.txt). Section 8 of that draft has a 
discussion.

> sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. 

It seems reasonable to me. I think what we wanted to say is that the 
Request-URI of the outboud message SHOULD NOT contain a list parameter. 
The body need not carry the list, but may carry it for other purposes 
(such as the one you mentioned).

> to explode more than one method.

No, I don't agree. In the past we got an agreement that we will create 
a message-specific exploder draft. There is a draft that says how to 
deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft 
is about MESSAGE.  We don't want to go back and make the draft generic, 
to be applicable to any method. So I believe the wording is correct as 
it is now.

> the same URI in a bunch of times, and have a nice DoS amplifier.'

Good point. We will add a discussion on the subject.

Miguel.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Apr 2004 09:45:18 -0500

Miguel Garcia wrote:

[...]
>> match the outbound method. This would allow for exploders that know 
>> how to explode more than one method.
> 
> 
> No, I don't agree. In the past we got an agreement that we will create a 
> message-specific exploder draft. There is a draft that says how to deal 
> with INVITE, other for SUBSCRIBE, other for REFER, and this draft is 
> about MESSAGE.  We don't want to go back and make the draft generic, to 
> be applicable to any method. So I believe the wording is correct as it 
> is now.

My concern is, the text as written can be interpreted to mean that 
device cannot be both a MESSAGE exploder and an INVITE exploder, because 
exploding INVITE explicitly violates a normative requirement for MESSAGE 
exploders. I know that is not the intent, but I think it can be misread. 
Perhaps we simply need to say that exploding non-MESSAGE methods is out 
of scope for this document.

Thanks!

Ben.

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 20 Apr 2004 18:22:04 +0300

Hi Paul:

Thanks for your comments. Answers inline.

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

>    - The signature could be on just the message. Presumably

I agree.

>    other headers in the message.

Yes, they should remain.
> content-disposition for message content.

Agree so far. It may happen that some of this stuff is generic enough 
(not MESSAGE specific).

> any of "session", "render", "alert", or "icon". Maybe it could be 

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

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 20 Apr 2004 18:24:47 +0300

ext Ben Campbell wrote:
>> is about MESSAGE.  We don't want to go back and make the draft 
>> generic, to be applicable to any method. So I believe the wording is 
>> correct as it is now.
> 
> 

Ok, I understand your concern, and it sounds fine to me. We will specify 
that other messages are outside the scope of the document. Thanks.

    Miguel

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 21 Apr 2004 11:15:50 +0300

ext Miguel Garcia wrote:

[snip]

>> messages seems a little severe. I can imagine applications where I
>>  want the recipients to know the list. This could be useful for
>> "reply to all" sort of functions. But if we do allow this, we would
>> need to give the sender a way to choose, possibly on a per-URI
>> basis. (Sort of a "cc" vs. "bcc" thing.)
> 
> 
>  Request-URI of the outboud message SHOULD NOT contain a list
> parameter. The body need not carry the list, but may carry it for
> other purposes (such as the one you mentioned).

I agree.

One other thing, to convey such Cc information to the final recipients
of the explosion, message/cpim actually seems like a very good fit. It
already has the To, Cc headers defined, and the sender can populate them
as it sees fit and the exploder need not care. Including a URI in the
MESSAGE resource list, but omitting it from the To, CC in message/cpim
would result in exactly the Bcc-type behavior.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Apr 2004 17:02:02 -0400

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

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?

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

Yes, very much so.

>> 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.
>>
>> 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'm interested in this. Do you think this is suitable as a new work 
item? (Probably for sipping at first.)

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 22 Apr 2004 15:30:19 +0300

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:

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

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 10:53:05 -0400

> have a pointer somewhere in the message pointing to the body part... or 

Note that even if you don't explicitly tag a body with a content 
disposition it implicitly has one, because there is a defaulting rule.

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

Here are a few fuzzy issues:

- what content-disposition should a multipart/mixed body have?
   Should the recipient always look inside one for interesting
   content, regardless of the disposition?

- It is ok to nest body parts arbitrarily deep in nested
   multipart/mixed bodies? Or is there a cannonical way that
   body parts should be composed?

- What should happen, in an invite, to a body part with
   content-type of application/sdp but with a content-disposition
   of something other than "session"? (E.g. "render".)

- What should happen if an invite contains two body parts that
   both have content-type of application/sdp and content-disposition
   of session. (In a multipart/mixed, not multipart/alternative.)

- What content-disposition should be used for the content of
   a MESSAGE message? A NOTIFY message? A SUBSCRIBE message?

- What content-disposition should be used for multipart/signed
   and multipart/encrypted bodies? Should it match whatever it
   is that is signed or encrypted?

- What content-disposition should be used for body parts that
   are referenced via a cid: uri somewhere in the message?

- Does the fact that a body part is referenced by a cid: uri
   mean that it shouldn't also be processed as it would have been
   had it not been referenced by a cid: uri? What if the reference
   is from an extension header that the recipient doesn't understand?

- The content-disposition header has a handling parameter.
   An error should be generated if any parts with handling=required
   aren't able to be processed. In the context of sip, how is a
   determination made whether a part has been processed? Is it
   sufficient that it be understood even if it isn't acted upon?

I can probably come up with more, but that is a start.

	Paul