Subject: [Sip] MIME: Nested bodies with option-tag?

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 28 May 2007 09:16:30 +0200

Hi,

Gonzalo's draft describes a use-case where nested multipart bodies may
be used.

>From the implementation community we know that multipart is not widely
supported - which is the reason the draft was put together in the first
place.

And, when looking at the implementations that actually do support
multipart, I have one seen one or two that actually supports nested
bodies.

I wonder whether we should define an option-tag for the support of
nested bodies. Considering the limited support of non-nested multipart,
and the fact that it is still probably going to take a while before we
really needed nested multiparts (read: before we will have an
alternative to SDP), simply saying that entities MUST also support
nested multiparts may not have the real-life effect we wish (read:
people will not implement it no matter what the spec says), and we will
not get rid of the interop problems. 

I think it's a big step forward if we manage to get people to implement
support of non-nested multipart bodies...

Comments?

Regards,

Christer
_______________________________________________
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: Mon, 28 May 2007 11:34:31 -0400

If we have a significant body of implementations that support un-nested 
multipart, but that don't support nested multipart, then maybe such a 
tag would be useful. But first we should probably try to understand the 
situation and choose the best migration approach.

But I would hesitate to give *new* implementations the option to only 
support un-nested. If you are doing a new implementation you should 
implement nesting from the beginning.

	Paul

Christer Holmberg (JO/LMF) wrote:
> multipart, I have one seen one or two that actually supports nested bodies.
> 
> 
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Mon, 28 May 2007 15:58:23 -0400

From: "Christer Holmberg (JO/LMF)" <[email-masked]>

   nested bodies.

I don't think there's a lot to be gained from defining such an
option-tag.  The sender should already be aware that there is a risk
the recipient can't understand nested bodies, and have arranged for
suitable fallbacks.  Conversely, the recipient should (at least) be
able to skip the nested multipart body part in the proper "I don't
understand this body part" way.  All an option-tag would do is allow
the sender to not add a fallback.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 28 May 2007 22:22:21 +0200

Hi, 

>I don't think there's a lot to be gained from defining such 
>an option-tag.  The sender should already be aware that there 
>is a risk the recipient can't understand nested bodies, and 
>have arranged for suitable fallbacks.  Conversely, the 
>recipient should (at least) be able to skip the nested 
>multipart body part in the proper "I don't understand this 
>body part" way.  All an option-tag would do is allow the 
>sender to not add a fallback.

In that case we need some specific text saying that if the receiver does
not support nested multiparts it MUST do-this-and-do-that.

Because, as I said earlier, I don't think we will achieve what we want
by saying that one MUST be able to parse nested multiparts. It can be
rather tricky to implement (depending on how the parser is implemented,
though), and since there aren't really any use-cases out there yet I am
pretty sure some people will choose not to implement it (and saying that
people are not compliant in that case will not really help from an
interop perspective). So, because of that I think it would be good not
to mandate the support of nested multiparts, but to mandate appropriate
behavior if not supported - just like in any other case when a MIME body
contains an unsupported but required content type.

Regards,

Christer

> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 May 2007 17:05:01 -0400

More or less repeating what I said before:

I expect we do have to account in some way for implementations that have 
already been deployed, in absence of a clarifying document. Exactly how 
we deal with that is still TBD.

But as we define what is required to support this in the future, I think 
there is *no* benefit to defining two levels of support - full and 
partial. Anybody that sets out to provide support for this document 
should be expected to do it all - its not that much harder.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 09:08:28 +0200

Hi, 

>I expect we do have to account in some way for 
>implementations that have already been deployed, in absence 
>of a clarifying document. Exactly how we deal with that is still TBD.
> 
>But as we define what is required to support this in the 
>future, I think there is *no* benefit to defining two levels 
>of support - full and partial. Anybody that sets out to 
>provide support for this document should be expected to do it 
>all - its not that much harder.

I also think we should take into consideration what is already out
there, and not suddenly make all those implementations "wrong" just
because we are now adding lots of new MUSTs.

I am pretty sure that most implementations today supporting multipart
only support mixed, and non-nested bodies (maybe Robert has more correct
information based on his SIPit work).

So, when we think about nested bodies, non-mixed multiparts etc etc etc,
we really need to think whether it's a need for it in SIP in the first
place - at least without an option tag.

Because, again, making a huge document which mandates people to
implements lots of things, just because it can be done, will not help.
People will not implement it, unless they see any need for it.

Regards,

Christer

