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, 
> 
>>>>> So, just to make sure I understand: you are talking about 
>>>>> a case where the INFO does contain a multipart message body, 
>>>>> but only one of the mimes contains an actual info-package 
>>>>> (the other mime(s) contains something else)?
>>>>> pretty much. And to distinguish those, you need more than C-T.
>>>>> But I think as we have been discussing, if we only allow one info 
>>>>> package per INFO, then the Info-Package header belongs in the 
>>>>> message, not in the body part.
>>>  
>>>> I don't think that defining Info-Package as a mime header 
>>>> would even be within the scope of the SIP WG, would it?
>> Before I say more, I will first point out that discussion is 
>> irrelevant if we only intend to allow one info package per INFO.
> 
> I think it's irrelevant if we only intent to allow one MIME per INFO.

I think it is irrelevant if we only allow one info package per INFO, 
even if we allow multipart bodies where one of those is the info package.

> Because, IF you have multipart, and one of them contains the info
> package, the question is how to figure out which it is.

Yes, we then require a way to distinguish which part is the info 
package. Hopefully we can find a way better than using the Info-Package 
header in the body part to do that.

>> But MIME bodies are extensible with arbitrary headers. I don't recall
> if there is any requirement about standardizing them.
> 
> Well, if we could put the Info-Package header into the mime itself we
> obviously won't have a problem.

I'd rather not have to be searching all the body parts to that extent to 
figure it out. The advantage of C-D is that its already necessary to 
look at that to figure out the role of each body part.

>>> My assumption has been that the I-P header is in the SIP  message
> part, and that causes the problem: in the case of 
>>> multipart, how to associate the correct mime with the I-P header?
>> Lets not get off in the weeds discussing this until and 
>> unless we decide to support multiple info packages per INFO.
>>
>>> I still think making assumptions on C-D is very dangerous, considering
> the very little experience we have of the C-D 
>>> header in the first place.
>> Could you please spell out precisely what your concern is?
> 
> You have multipart.
> 
> One mime contains the info package.
> 
> One mime contains something else.
> 
> My concern is that, by looking at the C-D you will always be able to
> determine which mime contains the info package.
> 
> ...again, unless you specify a info specific C-D value.

Indeed, IMO there *must* be a C-D value that, *in INFO messages*, is 
used *only* for the info package body part.

My preference would be for a new value, say "package", "info", or 
"info-package". I think we *might* be able to define that "render" 
serves this purpose *for INFO messages*, but I would rather not do that 
because it is indeed asking from trouble and confusion.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>>> I'll revise your example a bit:
>>>>
>>>> INFO sip:[email protected]
>>>> To:...
>>>> From:...
>>>> Some-Header: CID:abcdefg
>>>> Info-Package: foo
>>>> Content-Type:multipart/mixed
>>>> Content-Length:...
>>>>
>>>> --boundary
>>>> Content-Type: application/foo-data
>>>> Content-Disposition: package;handling=required
>>>>
>>>> foo data
>>>> --boundary
>>>> Content-ID: abcdefg
>>>> Content-Type: application/some-header-data
>>>> Content-Disposition: by-reference;handling=optional
>>>>
>>>> some other (non-info package) data
>>>> --boundary--
>>>>
>>>> In the above I have used C-D of "package" to identify the 
>> part that 
>>>> contains the info package. That is yet to be determined, 
>> but I think 
>>>> it needs to be well defined, even if it is "render".
>>> Again, I don't think using C-D for the "association" is a good idea.
>>>  
>>>
>>>> A more straightforward case would be:
>>>>
>>>> INFO sip:[email protected]
>>>> To:...
>>>> From:...
>>>> Info-Package: foo
>>>> Content-Type: application/foo-data
>>>> Content-Disposition: package;handling=required Content-Length:10
>>>>
>>>> foo data
>>> ...assuming that we don't allow multipart in INFOs, yes.
>>>  
>>> Regards,
>>>  
>>> Christer
>>>  
>>> _______________________________________________
>>> 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
>>>
> _______________________________________________
> 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
> 
_______________________________________________
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