[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]





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?

Before I say more, I will first point out that discussion is irrelevant if we only intend to allow one info package per INFO.

But MIME bodies are extensible with arbitrary headers. I don't recall if there is any requirement about standardizing them.

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?

I'll revise your example a bit:

INFO sip:foo at bar.com
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:foo at bar.com
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip