[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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]
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.
You will have to look through "all" (not sure there will be too many...)
body parts anyway. Even if the info package happens to be in the "first"
body part you look at, you still need to look through the rest if there
are body parts with handling=required etc. That is normal multipart
handling.
>>>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.
IF we define a new C-D value, which is unique for info packages, I have
no problem with a C-D based solution.
But, it would still be more work to define info packages, because you
would need to specify which C-T value to use. Maybe not a big issue if
you can use an existing value, but it's more work if you have to define
a new value. For example, is there a standardized value which could be
used for DTMF? Has Cisco registerd the value they use in C-T when
sending DTMFs? :)
My issue is if we want to re-use an existing value, because I don't
think we for sure can say that couldn't be a case where more than one
body part has a "render" value (or whatever existing value we would
choose for info packages).
Regards,
Christer
>>>> I'll revise your example a bit:
>>>>
>>>> INFO sip:foo at bar.com
>>>> 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:foo at bar.com
>>>> 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
>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>> sipping at ietf.org 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
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org 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
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip