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
