Subject: [Sip] Draft slides for body (MIME) handling

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 18 Jul 2007 14:29:19 +0300

Folks,

here you have the slides I have put together for the body (MIME) 
handling presentation on Monday:

http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt

These slides relate to this draft:

http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt

The slides discuss all the open issues that have been brought up in the 
list in the last months.

Comments are welcome.

Thanks,

Gonzalo

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 10:39:23 -0400

Thanks for sending out in advance. Maybe we can get into the discussion 
of the slides now, before the meeting.

Regarding references to body parts:

IMO it is a *bad* idea to make the decision about processing of a body 
part "on its own" dependent on whether the node doing so has detected a 
reference to that body part or not.

For one thing, that requires a multi-pass parsing mechanism to check for 
references before deciding what processing to do on a particular part. 
For another, it requires that the recipient understand every reference. 
For instance, the sender may have included an extension header that 
contains a reference to a body part. If the extension isn't understood, 
then the body part should not be processed. But if the recipient doesn't 
understand the extension then it won't recognize the reference either, 
and so will attempt to process the body part as one without references.

The only good solution I see to this is to partition the 
Content-Disposition and/or Content-Type values whose processing is 
dependent on reference from those whose processing is not dependent on a 
reference. For instance, we could simply define a new 
Content-Disposition of "by-reference".

Then a normal sequence of processing would be to first process all the 
body parts according to their type and disposition alone. Any with 
disposition "by-reference" would be set aside. Then, when processing 
headers, if a header with a reference is encountered the appropriate 
processing could be applied to the set aside body part. References 
within other body parts would be a little more complex, but you get the 
idea.

This would not prevent reference to body parts with other dispositions. 
It just means that those body parts would also be processed according to 
their type and disposition, in addition to any processing they might get 
according to their reference. The "by-reference" disposition is just a 
defintion that gets no implicit processing.

An advantage of this approach is that by-reference body parts don't need 
to be parsed unless the reference is processed and the action required 
in processing the reference requires the node to parse the referenced 
body. (Interaction with handling=required in this case is TBD.) Even a 
multipart with disposition of by-reference might not need to be parsed.

Regarding Content-Disposition in multiparts:

While it seems "wrong" to me, I can live with using "render" as the 
normal disposition for multipart, *if* we can do a careful job of 
defining what "render" actually means for SIP. Used this way it clearly 
doesn't always mean to display the content to a user.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 12:59:56 +0300

Hi Paul,

> of the slides now, before the meeting.

yes, that was the intention.

> and so will attempt to process the body part as one without references.

yes, these two issues are described in the draft.

> within other body parts would be a little more complex, but you get the 

yes. When looking for references, one would need to process the header 
fields plus the body parts with a disposition type different than 
'by-reference', since, as you point out, those body parts could contain 
references to 'by-reference' body parts.

The only case we would not cover would be two (or more) 'by-reference' 
body parts referencing each other. But we can just say that this is 
forbidden (no extension does that at present).

> defintion that gets no implicit processing.

yes, the draft already talks about the possibility of having several 
references to a body part. In such a case, the body part would need to 
be processed several times (in different ways). However, the case you 
are talking about is not currently addresses (i.e., a body part is 
processed once based on a reference and another time based on its 
content disposition). None of these situations occur within current 
extensions, but they could happen in the future.

> multipart with disposition of by-reference might not need to be parsed.

The interaction with handling=required would be that if you are not able 
to find a reference to a 'by-reference' body part with 
handling=required, you report an error because you have not been able to 
process the body part.

This approach would work and has the advantage to be explicit about how 
a body part is expected to be processed... I would like to hear more 
opinions on this.

Cheers,

Gonzalo

>> The slides discuss all the open issues that have been brought up in 
>> the list in the last months.
>>
>> Comments are welcome.
>>
>> Thanks,
>>
>> Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 13:10:40 +0300

Hi Paul,

> doesn't always mean to display the content to a user.

An entity receiving a 'multipart/mixed' body will process its body parts 
based on their disposition types.If the disposition type of a particular 
body part is not understood, it will be displayed to the user because 
the default disposition type is 'render'.

