Hadriel Kaplan wrote:
-----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.
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
