Re: draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]

Hi,
 
I don't understand why we should have to make an assumption that the C-D value will be different, and that it will always be possible to pick out the info package based on it. 
 
We don't know what info packages there will be, and we don't have a clear picture of other usages, so I think making such restrictive assumption is really bad. In that case I would rather prefer that we don't even allow multipart in INFO, which may also be another shooting in the feet thing...
 
I would still like to understand why the proposed usage of C-T by Jeroem and myself (eventhough I may not have made myself clear) wouldn't work:
 
example: Content-Type: application/foo-data;info-package=foo 
 
I don't think the C-T usage, as in the example above, fits into Eric's why-content-type-is-bad description.
 
image/jpge is BAD, I agree
 
image/jpeg; info-package=foo is not bad, in my opinion.
 
Of course, there may still be a need for C-D, per mime, but I don't think we should use C-D in order to figure out which mime is associated with the info package (unelss we have a C-D value of "info-package", that is).
 
Regards,
 
Christer

________________________________

From: Paul Kyzivat [mailto:[email protected]]
Sent: Sat 25/10/2008 01:28
To: Dean Willis
Cc: SIP IETF; Christer Holmberg
Subject: 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]





Dean Willis wrote:
>
> On Oct 24, 2008, at 5:04 PM, Paul Kyzivat wrote:
>
>>
>> Christer Holmberg wrote:
>>
>>> 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.
>>
>
> So the error condition is you have two body parts of types allowed for
> the INFO package, but only one of them is the "real" info, and the other
> part is from some other extension.
>
> If it hurts, don't do it?
>
> Seriously, a Content-Disposition would sort this out.

Yes. We need a C-D.

It can be "render" if we want it to be. But I think that brings some
baggage that we could do without. In particular, "render" is the default
C-D for any C-T that isn't defined to have some other C-D as its default.

I am really now thinking that the info package type is really a
"sub-disposition-type" - an extension to the disposition type namespace
that is independently managed. And then we provide the means to
negotiate use of those in INFO.

        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