Re: Multiple body-parts in one INFO

Hadriel Kaplan <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <E6C2E8958BA59A4FB960963D475F7AC313776E1DF4@mail>
> -----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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.