[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] 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:pkyzivat at cisco.com]
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: 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
>>
>
_______________________________________________
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