Hi, >>>Like 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 to disambiguate the >>>interpretation of the body >> >>If 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. Regards, Christer > > Regards, > > Jeroen > > > > Christer Holmberg wrote: > >> Hi, > >> > >> > >>>> So, just to make sure I understand: you are talking about a case > >>>> where the INFO does contain a multipart message body, > but only one > >>>> of the mimes contains an actual info-package (the other mime(s) > >>>> contains something else)? > >>>> > >>> pretty much. And to distinguish those, you need more than C-T. > >>> But I think as we have been discussing, if we only allow one info > >>> package per INFO, then the Info-Package header belongs in the > >>> message, not in the body part. > >>> > >> > >> I don't think that defining Info-Package as a mime header > would even > >> be within the scope of the SIP WG, would it? > >> > >> My assumption has been that the I-P header is in the SIP message > >> part, and that causes the problem: in the case of > multipart, how to > >> associate the correct mime with the I-P header? I still > think making > >> assumptions on C-D is very dangerous, considering the very little > >> experience we have of the C-D header in the first place. > >> > >> > >>> I'll revise your example a bit: > >>> > >>> INFO sip:[EMAIL PROTECTED] > >>> To:... > >>> From:... > >>> Some-Header: CID:abcdefg > >>> Info-Package: foo > >>> Content-Type:multipart/mixed > >>> Content-Length:... > >>> > >>> --boundary > >>> Content-Type: application/foo-data > >>> Content-Disposition: package;handling=required > >>> > >>> foo data > >>> --boundary > >>> Content-ID: abcdefg > >>> Content-Type: application/some-header-data > >>> Content-Disposition: by-reference;handling=optional > >>> > >>> some other (non-info package) data > >>> --boundary-- > >>> > >>> In the above I have used C-D of "package" to identify the > part that > >>> contains the info package. That is yet to be determined, > but I think > >>> it needs to be well defined, even if it is "render". > >>> > >> > >> Again, I don't think using C-D for the "association" is a > good idea. > >> > >> > >> > >>> A more straightforward case would be: > >>> > >>> INFO sip:[EMAIL PROTECTED] > >>> To:... > >>> From:... > >>> Info-Package: foo > >>> Content-Type: application/foo-data > >>> Content-Disposition: package;handling=required Content-Length:10 > >>> > >>> foo data > >>> > >> > >> ...assuming that we don't allow multipart in INFOs, yes. > >> > >> Regards, > >> > >> Christer > >> > >> _______________________________________________ > >> 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 > >> > >> > > > _______________________________________________ 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