Therefore, the 'multipart/mixed' body will never be processed based on 
its disposition type. This means that it does not make much sense to 
talk about its disposition type as a whole. However, we need to have one 
in order to be able to set its handling parameter. That's why we can 
either keep 'render' explaining that it is actually never used or define 
a new disposition type.

Since existing implementations will not understand our newly defined 
disposition type, they will treat it as 'render' anyway... but the 
resulting behavior would be the same. That's why it may make sense to 
keep using 'render'.

On the other hand, semantically, it would make more sense to define a 
new disposition type.

Also, if we decide to define the 'by-reference' disposition type (per a 
different email thread), it could be used here as well.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jul 2007 09:18:14 -0400

Gonzalo Camarillo wrote:
> Hi Paul,
> 
>> Thanks for sending out in advance. Maybe we can get into the 
>> discussion of the slides now, before the meeting.
> 
>> part "on its own" dependent on whether the node doing so has detected 
>> a reference to that body part or not.
>>
>> For one thing, that requires a multi-pass parsing mechanism to check 
>> for references before deciding what processing to do on a particular 
>> part. For another, it requires that the recipient understand every 
>> reference. For instance, the sender may have included an extension 
>> header that contains a reference to a body part. If the extension 
>> isn't understood, then the body part should not be processed. But if 
>> the recipient doesn't understand the extension then it won't recognize 
>> the reference either, and so will attempt to process the body part as 
>> one without references.
> 
>> dependent on reference from those whose processing is not dependent on 
>> a reference. For instance, we could simply define a new 
>> within other body parts would be a little more complex, but you get 
>> the idea.
> 

Right. That case makes no sense to construct.

>> This would not prevent reference to body parts with other 
>> dispositions. It just means that those body parts would also be 
>> processed according to their type and disposition, in addition to any 
>> processing they might get according to their reference. The 
>> "by-reference" disposition is just a defintion that gets no implicit 
>> processing.
> 

Yes. IMO it is important to get a consistent framework in place that 
covers whatever kinds of usage might come along. Without that people may 
invent processing algorithms that cover only the cases they happen to 
have encountered.

>> An advantage of this approach is that by-reference body parts don't 
>> need to be parsed unless the reference is processed and the action 
>> required in processing the reference requires the node to parse the 
>> referenced body. (Interaction with handling=required in this case is 
>> TBD.) Even a multipart with disposition of by-reference might not need 
>> to be parsed.
> 

Hmm. I guess that makes sense. It means that any time there is an 
optional header with a reference to a body part then the handling of 
that body part needs to be optional. But again I guess that makes good 
sense.

