[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. 

I think it's irrelevant if we only intent to allow one MIME per INFO.
I think it is irrelevant if we only allow one info package per INFO, even if we allow multipart bodies where one of those is the info package. 


Because, IF you have multipart, and one of them contains the info
package, the question is how to figure out which it is.
Yes, we then require a way to distinguish which part is the info package. Hopefully we can find a way better than using the Info-Package header in the body part to do that. 


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.
I'd rather not have to be searching all the body parts to that extent to figure it out. The advantage of C-D is that its already necessary to look at that to figure out the role of each body part. 


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.
Indeed, IMO there *must* be a C-D value that, *in INFO messages*, is used *only* for the info package body part.
My preference would be for a new value, say "package", "info", or "info-package". I think we *might* be able to define that "render" serves this purpose *for INFO messages*, but I would rather not do that because it is indeed asking from trouble and confusion. 

	Thanks,
	Paul


Regards,

Christer

















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


_______________________________________________
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