Hi, >Multiple packages breaks the easy, 95% case: what if I have only a single body part, and it is the Info Package payload?
We DO say that one must support multipart, don't we? So, even in the one-package-only case one needs a way to find that Info Package. How is that done, and why doesn't that work also for multiple info packages? That's all I need to know :) Regards, Christer On Nov 28, 2008, at 2:38 PM, Christer Holmberg wrote: > > 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 :) > > Regards, > > Christer _______________________________________________ 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
