[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] [sip] extensions of "handling" parameter of Content-Disposition header




Sedlacek Ivo wrote:
> Just to be absolutely sure - do you mean that it is more appropriate to 
> create a new disposition-type of the Content-Disposition header (rather 
> than creating new "handling" parameter values)? Thanks.

Yes. We have already created several for use with SIP. While I don't 
think this is something we want a *lot* of, with enough justification it 
is reasonable to create another.

You should take a look at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-03.txt

	Thanks,
	Paul

> Kind regards
> 
> Ivo Sedlacek
> Siemens
> PSE CZ TMM MMA8
> phone: +420 5 3877 6532
> email: ivo.sedlacek.ext at nsn.com, ivo.sedlacek at siemens.com
> 
> Mailcode: tL3PbjBL
> 
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 19. září 2008 14:08
> To: Sedlacek Ivo
> Cc: sip at ietf.org
> Subject: Re: [Sip] [sip] extensions of "handling" parameter of 
> Content-Disposition header
> 
> I can't think why you would want to have added values for the handling
> parameter. IMO what you want to do would be better served by values of
> the Content-Disposition itself.
> 
>         Thanks,
>         Paul
> 
> Sedlacek Ivo wrote:
>  > Hello,
>  > 
>  > can anyone please give me an expert opinion on possible extensions of
>  > "handling" parameter defined in RFC3204/RFC3459?
>  > 
>  > Is it appropriate to extend and use the "handling" parameter of
>  > Content-Disposition header of a MIME body inserted in a SIP request to
>  > signal a particular action which the sender requests from the recipient?
>  > 
>  > For example - if the "handling" parameter contained value "XYZ", the SIP
>  > request recipient would do a special action ActionXYZ using the MIME
>  > body. If the MIME body was included in the SIP request without the
>  > "handling" parameter, the recipient would NOT do the special action XYZ
>  > and instead would just store or render the MIME body.
>  > 
>  > AFAIK, RFC3204 defines parameter "handling" of Content-Disposition
>  > header of a MIME body with two defined parameter values "required" and
>  > "optional" and allows for possible future extensions. RFC3204 also
>  > states "The handling parameter, handling-parm, describes how the UAS
>  > should react if it receives a message body whose content type or
>  > disposition type it does not understand". RFC3459 says "The protocol
>  > described here is identical in functionality to RFC 3204 with respect to
>  > SIP.".
>  > 
>  > Kind regards
>  > 
>  > *Ivo Sedlacek*
>  > Siemens
>  > PSE CZ TMM MMA8
>  > phone: +420 5 3877 6532 <tel:+420543106532>
>  > email: ivo.sedlacek.ext at nsn.com <mailto:ivo.sedlacek.ext at nsn.com>,
>  > ivo.sedlacek at siemens.com <mailto:ivo.sedlacek at siemens.com>
>  >
>  > Mailcode: tL3PbjBL
>  > 
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > _______________________________________________
>  > 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