Hi, - CID is too complex, and I think it will prevent some people from moving from legacy to info packages.
- "Render" as the c-d is probably not 100% waterproof, since other body types may also use it. - I DO still strongly support a new c-d for the package body, but it seems that others have issues with that. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 9:51 PM To: Christer Holmberg Cc: Hadriel Kaplan; Dean Willis; SIP List Subject: Re: [Sip] Multiple body-parts in one INFO Christer, I just think using a single C-T for all packages is a bad idea. Its quite likely that some packages will support multiple content types. Its also quite likely that some/many/most packages will want to use *existing* content-types. We already have a mechanism for negotiating support for content-types. We should exploit that, not discard it here. We already have several other ways to skin this cat: - use cid references and the by-reference c-d for the package body - define "render" as the c-d for the package body in an INFO - define a new c-d (e.g. "info-package") for the package body IMO *all* of those are preferable to bastardizing the C-T for the purpose. Thanks, Paul Christer Holmberg wrote: > 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
