Hi, >>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 I agree with Hadriel on this one :) Legacy has issues, and people who want to continue using legacy will have ways of dealing with that. The whole purpose of this work os not to make legacy better, but to define something which solves the issues with legacy - Info packages. Yes, our document is also supposed to cover legacy, but I don't think we should specify anything more than what is in the current RFC today. So, I think the question we shall focus on is: how do we identify that a body part contains an Info package? >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) Each package can define what C-D value to use, but based on the discussion I think that we will not use C-D to actually say "This body part contains an info package". 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
