RE: [Sip] Support for Multipart/MIME

["James M. Polk" <[e-mail]>]

At 01:19 PM 4/30/2007, Francois Audet wrote:
>I agree that we should make support for Multipart/MIME mandatory.
>
>I.e., that you must be able to decapsulate the parts and parse
>the ones you do support.

I agree with addressing Multipart now

A short requirements ID that becomes (no need for separate RFCs) a 
solutions doc will flesh all these individual details out (wrt which 
multipart needs to be supported (all?), and what to do with the 
Content-Disposition header values that may or may not also need to be 
accompanying such an extension in the message.



> > -----Original Message-----
> > From: Cullen Jennings [mailto:[e-mail]]
> > Sent: Sunday, April 29, 2007 22:05
> > To: IETF SIP List
> > Subject: [Sip] Support for Multipart/MIME
> >
> >
> > The extensibility model of SIP and SDP is very powerful in
> > most ways.
> > It is often done by adding a new thing and if both sides
> > understand it, they use it, and if they don't understand it,
> > they use the other data in the messages that they both do
> > understand and "fall back" to the old behavior. We can do
> > this for headers, URI, and other places in SIP. We can do if
> > for SDP attributes. However, there is one place were SIP is
> > very lacking in it's ability to be upgraded in the future.
> > This is around body extensibility.
> >
> > The typical way to deal with extensibility of bodies is using
> > MIME multipart. This allows a SIP message to cary more than
> > one body and the receiver to select and use whichever ones it
> > understands - This is all defined for sip except for one
> > problem. It was not mandatory to implement and as you can see
> > from the stats below, lots of UAs don't implement it.
> >
> > I believe that sooner or later we will have to do this - it's
> > pretty trivial to implement support for receiving multipart
> > even if SDP is the only thing your UA knows how to handle.
> > Now we could argue about if emergency calls were the thing
> > that absolutely required us to do this but my point is sooner
> > or later we are going to need to deal with this - it has come
> > up many times in the past.  I suspect it will only get more
> > difficult over time to make this change.
> >
> > I think the WG should consider an update to 3261 (likely done
> > through the process Keith has proposed) that makes this
> > multipart/MIME mandatory to implement.
> >
> > Cullen
> >
> >
> > On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:
> >
> > > I'd like to point out one thing about this:
> > >
> > >> This is how they answered for multipart/mime:
> > >>     2% I break if someone sends me multipart/mime
> > >>    24% I pretend multipart/mime doesn't exist if someone
> > sends it to
> > >> me
> > >>    24% I ignore multipart/mime but will proxy it or hand it to my
> > >> application if it shows up
> > >>    10% I try to do something useful with multipart/mime I receive,
> > >> but I never send it
> > >>     4% I ignore multipart/mime that I receive, but I try to do
> > >> something useful with multipart/mime I send
> > >>    24% I try to do something useful with multipart/mime I send and
> > >> receive
> > >>    12% Other
> > >
> > > Moving forward, SIP UAs and proxies will be required to support
> > > location-conveyance (currently draft-ietf-sip-location-
> > > conveyance-07) in
> > > order to support location for emergency calls (citizen to
> > authority,
> > > like
> > > 1-1-2 or
> > > 9-1-1).  -conveyance requires multipart support.
> > >
> > > The consequences of not supporting emergency call location will be
> > > serious.
> > > I believe it is likely that there will eventually be regulatory
> > > requirements to support emergency calls in some jurisdictions.
> > > Upgrades to several components of today's infrastructure will be
> > > needed before this all works, but stack vendors and UA developers
> > > should put multipart (and
> > > location-conveyance) on their development plans for next
> > year at the
> > > latest.
> > >
> > > Brian
> >
> >
> > _______________________________________________
> > 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


_______________________________________________
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