Some interesting questions arise when body parts are being processed by 
middleboxes. (Maybe we aren't supposed to talk about that here.) The 
whole issue of handling=required gets messy there. The middlebox isn't 
the intended recipient, so the handling parameter doesn't really apply 
to it. So presumably it processes whatever headers and body parts it 
likes. That is another motivation for making the decision about 
processing be explicit - so it can be selective.

> a body part is expected to be processed... I would like to hear more 

Me too. So far this has mostly been a dialog between the two of us.

(Dale? - I can usually count on you to have an opinion.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jul 2007 09:59:22 -0400

Gonzalo Camarillo wrote:
>> defining what "render" actually means for SIP. Used this way it 
>> clearly doesn't always mean to display the content to a user.
> 

There is a bigger problem with 'render' than just multipart.

We have many uses of body parts that never mention Content-Disposition 
at all. The related examples don't use it, and so they all get a default 
of 'render'. This is particularly the case with events. E.g.

- the notification for REFER contains type application/sipfrag.
   Its probably not intended to be "rendered" in any literal sense,
   though some conclusion about success or failure may be.

- usage of filter bodies in presence subscriptions (RFC 4660)
   doesn't have a specified disposition, so it implicitly uses render.
   Its hard for me to convince myself that what the presence server
   does with these can be described as rendering.

- In fact, the only place I can think of where 'render' is (implicitly)
   used in sip and has the appropriate connotation is in MESSAGE.

I think we just have to grandfather the use of 'refer' in SIP, and 
document that the usage in sip does not mean "render", but rather means 
that the usage must be determined by other context - specifically the 
type of message or response and the content type. IOW, 'render' in sip 
can be thought of as a peculiar spelling for 'by-context'. It might be 
helpful to give guidance for development of future specs about when 
'render' should be used vs defining a new disposition.

> its disposition type.

Based on my discussion above, I would consider this a case of the 
multipart being processed according to its context *because* its 
content-disposition is 'refer'. If it had some other content-disposition 
then that might mean that it should be processed specially. E.g. if a 
multipart/mixed had disposition 'by-reference' then that needs to be 
taken into account, and the processing of the multipart becomes 
conditional on the reference.

Also, there are only certain contexts in which multipart should be 
processed "normally". Consider a NOTIFY from a REFER, with a 
Content-Type of message/sipfrag, which happened to include a body as 
part of the fragment. (This is legal.) That body might contain a 
multipart/mixed, and that might contain other stuff. But I think the 
processing of all of that is dependent on processing of the sipfrag. For 
instance, if something inside that had handling=required, I don't think 
that means that processing of the NOTIFY fails because the recipient 
can't handle that.

> This means that it does not make much sense to 
> talk about its disposition type as a whole.

Counterexample above.

> However, we need to have one 

I can go either way on that. But because there is existing usage, and 
because 'render' semantics are already so messed up, I think it makes 
more sense to stick with 'render' and just clarify its meaning.

> resulting behavior would be the same. That's why it may make sense to 

Yup.

> different email thread), it could be used here as well.

It could be used when there is actually a reference to it. But it would 
not be an appropriate disposition to use when there is no reference to 
the multipart.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 20:41:46 +0300

Hi,

yes, I agree there is a bigger issue with 'render'. Even though this 
bigger issue does not directly relate to multipart, we can also tackle 
it in the same draft and clarify how 'render' is used and what it means.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>> An entity receiving a 'multipart/mixed' body will process its body 
>> parts based on their disposition types.If the disposition type of a 
>> particular body part is not understood, it will be displayed to the 
>> user because the default disposition type is 'render'.
> 
>> This means that it does not make much sense to talk about its 
>> disposition type as a whole.
> 
> Counterexample above.
> 
>> However, we need to have one in order to be able to set its handling 
>> parameter. That's why we can either keep 'render' explaining that it 
>> is actually never used or define a new disposition type.
> 
>> Also, if we decide to define the 'by-reference' disposition type (per 
>> a different email thread), it could be used here as well.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 20:53:22 +0300

Hi Paul,

> that body part needs to be optional. But again I guess that makes good

Not really. I create an extension that consists of a header field (which 
is optional as any other new header field) that points to a body of 
disposition type 'by-reference'. If I want to make sure that the UAS 
understands the extension, I set the body's handling parameter to required.

If the UAS does not understand the header field, it will not find any 
reference to the body. Therefore, it will not be able to process it and 
will return an error response.

Of course, this could also be done with an option-tag in a Require 
header field.

> to it.

Well, this is true (or we want to think it is true) in SIP. But this is 
what RFC 3459 has to say about optional body parts:

    An OPTIONAL body part is one the sender doesn't care whether the
    receiving system delivers it or not.  A content gateway can silently
    delete such body parts if the receiving system cannot deliver the
    part.

Maybe we should add some clarifying text in the draft before B2BUA 
implementers decide to remove all optional body parts they get their 
hands on :o)

>  So presumably it processes whatever headers and body parts it

yes, being explicit is always good.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jul 2007 14:14:42 -0400

> it in the same draft and clarify how 'render' is used and what it means.

Sounds good. Maybe its just a matter of changing the title of the draft 
to match the scope. Something like: 
draft-sipping-content-type-disp-clarification-nn.txt

	Paul

