Hadriel Kaplan wrote: > >> -----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?
By detecting the legacy code using a Require option-tag, and failing the call. Seriously. For a very reasonable definition of backward-compatible, that's a backward-compatible mechanism -- it behaves predictably in the presence of broken old crap. We can't fix the broken old crap. All we can do is detect its presence, and work within its limitations if required. -- Dean _______________________________________________ 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
