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 look
for 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
