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? > >Before I say more, I will first point out that discussion is >irrelevant if we only intend to allow one info package per INFO.
I think it's irrelevant if we only intent to allow one MIME per INFO. Because, IF you have multipart, and one of them contains the info package, the question is how to figure out which it is. >But MIME bodies are extensible with arbitrary headers. I don't recall if there is any requirement about standardizing them. Well, if we could put the Info-Package header into the mime itself we obviously won't have a problem. >>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? > >Lets not get off in the weeds discussing this until and >unless we decide to support multiple info packages per INFO. > >>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. > >Could you please spell out precisely what your concern is? You have multipart. One mime contains the info package. One mime contains something else. My concern is that, by looking at the C-D you will always be able to determine which mime contains the info package. ...again, unless you specify a info specific C-D value. Regards, Christer > > >> 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
