Christer Holmberg wrote:
Hi,disambiguate theLike I wrote before: adding the INFO package as a parameter to Content-Type solves all this. I don't think C-D is the right header, because the "disposition" would depend on the semantics of the event package. We simply need an additional qualifier tointerpretation of the bodyIf you mentioned this before I missed it.Its an interesting idea. But I don't think it is technicallyh feasible. AFAIK the parameters to a C-T must be defined as part of the definition of the C-T. That wold mean that only yet-to-be-defined C-Ts could be used for info packages.That would be a reason to use a COMMON C-T type, and then a parameter which identifies the info package. Let's keep in mind that info packages have been NEGOTIATED. Ie I will not send you a package unless you have indicated support for it. Therefor, if I send you a picture, I don't think it matters if C-T is image/jpeg, or application/info;info-package=jpeg-package. ...because, YOU know the semantics of the package. Also, since an info package is not supposed to change the core SIP state, the stack itself doesn't need to know the semantics of the body, does it? The problem is if I send you ONLY image/jpeg - without any negotiation, and semantics we both have agreed on. I don't know what you will do it. I think THAT is the problem that Eric initially raised.
So you are suggesting that *all* info packages share a single C-T, except for parameters to it. But then that single C-T may be used with a range of C-D types???
This seems like it would be quite inconvenient for the use case here. If there is to be an info package where I can send you a picture for some purpose, then the info package must specify the precise format of the picture (equivalent of C-T) because the C-T will be this fixed value. There may be a bunch of different C-Ts that are useful for encoding my picture, but I'll need a separate info package for each. And I'll need to fudge my encoding/decoding logic to no longer work based on C-T in this case.
IMO what I am suggesting is much simpler and more straightforward. A single C-D type identifies which body part should be processed as the "payload" of the INFO message. (In a way entirely analogous to the way the C-D of "session" identifies the payload of INVITE.) The C-T of this payload identifies how it is encoded, and the value from the Info-Package header is used to demultiplex the payload across all the possible ways that INFO can be used.
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