Re: [Sip] Multiple body-parts in one INFO

["Christer Holmberg" <christer.holmberg at ericsson.com>]

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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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:dean.willis at softarmor.com]
> > 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 
> sip-implementors at cs.columbia.edu for questions on current sip 
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip