Hadriel Kaplan wrote:
-----Original Message----- From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Monday, December 01, 2008 9:18 AM Hadriel Kaplan wrote:So the next question was on multiple body-parts. Since INVITE, UPDATE,PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all carry bodies and not one of them defined a CID mechanism for the body part that was specific to their message method context, we shouldn't need to for INFO either. The problem is that none of them really considered the impact of multiple body parts, so it is anything but clear how an application is supposed to decipher one of these messages when it does contain multiple body parts. We are going to find that when combined with body parts for other purposes, implementations will do a variety of things. (That includes existing legal usages, such as body parts with C-D of "alert", which have been defined for a long time but never used.)There are two aspects to this:1) Legacy/deployed code. There's a crapload of it out there, doing what sub/not/publish/message/info/etc. said to do.
And doing what it *thought* it should do in cases where the specs didn't say.
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.)
That code is deployed - there is NOTHING we can define to change their behavior, because the code is what the code is. So as I said before, we can't go turn back the clock. Any piggy-backer that would create multiple body parts where none existed before has the responsibility to make itself work with that legacy code, not the other way around. That's not a problem we can fix. 2) New INFO code. I think we all agree that this draft must reference the body-handling draft as normative to support. The next question is if the draft needs to make any other specific normative requirements for handling of anything other than what the body-handling draft says. If it does, then I would assert such extra normative requirements are necessary for Subscribe/Notify/Message/etc. too, and thus deserve their own, separate draft that covers all of those message types, instead of one specific for INFO. A separate draft like, oh... body-handling? :)
For use with info-packages, we still have to define how the info package body part is identified by the recipient. Simply saying that it should be done the same way that old INFO, NOTIFY, and MESSAGE do it, when that hasn't been well defined, isn't a sufficient solution.
The bottom line is that we have *nothing* that says "this is how you identify the body part(s) that are supposed to be processed based on the definition of the type of message that contains them". Yet that is what we need here. (And what we should have had for MESSAGE and NOTIFY as well, among others.)
There is also what should be done for new implementations of legacy INFO, and to upgrade existing implementations of the legacy INFO.
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.
The mechanism used to identify the body part for legacy info *could* be entirely distinct from the mechanism used for identifying an info-package. But if a common mechanism works for both, that would be nice.
Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip