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" <christer.holmberg at ericsson.com>]

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.

Yes.

>But then that single C-T may be used with a range of C-D types???

Yes.

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

I am just wondering whether the C-D mechanism is 100% waterproof.

Or, are you proposing an info specific C-D type? "Info" for example?

Regards,

Christer
















 
> 	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