> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > 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. 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? :) -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
