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.
> -----Original Message----- > From: Cullen Jennings [mailto:[EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
