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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
