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: [EMAIL PROTECTED], [EMAIL PROTECTED]
> 
> Mailcode: tL3PbjBL
> 
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: 19. září 2008 14:08
> To: Sedlacek Ivo
> Cc: [email protected]
> 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: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>,
>  > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>  >
>  > Mailcode: tL3PbjBL
>  > 
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > _______________________________________________
>  > 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

Reply via email to