Christer Holmberg wrote:
Hi,
Like I wrote before: adding the INFO package as a parameter to
Content-Type solves all this. I don't think C-D is the right header,
because the "disposition" would depend on the semantics of
the event package. We simply need an additional qualifier to
disambiguate the
interpretation of the body
If you mentioned this before I missed it.
Its an interesting idea. But I don't think it is technicallyh
feasible.
AFAIK the parameters to a C-T must be defined as part of the
definition of the C-T. That wold mean that only
yet-to-be-defined C-Ts could be used for info packages.
That would be a reason to use a COMMON C-T type, and then a parameter
which identifies the info package.
Let's keep in mind that info packages have been NEGOTIATED. Ie I will
not send you a package unless you have indicated support for it.
Therefor, if I send you a picture, I don't think it matters if C-T is
image/jpeg, or application/info;info-package=jpeg-package.
...because, YOU know the semantics of the package. Also, since an info
package is not supposed to change the core SIP state, the stack itself
doesn't need to know the semantics of the body, does it?
The problem is if I send you ONLY image/jpeg - without any negotiation,
and semantics we both have agreed on. I don't know what you will do it.
I think THAT is the problem that Eric initially raised.
So you are suggesting that *all* info packages share a single C-T,
except for parameters to it. But then that single C-T may be used with a
range of C-D types???
This seems like it would be quite inconvenient for the use case here. If
there is to be an info package where I can send you a picture for some
purpose, then the info package must specify the precise format of the
picture (equivalent of C-T) because the C-T will be this fixed value.
There may be a bunch of different C-Ts that are useful for encoding my
picture, but I'll need a separate info package for each. And I'll need
to fudge my encoding/decoding logic to no longer work based on C-T in
this case.
IMO what I am suggesting is much simpler and more straightforward. A
single C-D type identifies which body part should be processed as the
"payload" of the INFO message. (In a way entirely analogous to the way
the C-D of "session" identifies the payload of INVITE.) The C-T of this
payload identifies how it is encoded, and the value from the
Info-Package header is used to demultiplex the payload across all the
possible ways that INFO can be used.
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
