Re: draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
Jeroen van Bemmel wrote: > Christer, > > 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. Whether C-D is suitable to identifhy the info package depends on whether it makes any sense to use C-D as an independent control over processing of the package, in addition to the definition of the package itself. I certainly haven't seen it that way. I would need a good use case to convince me that it is a useful thing to do. Thanks, Paul > > 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