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
