Hello Eric,
 
thanks for your mail.
 
> What precisely is the use case behind your request?
 
The use case is to initiate sharing of a resource (stored at an external
server) to participants of a tightly coupled conference (RFC4353).
 
After the tightly coupled conference is established, a participating client
sends a SIP request containing a MIME body of MIME type
message/external-body (RFC2017) towards the focus. The "URL" parameter of
the Content-Type header of the MIME body contains URL of the resource to be
shared. The "handling" parameter with value "xyz" of the Content-Disposition
header of the MIME body indicates to the focus that this is not a regular
message/external-body but it is a request to initiate sharing of the
resource to participants.
 
When the focus receives a SIP request with the MIME body of MIME type
message/external-body with the "handling" parameter of Content-Dispotion
header set to "xyz", the focus will start sharing the resource indicated by
the URL of the MIME body of MIME type message/external-body.
 
If the focus received the SIP request with the MIME body of MIME type
message/external-body WITHOUT the "handling" parameter of Content-Dispotion
header set to "xyz", the focus would behave differently - e.g. initiate the
SIP requests towards the other participants and include there the MIME body.
 
Other considered method is to initiate sharing of the resource using 5.2.
Adding Participants of RFC4353 - the participating client indicates to the
focus to add the resource as added participant. The focus applies a special
policy when the focus detects the referred URI is not a user.
 
Kind regards
 
Ivo Sedlacek
Siemens
PSE CZ TMM MMA8
phone: +420 5 3877 6532 <tel:+420543106532> 
email: [EMAIL PROTECTED], [EMAIL PROTECTED]

Mailcode: tL3PbjBL 

 

  _____  

From: ext Eric Burger [mailto:[EMAIL PROTECTED] 
Sent: 19. září 2008 22:04
To: Sedlacek Ivo
Cc: SIP IETF
Subject: Re: [Sip] [sip] extensions of "handling" parameter of
Content-Disposition header


Absolutely.  Here is the deal: 

;handling is a parameter that tells the UAS that is MUST (or MAY) understand
the body part in its processing of the SIP message. "Understand" usually
means "can process" the body part, but that is an implementation issue.

Content-Disposition is a parameter that tells the UAS what to do with the
body part.

Now, looking at your question, Content-Disposition is probably not what you
want, either. You say, "to signal a particular action which the sender
requests from the recipient". That implies signaling. Content-Disposition is
not signaling. Content-Disposition is a hint to the UAS as to what it should
do with the body. If you want to signal an action at the UAS, then you more
likely want one of (new) INFO packages, PUBLISH/SUBSCRIBE, or a new SIP
header.

What precisely is the use case behind your request?


On Sep 19, 2008, at 7:16 AM, 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.

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]>
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]>
mailto:[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] < <mailto:[EMAIL PROTECTED]>
mailto:[EMAIL PROTECTED]>
>
> Mailcode: tL3PbjBL
> 
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sip mailing list   <https://www.ietf.org/mailman/listinfo/sip>
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


_______________________________________________
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