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:[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
_______________________________________________
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