> > In that case we need some specific text saying that if the receiver 
> > does not support nested multiparts it MUST do-this-and-do-that.
> > 
> > rather tricky to implement (depending on how the parser is 
> > implemented, though), and since there aren't really any 
> use-cases out 
> > there yet I am pretty sure some people will choose not to 
> implement it 
> > (and saying that people are not compliant in that case will 
> not really 
> > help from an interop perspective). So, because of that I think it 
> > would be good not to mandate the support of nested 
> multiparts, but to 
> > mandate appropriate behavior if not supported - just like 
> in any other 
> > case when a MIME body contains an unsupported but required 
> content type.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 May 2007 16:05:48 +0300

Hi,

what I am hearing is that there are implementations out there that 
support multipart but not nested. Therefore, we need to decide two things:

1) do we want to have a MUST for multipart and a SHOULD for nested? I 
would say that we should have the same level (e.g., MUST, if we decided 
that MUST is appropriate) for both.

2) do we need a way for implementations that support multipart but not 
nested to be quickly updated to, at least, report that fact with an 
error response? This may make sense.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 May 2007 09:44:42 -0400

> that MUST is appropriate) for both.

I think if we don't do this, we will simply be creating another problem 
such as the problem we have today with multipart.

> error response? This may make sense.

This only makes sense if there is something that the sender can do about 
it. For instance today a 415 that indicates support for SDP but not for 
multipart tells a sender that used multipart with SDP and some optional 
parts to try again with just the SDP.

So the question is: is there anything that the sender could do in this 
case. We already have a SHOULD strength requirement to not do gratuitous 
nesting. If that had been followed then the nesting must not be 
gratuitous, so what is the fallback strategy.

Also, I think if we do a survey we are likely to find more restrictive 
limitations than just no nesting. For instance multipart may only work 
with certain contained body parts. I suspect it is a fools errand to 
attempt to describe the particular restrictions of a non-compliant 
implementation in the hopes that the sender will be able to craft an 
alternative form of request that is useful.

For inadequate implementations I think we must focus on the installed 
base that must be coped with. In that regard, specifying something that 
the existing implementation must do, that it doesn't already do, makes 
little sense.

	Paul

>> I expect we do have to account in some way for implementations that 
>> have already been deployed, in absence of a clarifying document. 
>> Exactly how we deal with that is still TBD.
>>
>> But as we define what is required to support this in the future, I 
>> think there is *no* benefit to defining two levels of support - full 
>> and partial. Anybody that sets out to provide support for this 
>> document should be expected to do it all - its not that much harder.
>>
>>     Paul
>>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 15:46:56 +0200

Hi,

My main concern is not what wording (SHALL, MUST, etc) we use.

The issue is that I think we need text saying what implementations that
DO NOT support alternative and/or nested shall do. If we say that they
shall reject the message I believe that many of the existing
implementations will be compliant with the spec.

And, if we give the possibility to simply reject the message, I believe
it will be easier to get people to change their implementations, if they
currently simply discard alternative and/or nested today.

Regards,

Christer

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 29. toukokuuta 2007 16:06
> To: Paul Kyzivat
> Cc: Christer Holmberg (JO/LMF); [email-masked]
> Subject: Re: [Sip] MIME: Nested bodies with option-tag?
> 
> Hi,
> 
> what I am hearing is that there are implementations out there 
> that support multipart but not nested. Therefore, we need to 
> decide two things:
> 
> 1) do we want to have a MUST for multipart and a SHOULD for 
> nested? I would say that we should have the same level (e.g., 
> MUST, if we decided that MUST is appropriate) for both.
> 
> 2) do we need a way for implementations that support 
> multipart but not nested to be quickly updated to, at least, 
> report that fact with an error response? This may make sense.
> 
> Cheers,
> 
> Gonzalo
> 
> Paul Kyzivat wrote:
> >> Because, as I said earlier, I don't think we will achieve what we 
> >> want by saying that one MUST be able to parse nested 
> multiparts. It 
> >> can be rather tricky to implement (depending on how the parser is 
> implement 
> >> it (and saying that people are not compliant in that case will not 
> >> really help from an interop perspective). So, because of 
> that I think 
> >> it would be good not to mandate the support of nested 
> multiparts, but 
> >> to mandate appropriate behavior if not supported - just 
> like in any 
> >> other case when a MIME body contains an unsupported but 
> required content type.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 15:51:15 +0200

Hi,
 
>For inadequate implementations I think we must focus on the 
>installed base that must be coped with. In that regard, 
>specifying something that the existing implementation must 
>do, that it doesn't already do, makes little sense.

I guess there are people who know this better than me, but I do believe
there are implementations which do reject nested bodies today.

I agree that we can't do anything regarding implementations which simply
discard anything they don't understand.

Regards,

Christer

> implementations that 
> >>>> option-tag.  The sender should already be aware that there is a 
> >>>> risk the recipient can't understand nested bodies, and have 
> >>>> arranged for suitable fallbacks.  Conversely, the 
> recipient should 
> >>>> (at least) be able to skip the nested multipart body part in the 
> >>>> proper "I don't understand this body part" way.  All an 
> option-tag 
> >>>> would do is allow the sender to not add a fallback.
> >>>
> >>> implemented, though), and since there aren't really any use-cases 
> >>> out there yet I am pretty sure some people will choose not to 
> >>> implement it (and saying that people are not compliant in 
> that case 
> >>> will not really help from an interop perspective). So, because of 
> >>> that I think it would be good not to mandate the support 
> of nested 
> >>> multiparts, but to mandate appropriate behavior if not 
> supported - 
> >>> just like in any other case when a MIME body contains an 
> unsupported but required content type.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 May 2007 10:01:17 -0400

