> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Monday, December 01, 2008 1:05 PM > > I suspect that the majority of the deployed code won't do anything good > with multipart, though I see from the SIPit reports that support is > getting there in things that are being brought to SIPit. (May not be the > majority of what is deployed.) > > [snip] > > All the code has to continue supporting legacy INFO. Even after almost > everybody has upgraded their code to support multipart, legacy INFO > usage will almost certainly continue. So there can then be cases where > legacy info use is combined with body parts used for other purposes. We > should be clear how that should work. And it must be defined in such a > way that interoperation with old implementations of INFO still works.
Since, as you said, legacy INFO (or legacy anything really) has basically undefined behavior for multiple body-parts, how can we reasonably define a mechanism that works for multiple body parts with legacy code? I think the answer is: don't change it. One way to not change it, as you've already pointed out in a previous email, is to simply say anything with a Content-Disposition of "render" is for the package, unless the package defines a specific Content-Disposition for itself. (as SIP-T/SIP-I does, for example) -hadriel _______________________________________________ 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
