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

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

We do allow multipart for legacy INFO (well, at least we don't disallow
it).

Do we need to say anything about the number of packages?

Regards,

Christer 



> -----Original Message-----
> From: Elwell, John [mailto:john.elwell at siemens.com] 
> Sent: 3. joulukuuta 2008 11:12
> To: Christer Holmberg; Hadriel Kaplan; Eric Burger
> Cc: SIP List
> Subject: RE: [Sip] INFO Framework - one pakage per INFO
> 
> 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