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