> currently simply discard alternative and/or nested today.

I agree that simply ignoring a body can cause huge problems.

I believe we have addressed that by clarifying the use of 
Content-Disposition and its handling parameter. In the absence of 
handling=optional, the request must be rejected. This part must be of 
MUST strength. And the default of handling=required in the absence of a 
C-D header must also be of MUST strength.

But there is little we can do about existing implementations that don't 
do that right. I guess I can see writing up somewhere that even if you 
aren't going to make your implementation compliant to this full draft 
you should at least do make sure you support Content-Disposition. Would 
it be helpful in that regard to make that part a separate draft???

	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 30 May 2007 07:32:50 +0200

Once we get down to a decision of supporting nested versus not
supporting nesting, presumably we are then entirely in the realm of the
multipart coding itself.

Could I ask someone to elaborate on what generic requirements already
exist within multipart/mime in this respect, before we start looking at
defining SIP specific rules or indications?

Regards

Keith 

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Tuesday, May 29, 2007 2:47 PM
> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat
> Cc: [email-masked]
> Subject: RE: [Sip] MIME: Nested bodies with option-tag?
> 
> 
> Hi,
> 
> The issue is that I think we need text saying what 
> implementations that DO NOT support alternative and/or nested 
> shall do. If we say that they shall reject the message I 
> believe that many of the existing implementations will be 
> compliant with the spec.
> 
> And, if we give the possibility to simply reject the message, 
> I believe it will be easier to get people to change their 
> implementations, if they currently simply discard alternative 
> and/or nested today.
> 
> Regards,
> 
> Christer
>  
> 
> nested? I 
> > would say that we should have the same level (e.g., MUST, if we 
> > decided that MUST is appropriate) for both.
> > 
> multipart but not 
> future, I

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 30 May 2007 09:51:51 +0200

Hi Keith, 

>Once we get down to a decision of supporting nested versus 
>not supporting nesting, presumably we are then entirely in 
>the realm of the multipart coding itself.
> 
>Could I ask someone to elaborate on what generic requirements 
>already exist within multipart/mime in this respect, before 
>we start looking at defining SIP specific rules or indications?

I am very sure that I have seen text related to the support of nested
multiparts, and what nodes are expected to support, somewhere, but I yet
have not found it.

Regards,

Christer

> > The issue is that I think we need text saying what implementations 
> > that DO NOT support alternative and/or nested shall do. If 
> we say that 
> > they shall reject the message I believe that many of the existing 
> > And, if we give the possibility to simply reject the message, I 
> > believe it will be easier to get people to change their 
> > implementations, if they currently simply discard 
> alternative and/or 
> > nested today.
> > 
> > Regards,
> > 
> > Christer
> >  
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 30 May 2007 10:16:17 +0200

Hi, 

>>that DO NOT support alternative and/or nested shall do. If we say that

>>implementations, if they currently simply discard alternative and/or
nested today.
>Content-Disposition and its handling parameter. In the 
>absence of handling=optional, the request must be rejected. 
>This part must be of MUST strength. And the default of 
>handling=required in the absence of a C-D header must also be 
>of MUST strength.

I agree with that.

But, if there are implementations that don't even look at the C-D
headers, because they discard the whole message body because they don't
support multipart/alternative, that does not solve the problem. So, it
is important that implementations either treat alternative as mixed or,
as I suggest, reject the request. 

BTW, in the case of alternative, is the receiver required to support all
body types if they have handling=required? Or, is it enough if they
support at least one of the alternative body types?

