Re: [Sip] Multiple body-parts in one INFO

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----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.  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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip