Re: Multiple body-parts in one INFO

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