>But there is little we can do about existing implementations 
>that don't do that right. I guess I can see writing up 
>somewhere that even if you aren't going to make your 
>implementation compliant to this full draft you should at 
>least do make sure you support Content-Disposition. Would it 
>be helpful in that regard to make that part a separate draft???

I absolutely agree that implementations MUST support C-D (including the
default value if C-D is not present).

Regards,

Christer

> >> 2) do we need a way for implementations that support multipart but 
> >> not nested to be quickly updated to, at least, report that 
> fact with 
> >> an error response? This may make sense.
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
> >> Paul Kyzivat wrote:

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 30 May 2007 10:44:21 +0200

Well, at the moment, what I am trying to do is get some understanding of
what we should scope as valid SIP work.

We need to be able to understand why something that is clearly a generic
problem for specification of nested MIME bodies merits a SIP specific
solution.

So:

-	is a generic solution already documented elsewhere?

-	if a generic solution is not documented elsewhere, should one be
documented, rather than a specific SIP solution?

Regards

Keith

> Sent: Wednesday, May 30, 2007 8:52 AM
> To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat
> Cc: [email-masked]
> I am very sure that I have seen text related to the support 
> of nested multiparts, and what nodes are expected to support, 
> somewhere, but I yet have not found it.
> 
> Regards,
> 
> Christer
> 
> 
> > 
> > Regards
> > 
> > Keith
> > 
> implementations 
> > > > support multipart but not nested. Therefore, we need to 
> decide two
> > > > things:
> > > >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2007 11:53:08 +0300

Hi,

what Keith says makes sense. I believe mandating support for multipart 
in SIP is a SIP-specific problem. Mandating suppport for 
multipart/alternative is also a SIP-specific problem, since a 
SIP-specific problem such as the transition to new session description 
formats depends on that.

However, specifying if an implementation that supports multipart should 
support nested body parts or not is something more general on which the 
email folks have a lot of experience.

Cheers,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 May 2007 12:35:35 -0700

> multiparts, and what nodes are expected to support, 

message/rfc822 [RFC2046], which is used when you forward a message,
routinely has nested multiparts when the message you're forwarding itself
had multiple parts.  It looks something like this:

  From: [email-masked]
  To: [email-masked]
  Content-Type: multipart/mixed; boundary=A
  
  --A
  Content-Type: text/plain
 
  here is that email I mentioned during lunch.

  --A
  Content-Type: message/rfc822

  From: Sammy Sammython <[email-masked]>
  Content-Type: multipart/mixed; boundary=B
  Subject: Pictures from our recent trip
  
  --B
  Content-Type: text/plain
  
  Here are the pictures from the island!  Enjoy!

  --B
  Content-Type: image/jpg
  Content-Transfer-Encoding: base64

  EKFEJKFIEUJKEJKEJFF ...

  --B
  Content-Type: image/jpg
  Content-Transfer-Encoding: base64

  EKFEJKFIEUJKEJKEJFF ...

  --B--
  --A--

-d

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 31 May 2007 22:51:52 +0200

Hi,

I don't object to your example, but wasn't message outside the scope of
the document (it only deals with multipart)? So, a "valid" example would
be a multipart containing another multipart.

In any case, the text I was thinking about was not an example, but more
generic text on what support is expected regarding nested body types.

Regards,

Christer 

> From: Dan Wing [mailto:[email-masked]] 
> Sent: 30. toukokuuta 2007 22:36
> To: Christer Holmberg (JO/LMF); 'DRAGE, Keith (Keith)'; 
> Gonzalo Camarillo (JO/LMF); 'Paul Kyzivat'
> Cc: [email-masked]
> > >supporting nesting, presumably we are then entirely in the 
> realm of 
> > >the multipart coding itself.
> > > 
> > >exist within multipart/mime in this respect, before we 
> start looking 
> > >at defining SIP specific rules or indications?
> > 
> message/rfc822 [RFC2046], which is used when you forward a 
> message, routinely has nested multiparts when the message 
> you're forwarding itself had multiple parts.  It looks 
> something like this:
> 
>   From: [email-masked]
>   To: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 May 2007 16:23:53 -0700

> I don't object to your example, but wasn't message outside 
> the scope of the document (it only deals with multipart)?  So, 
> a "valid" example would be a multipart containing another 
> multipart.

True.  But that occurs when you forward a message containing
two parts itself.

> generic text on what support is expected regarding nested body types.

I'm thinking MUST be supported; otherwise, we'll be back here in another 5
years trying to noodle over adding nested multipart support because we tried
to over-simplify things in 2007.

-d