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

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



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.

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