Re: INFO Framework - one pakage per INFO

Again, this is why I said, "technically easy."

However, it mean more package work, which the *work group* (not me)  
said, "hard - please punt."

On Nov 28, 2008, at 4:43 PM, Christer Holmberg wrote:

>
> 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip