Re: 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