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

["Elwell, John" <john.elwell at siemens.com>]

Also I don't think methods such as SUBSCRIBE, NOTIFY and PUBLISH allow
>1 event package, so why should INFO allow >1 Info package?

John

> -----Original Message-----
> From: Elwell, John 
> Sent: 03 December 2008 08:53
> To: 'Christer Holmberg'; Hadriel Kaplan; Eric Burger
> Cc: SIP List
> Subject: RE: [Sip] INFO Framework - one pakage per INFO
> 
>  
> 
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> > Behalf Of Christer Holmberg
> > Sent: 28 November 2008 19:38
> > To: Hadriel Kaplan; Eric Burger
> > Cc: SIP List
> > Subject: Re: [Sip] INFO Framework - one pakage per INFO
> > 
> > 
> > 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 :)
> [JRE] The answer is we didn't have a requirement for this. I 
> agree with Hadriel's a), b) and c).
> 
> John
> 
_______________________________________________
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