> -----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
