Pruned. Comments inline. Christer Holmberg wrote:
Hi,(I've put all text about this into a single reply)
For example, envision a location-enabled image push: It sends an image/jpeg and a pidf/lo that are correlated.You need the Info-Package header to tell you what two bodies to lookfor and what they mean, and the MIME markup to know which is which. [Christer] If we assume that we are NOT going to allow multiple packages per INFO (nobody has objected to that restriction) we wouldn't have that problem.
Paul: =====Let's assume I want to send an INFO with package foo.The value of the Info-Package header is "foo", right? Now, what is the value of the Content-Type header?The package could support a number of content types: image/jpeg,text/plain, multipart/related, ...Anything that the definition of the package says is allowed. At least that is how I think Eric intended to to be.[Christer] I agree that a package could be associated with a number of content types. But, since the Info-Package header shows which package is included, I just wonder why we can't use a common C-T mime.
Just because there is only one package per info, there still could be *alternative* C-Ts for a given package. If you use one C-T for all INFOs then you can't do this. And its an abuse of the C-T, since then it won't describe the format of the content.
I do think there is something we haven't discussed: how do we figure out what part of the overall body is the part that carries the package? Normally this is no issue, since it is the entire body of the INFO message. But there are cases where it might not be. For instance if S/MIME is used, or if there is some header in the message the needs to reference a body part from a CID URI.
The answer to this goes back to Content-Disposition. The body part that contains the info package should have a unique C-D. That can be "render", or we could pick some other one.
Thanks, Paul _______________________________________________ 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