[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Multiple body-parts in one INFO
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