Re: [Sip] INFO Framework - one pakage per INFO

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

>Multiple packages breaks the easy, 95% case: what if I have only a
single body part, and it is the Info Package payload?

We DO say that one must support multipart, don't we? So, even in the
one-package-only case one needs a way to find that Info Package.

How is that done, and why doesn't that work also for multiple info
packages? That's all I need to know :)

Regards,

Christer



On Nov 28, 2008, at 2:38 PM, Christer Holmberg wrote:

>
> Hi,
>
>>> But, my question is still: what makes support of multiple packages
> un-simple? Based on the discussions we had on the list before the IETF

> meeting, I thought there were no problems.
>>
>> From a protocol perspective: you'd have to define that more than one
> package name can be indicated in an INFO,
>
> Sure. You allow a list of values in the Info-Package header.
>
>> that they have to use cid or some means to identify which body part 
>> is
> which package's,
>
> Based on the e-mail discussions with Paul, I thought each package was 
> going to have a unique Content-Disposition value. Has that changed?
>
> But, how is package identified in the case there is only one package, 
> but still multipart (which you DO say must be supported)?
>
>> and you'd have to handle the case when the receiver can process
> one/some package body parts but not another.  It's not truly "free" to

> add this.
>> It adds time and complexity to the draft.
>
> Isn't the generic handling of body parts described in the body- 
> handling spec?
>
>> For example, what if you received an INFO with two packages of the 
>> same
> package name?  Is that ok?  Which gets processed first?
>
> That's up to the application using the package to decide.
>
>> From a developer's perspective: you'd have to read a bigger RFC and
> grok more; and handle more execution paths or at least more logging 
> events/cases and possibly more configuration than your current INFO
>> code.
>>
>> From a product perspective: you'd have to test more scenarios in QA,
> train your support staff on more conditions, and document more logging

> event cases.
>>
>> Current INFO use doesn't support this capability, so why do we need 
>> to
> add it?
>
> AFAIK there is nothing which prevents you to from using multipart with

> INFO today, is it?
>
> Trust me, I want all this to be simple, but I also want to be able to 
> answer when someone asks be why it is not allowed :)
>
> Regards,
>
> Christer

_______________________________________________
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