RE: [Sip] Support for Multipart/MIME

["Francois Audet" <[e-mail]>]

I think we are on to something here. I believe that Paul Kyzivat and Dan
Wing have it
right.

What I'd like to see is something describing the following:

- How to use Multipart/mixed

  I think Paul Kyzivat and Dan had some good explanation in this thread
about it. 
  We should really make proper treatment of multipart/mixed as mandatory
as we can. 
  This means, being able to understand parse the nested MIME bodies that
you DO support.
  At a miminum, an implementation should be able to find in a
Multipart/mixed the SDP
  for example. We probably need also to write some recommnedation on
what happens if
  there is multiple SDPs in that multipart mixed.

  It's not pretty out there. I've seen implementations that don't even
send 415
  when receiving multipart/mixed: they just ignore the payload, and
believe
  it's an SDP-less INVITE. They then put an offer in the response, which
the
  real offerer believes is an answer. Then all hell breaks loose.

  Some of them do send 415, but without the supported payload type in an
Accept 
  header in 415.


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