Hi, Most of the multipart cases I've seen have worked fine, because the Content-Type normally tells everything the receiver needs to know (e.g. SDP, ISUP, XML-whatever, etc).
I guess the potential problem is when you send things like image/jpeg etc. For info packages, I still don't understand why we can't specify a common content-type value. The body part contains an info package, so the content-typ is info something. That way we would solve the how-to-find-info-body-parts problem, and whatever common stuff then needs to be done for SIP can be done outside the work of info. Regards, Christer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: 3. joulukuuta 2008 0:42 > To: Dean Willis > Cc: SIP List > Subject: Re: [Sip] Multiple body-parts in one INFO > > > > > -----Original Message----- > > From: Dean Willis [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 02, 2008 4:07 PM > > > > > Seriously - you expect us to put in a Require header > option-tag when > > > multi-part mime is used, so it can fail against every SIP device > > > that is deployed on the planet?? > > > > If understanding how to decode the multipart MIME is > critical to the > > success of the request, then I expect the request to fail > if the UAS > > cannot decode it. Further, I want it to fail predictably in > a way that > > the request originator can understand, not in some cryptic > > application/version dependent way. > > > What you are suggesting is that to use multi-part MIME in > current SIP methods, we cannot rely on currently deployed > system behavior. So you're basically proposing we either: > 1) Never do multi-part MIME. > 2) Do a new SIP version. > > I'm ok with doing #1, but I don't think things are *that* bad > anyway. I think we can rely on systems to behave sanely > enough to do a backwards-compatible multi-part that should > work in most cases - for the cases it doesn't, I think it > will fail explicitly (with a failure response), and *then* > one can argue if you can re-send it without the other body > parts, or if you just fail the call hard. But at least by > then you've actually hit an error, and it's not ALL deployed > systems that will have the problem. > > Although I do wonder about how much of a Red Herring this > topic is - what exact use-cases do you guys have for > multi-part bodies in SUBSCRIBE, NOTIFY, PUBLISH, and INFO > that is not actually defined in a package for them? Or are > we in some theoretical La-La land? [no offense meant - I like > La-La land] > > -hadriel > _______________________________________________ > Sip mailing list https://www.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://www.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
