Re: 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, 
> 
>>>> 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