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. > >The scary part is that demuxing based on C-T *does* work in a lot of simple cases, so it may be used widely. But it doesn't work in general. >To work generally, it will be necessary to first demux based on C-D. > >If we have a lot of implementations basing things on C-T, then they may not be inserting, or doing the necessary processing for C-D. That means they are likely to break in more complex cases going >forward.
We can still use C-D. >>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. > >If you chose a standard C-T for all info-packages, that constrains the syntax that it may contain. Yet each package is going to want to choose the syntax(es) that it uses. And some of them will want to >be standard ones, such as image/jpeg. To deal with that your "standard" info C-T would have to be a container for an arbitrary mime type. So you have simply pushed the problem down a level. The syntax can be very simple - for example package name plus a binary string which can contain whatever (the package defines the exact syntax within that binary string). It works a little like the SDP fmtp attribute. >>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. > >IMO its a really bad way to go. It's simple, and it does not require support of new parameter, content-ids etc. 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 > _______________________________________________ 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