>> at all. The related examples don't use it, and so they all get a 
>> default of 'render'. This is particularly the case with events. E.g.
>>
>> document that the usage in sip does not mean "render", but rather 
>> means that the usage must be determined by other context - 
>> specifically the type of message or response and the content type. 
>> IOW, 'render' in sip can be thought of as a peculiar spelling for 
>> 'by-context'. It might be helpful to give guidance for development of 
>> future specs about when 'render' should be used vs defining a new 
>> disposition.
>>
>>> Therefore, the 'multipart/mixed' body will never be processed based 
>>> on its disposition type.
>>
>> content-disposition is 'refer'. If it had some other 
>> content-disposition then that might mean that it should be processed 
>> specially. E.g. if a multipart/mixed had disposition 'by-reference' 
>> then that needs to be taken into account, and the processing of the 
>> multipart becomes conditional on the reference.
>>
>> processing of all of that is dependent on processing of the sipfrag. 
>> For instance, if something inside that had handling=required, I don't 
>> think that means that processing of the NOTIFY fails because the 
>> recipient can't handle that.
>>
>> It could be used when there is actually a reference to it. But it 
>> would not be an appropriate disposition to use when there is no 
>> reference to the multipart.
>>
>>     Thanks,
>>     Paul
>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>>
>>>
>>>> Gonzalo Camarillo wrote:
>>>>> Folks,
>>>>>

---

From: Qian Sun <[email-masked]>
Date: Fri, 20 Jul 2007 18:04:04 +0800

Hi,

If we define a new Content Disposition type "advertisement" so that the operator or service provider may insert advertisement in the all kinds of message body. And we want the advertisement content 'render' to the users. Could we use multiple content dispositions ("advertisement" and 'render') for a single content part? Or only define a new Content Disposition Parameters "advertisement" instead?

This is a real requirement, OMA and GSM is developing the mobile advertisement spec. the current advertisement way in Email or Webpage is very "evil", it is difficult for the user's client to distinguish the real content from advertisement, sometimes this is very disgusting or confusing. A new Content Disposition type "advertisement" or something else could be helpful, the advertisement may be displayed in a place different from the content.

Cheers,
Qian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 2:15 AM
To: Gonzalo Camarillo
Cc: sip
Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling)

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 20 Jul 2007 05:45:13 -0500

Qian Sun wrote:
> If we define a new Content Disposition type "advertisement" so that
> the operator or service provider may insert advertisement in the all
> kinds of message body. And we want the advertisement content 'render'
> to the users. Could we use multiple content dispositions
> ("advertisement" and 'render') for a single content part? Or only
> define a new Content Disposition Parameters "advertisement" instead?

So is there a need to ever use "advertisement" in conjunction with 
something besides "render"?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jul 2007 07:56:47 -0400

> If we define a new Content Disposition type "advertisement" so that the operator or service provider may insert advertisement in the all kinds of message body. And we want the advertisement content…

I'm quite certain that there may be only one content disposition per 
body part, just as there can be only one content type per body part.

> This is a real requirement, OMA and GSM is developing the mobile advertisement spec. the current advertisement way in Email or Webpage is very "evil", it is difficult for the user's client to disti…

I don't think I want to think or talk about "advertisement".

	Paul

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Jul 2007 21:49:55 -0400

I would offer this is where we can "add value" to MIME for SIP usage.  Note
that I do not say, "deviate from MIME."  I would suggest we NOT try to
deviate from MIME in any respect.

On 7/19/07 9:59 AM, "Paul Kyzivat" <[email-masked]> wrote:
[snip] 
> 'render' should be used vs defining a new disposition.
[snip]

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Jul 2007 21:51:39 -0400

I respectfully disagree on this one.  Here we are not talking about
disposition, but about the context of the content.  In the case of
"advertisement", we are noting the context of the content.  It is up to the
application (user) to decide to display ads or block ads.  It is NOT up to
the sender.

On 7/20/07 6:04 AM, "Qian Sun" <[email-masked]> wrote:

> Hi,
> 
> If we define a new Content Disposition type "advertisement" so that the
> operator or service provider may insert advertisement in the all kinds of
> message body. And we want the advertisement content 'render' to the users.
> Could we use multiple content dispositions ("advertisement" and 'render') for
> a single content part? Or only define a new Content Disposition Parameters
> "advertisement" instead?
> 
> This is a real requirement, OMA and GSM is developing the mobile advertisement
> spec. the current advertisement way in Email or Webpage is very "evil", it is
> difficult for the user's client to distinguish the real content from
> advertisement, sometimes this is very disgusting or confusing. A new Content
> Disposition type "advertisement" or something else could be helpful, the
> advertisement may be displayed in a place different from the content.
> 
> Cheers,
> Qian
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Jul 2007 00:17:03 -0400

> deviate from MIME in any respect.

Oh MIME sage, your comment is inscrutable! :-)

I don't understand in this case where the line is between "adding value" 
and "deviating".

If we try to ascribe some common meaning to "render" then I believe sip 
is already violating it. If we have thus already "deviated" from MIME, 
which takes precedence: correcting the deviation, or backward compatibility.

My assumption is that backward compatibility is more important.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Sun, 22 Jul 2007 01:46:49 -0400

Well, we are only sort-of munging MIME.  The default is always RENDER.
However, *what* is a render is an exercise for the protocol to specify.
That is the wiggle room for SIP to say "render means by-context."

What we do not have the wiggle room for is to say the default
content-disposition is something other than RENDER.

On 7/22/07 12:17 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> Notice:  This email message, together with any attachments, may contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted  and/or
>> legally privileged, and is intended solely for the use of the individual or
>> entity named in this message. If you are not the intended recipient, and have
>> received this message in error, please immediately return this by email and
>> then delete it.
>> 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Jul 2007 11:28:22 -0400

> content-disposition is something other than RENDER.

Well, we have *already* said that the default Content-Disposition is 
something other than "render" for certain Content-Types. E.g. for C-T of 
application/sdp the default disposition is "session". There are other 
special cases for some other content types as well.

Is that really kosher for MIME, or did we already do something bad?

In any case, what I was suggesting is that we spend some effort defining 
what "render" means for SIP.

	Paul

---

From: Qian Sun <[email-masked]>
Date: Tue, 31 Jul 2007 09:36:24 +0800

Hi, Dean 

Sorry for late response. Do you mean "advertisement" content always is needed to 'render'? So a single content disposition "advertisement" is enough.

In addition, some content body (e.g. Geolocation or advertisement) may be inserted or modified by intermediary. Could we specify a common way for indicating the source of inserted content body? For example, define a new MIME header: Content-Insertedby. A B2BUA may insert a content body including AD like this:

Content-Type: text/plain
Content-Disposition: advertisement
Content-Insertedby: AD-Agent <sip: [email-masked]>

McDonald, i'm lovin' it!

Opinion?

Cheers,
Qian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 6:45 PM
To: Qian Sun
Cc: 'Paul Kyzivat'; 'Gonzalo Camarillo'; 'sip'
Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling)

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2007 22:29:57 -0400

I'd rather not institutionalize advertising in ietf standards.
BUT, if we can get an agreement that all advertisements, of any sort, 
MUST be labeled with the "advertisement" content-disposition.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Jul 2007 10:37:50 -0500

On Jul 30, 2007, at 8:36 PM, Qian Sun wrote:

> Hi, Dean
>
> Sorry for late response. Do you mean "advertisement" content always  
> is needed to 'render'? So a single content disposition  
> "advertisement" is enough.

Well, I'm wondering if advertisements have any other need than  
"render". If not, why not just use "render"?

If we define an "advertisement" content disposition, we might as well  
call it "ignore", in which case there's hardly any point in sending  
it to start with, right?

Although I must admit I'm intrigued by the prospect of getting  
advertisers to self-label stuff so that it can be discarded as  
efficiently as possible.

> In addition, some content body (e.g. Geolocation or advertisement)  
> may be inserted or modified by intermediary. Could we specify a  
> common way for indicating the source of inserted content body? For  
> example, define a new MIME header: Content-Insertedby. A B2BUA may  
> insert a content body including AD like this:
>
> Content-Type: text/plain

I'm sure there has been discussion of this in geopriv, but I don't  
recall the details. I suspect there have been concerns about  
mismatches between the "source" and the "information".

--
Dean