Hello, see further explanation below.
for some reason the initial mail was sent again, sorry about that. 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: 23. září 2008 6:46 To: Sedlacek Ivo Cc: 'ext Eric Burger'; 'SIP IETF' Subject: Re: [Sip] [sip] extensions of "handling" parameter of Content-Disposition header Sedlacek Ivo wrote: > > 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). > > Can you give a concrete example of what this means? > I'm still totally in the dark about what you are trying to do. There is a SIP based multiparty conference with a focus - every participant is connected using a SIP dialog to a central focus, which mixes/switches Media sent by the participants. One of the participants wants the focus to fetch e.g. a picture / an audio clip from an HTTP server / an RTSP server and play it to the conference participants using their media streams negotiated in SIP dialogs. Hope this makes this use case clearer. > > 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. > > I have no clue what it means for the focus to share the resource. As mentioned above - by "sharing the resource" I meant the focus is fetching the picture / audio clip from the HTTP server / the RTSP server and distribute it using the MSRP / MSRP media streams agreed in the SIP sessions to the participants. > > I'm going to reserve judgment about this topic until I have an idea what > you are trying to do. > > Thanks, > Paul > > > 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] <mailto:[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] <mailto:[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] <mailto:[EMAIL PROTECTED]>, > >> [EMAIL PROTECTED] <mailto:[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] <mailto:[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 > >> > This list is for NEW development of the core SIP Protocol > >> > Use [EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]> for questions on current sip > >> > Use [EMAIL PROTECTED] <mailto:[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] > >> <mailto:[EMAIL PROTECTED]> for questions on current sip > >> Use [EMAIL PROTECTED] <mailto:[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
