RE: [Sip] Support for Multipart/MIME

["Christer Holmberg \(JO/LMF\)" <[e-mail]>]

Hi, 
 
> - Multipart/alternative
> 
>   I agree with Dan that using Multipart/alternative in the 
> way that was
> described
>   in draft-jennings-sipping-multipart section 5 is in fact harmful.
> Especially now that we
>   are defining capability negotiation. Section 6 would be OK, but now
> that SDPng is gone,
>   it's irrelevant.
> 
>   What we really need to say is that multipart/alternative may be used
> only when we
>   are using alternative payload types for the same information. For
> example, text/html and 
>   text/xml or whatever. It would be applicable if one day we 
> re-created
> another SDPng 
>   for example.
> 
>   Section 3.1 explains this relatively well, but is 
> restricted to Offers
> (for which we have
>   no use cases anymore). I think it should instead talk about other
> examples (e.g.,
>   text/html, text/xml, or maybe some example with pictures).
> 
>   I really believe section 5 goes against the spririt of section 3.1
> (specifically, of
>   the quote of RFC 2046). What it really has it two 
> application/sdp (one
> of them is 
>   encrypted inside a application/pkcs7mime), but really it's still two
> application/sdp
> 
>   But we should make it clear that it is NOT for negotiating multiple
> alternatives of 
>   the same payload type, in particular, not for application/sdp &
> application/sdp.

In my example earlier it was not about negotiting multiple alternatives
of the same payload type.

But, anyway, if we want to forbid app/sdp & app/sdp we need good
technical justification for that, but my understanding is that Dan
indicated he would be able to provide that.

Regards,

Christer





   
> If we decide to go forward, I'd be happy to help too.
>  
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[e-mail]] 
> > Sent: Thursday, May 10, 2007 09:19
> > To: 'Christer Holmberg (JO/LMF)'; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [Sip] Support for Multipart/MIME
> > 
> > > >I have become convinced, through my efforts with RTPSEC, that 
> > > >multipart/alternative is harmful if it contains multiple 
> SDP parts.
> > > 
> > > Again, I am not in a position to disagree with you ,but is that 
> > > harmfulness documented somewhere?
> > 
> > Nope.  If we're going to move multipart/* forward in SIP, 
> > though, I'll be happy to write that section.
> > 
> > -d
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [e-mail] for questions on current sip 
> > Use [e-mail] for new developments on the application of sip
> > 
> 


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