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

From: "Sedlacek Ivo" <[email-masked]>
Date: Fri, 19 Sep 2008 13:53:25 +0200

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-masked], [email-masked]

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2008 08:08:13 -0400

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:
> 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
> email: [email-masked] <mailto:[email-masked]>, 
> [email-masked] <mailto:[email-masked]>
> 
> Mailcode: tL3PbjBL
>  
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Sedlacek Ivo" <[email-masked]>
Date: Fri, 19 Sep 2008 14:16:14 +0200

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

Mailcode: tL3PbjBL

-----Original Message-----
From: ext Paul Kyzivat [ <mailto:[email-masked]>
mailto:[email-masked]]
Sent: 19. září 2008 14:08
To: Sedlacek Ivo
Cc: [email-masked]
Subject: Re: [Sip] [sip] extensions of "handling" parameter of
Content-Disposition header

        Thanks,
        Paul

Sedlacek Ivo wrote:
> email: [email-masked] < <mailto:[email-masked]>
mailto:[email-masked]>,
> [email-masked] < <mailto:[email-masked]>
mailto:[email-masked]>
> Sip mailing list   <https://www.ietf.org/mailman/listinfo/sip>
https://www.ietf.org/mailman/listinfo/sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2008 09:15:32 -0400

Sedlacek Ivo wrote:
> 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

> From: ext Paul Kyzivat [mailto:[email-masked]]

---

From: Eric Burger <[email-masked]>
Date: Fri, 19 Sep 2008 15:03:33 -0500

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

---

From: "Sedlacek Ivo" <[email-masked]>
Date: Mon, 22 Sep 2008 11:11:20 +0200

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

Mailcode: tL3PbjBL 

  _____  

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

;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.

Kind regards

Ivo Sedlacek
Siemens
PSE CZ TMM MMA8
phone: +420 5 3877 6532

Mailcode: tL3PbjBL

-----Original Message-----

        Thanks,
        Paul

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Sep 2008 12:22:42 -0400

Since it looks like there is absolutely no security mechanism in the  
proposal, I would offer it will not go far in the IETF.

Why not use XCON to manage the conference part?

--
- Eric

On Sep 22, 2008, at 5:11 AM, Sedlacek Ivo wrote:

> 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
> "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.
>
> 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.
>
>> 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

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 Sep 2008 22:26:54 -0500

> external server) to participants of a tightly coupled conference  

I've been pondering this. Let me see if I can restate your use case.

A number of users are participating in a bridged conference. There is  
a persistent SIP-initiated session between each UA and the conference  
bridge.

One user wishes to command the conference bridge to retrieve a media  
sample and play it into the conference.

This "paying" operation does not change the session description for  
any of the existing sessions; rather it results in the delivery of  
specific media on the existing sessions to the end users.

One might envision any sort of control interface to the bridge. It  
might, for example, have a web-service interface. It might have an  
RTSP interface. One of the tricky bits of such an interface is  
correlating the SIP session that is to "hear" the media with the  
command protocol. For example, how in RTSP does one say "Play this  
media file onto the conference with  Alice, Bob, and Charlie, but not  
any other conferences".

But if the command interface is coaxial with a SIP dialog that  
supports a session, then we don;t have this correlation problem.

Something like an INFO package that has the semantic "Play the media  
reference by this INFO onto the session containing the INFO" might be  
appropriate. This is something like "render-to-this-session", as  
opposed to "render-to-the-user".

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Sep 2008 00:45:33 -0400

> 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.

> 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.
>  
> 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.

I'm going to reserve judgment about this topic until I have an idea what 
you are trying to do.

	Thanks,
	Paul

> message/external-body WITHOUT the "handling" parameter of 
> Other considered method is to initiate sharing of the resource 
> using 5.2. Adding Participants of RFC4353 - the participating client 
> 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
> *From:* ext Eric Burger [mailto:[email-masked]]
> *Sent:* 19. září 2008 22:04
> *To:* Sedlacek Ivo
> *Cc:* SIP IETF
> *Subject:* Re: [Sip] [sip] extensions of "handling" parameter of 
> 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. 
> 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.
> 
>> Cc: [email-masked] <mailto:[email-masked]>
>> > email: [email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked]>,
>> <mailto:[email-masked]>
>> >
>> > Mailcode: tL3PbjBL
>> > 
>> >
>> >
>> > Use [email-masked] 
>> <mailto:[email-masked]> for questions on current sip
>> > Use [email-masked] <mailto:[email-masked]> for new developments 
>> on the application of sip
>> Use [email-masked] 
>> <mailto:[email-masked]> for questions on current sip
>> Use [email-masked] <mailto:[email-masked]> for new developments on 
>> the application of sip
> 
>

---

From: "Sedlacek Ivo" <[email-masked]>
Date: Tue, 23 Sep 2008 08:40:39 +0200

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

Mailcode: tL3PbjBL

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 23. září 2008 6:46
To: Sedlacek Ivo
Cc: 'ext Eric Burger'; 'SIP IETF'
Subject: Re: [Sip] [sip] extensions of "handling" parameter of

> 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.

> 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.

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Sep 2008 02:22:05 -0500

> Hope this makes this use case clearer.

So, absolutely no variation on INVITE or UPDATE is reasonable here.

Maybe some sort of new INFO package would work.

Or, a variation of the MEDICATRL approach (focus subscribes to media 
control events at UA, receives media control commands as NOTIFY).

Or, a completely non-SIP mechanism.

---

From: Eric Burger <[email-masked]>
Date: Tue, 23 Sep 2008 06:47:05 -0400

Smells like INFO to me.  Definitely needs authentication (which you  
don't have in MIME) and probably needs authorization (which you don't  
have in MIME).

The only thing that looks pretty firm: MIME isn't the way to go.

On Sep 22, 2008, at 11:26 PM, Dean Willis wrote:

> A number of users are participating in a bridged conference. There  
> is a persistent SIP-initiated session between each UA and the  
> conference bridge.
>
> media file onto the conference with  Alice, Bob, and Charlie, but  
> not any other conferences".
>
> reference by this INFO onto the session containing the INFO" might  
> be appropriate. This is something like "render-to-this-session", as

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 23 Sep 2008 09:34:23 -0500

As Eric already been questioned (I apologize if I missed the response), have you considered XCON/MEDIACTRL to provide this functionality? 

You might be able to piece together some things to get this to work, but it's not likely to inter-op with other implementations in terms of client manipulation of a conference - that's the idea behind XCON/MEDIACTRL -  to allow an authorized participant to have control the conference/focus. While the XCON FW might seem to be overkill, the protocol itself is fairly straightforward (in the works), thus you could implement the basics and get the functionality you're looking for. 

Regards,
Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sedlacek Ivo
Sent: Tuesday, September 23, 2008 1:41 AM
To: 'ext Paul Kyzivat'
Cc: 'SIP IETF'
Subject: Re: [Sip] [sip] extensions of "handling" parameter of Content-Disposition header

Hello,

Kind regards

Ivo Sedlacek
Siemens
PSE CZ TMM MMA8
phone: +420 5 3877 6532

Mailcode: tL3PbjBL

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]]
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:
> > external

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.

> > 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.
> 

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
> 
> >> 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
> >> 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?
> >> >
> >> > Content-Disposition header of a MIME body inserted in a SIP 
> >> > request
to
> >> > 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
> >> > 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
> >> > This list is for NEW development of the core SIP Protocol Use 
> >> > [email-masked]
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] 
> >> <mailto:[email-masked]> for questions on current 
> >> sip Use [email-masked] <mailto:[email-masked]> for new 
> >> developments on the application of sip
> >
> >
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 

This list is for NEW development of the core SIP Protocol Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Sep 2008 11:42:20 -0400

> distribute it using the MSRP / MSRP media streams agreed in the SIP sessions

This sounds like a desire to have the conference mixer do something 
special. As such, something around mediactl might be appropriate.

Or, it might be viewed as introducing another sort of participant into 
the conference. Perhaps this could be done by sending a REFER to the 
focus, with a URL for the resource in the Refer-To header.

	Thanks,
	Paul

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 24 Sep 2008 10:07:59 +0800

Hello all,

I want to make a supplement because I think the new-introduced participant in the use case is a SEND-ONLY participant (fetching ... to the participants),  how about the solution in this situation? 

To Eric:  the statement on the authentication in RFC4483 is as follow, is it enough?

   "For confidentiality, integrity, and authentication, this content
   indirection mechanism relies on the security mechanisms outlined in
   RFC 3261.  In particular, the usage of S/MIME as defined in section
   23 of RFC 3261 provides the necessary mechanism to ensure integrity,
   protection, and confidentiality of the indirect content URI and
   associated parameters.

   Securing the transfer of the indirect content is the responsibility
   of the underlying protocol used for this transfer.  If HTTP is used,
   applications implementing this content indirection method SHOULD
   support the HTTPS URI scheme for secure transfer of content and MUST
   support the upgrading of connections to TLS, by using starttls.  Note
   that a failure to complete HTTPS or starttls (for example, due to
   certificate or encryption mismatch) after having accepted the
   indirect content in the SIP request is not the same as rejecting the
   SIP request, and it may require additional user-user communication
   for correction.

   Note that this document does not advocate the use of transitive
   trust.  That is, just because the UAS receives a URI from a UAC that
   the UAS trusts, the UAS SHOULD NOT implicitly trust the object
   referred to by the URI without establishing its own trust
   relationship with the URI provider.

   Access control to the content referenced by the URI is not defined by
   this specification.  Access control mechanisms may be defined by the
   protocol for the scheme of the indirect content URI."

Thanks and Regards

Xiangsong

  ----- Original Message ----- 
  From: Paul Kyzivat 
  To: Sedlacek Ivo 
  Cc: 'SIP IETF' 
  Sent: Tuesday, September 23, 2008 11:42 PM
  Subject: Re: [Sip] [sip] extensions of "handling" parameter ofContent-Disposition header

  Thanks,
  Paul

---

From: Eric Burger <[email-masked]>
Date: Wed, 24 Sep 2008 20:09:48 -0400

Nope. S/MIME ensures the content was not adulterated in flight.  
However, it does not mean the requester is authorized to make the  
request.

Here is an example:

UAC alice issues an INVITE to UAS bob.
bob likes alice, so he accepts the INVITE
What bob doesn't like is having alice do weird stuff in a conference
bob doesn't know that alice is into weird stuff until he gets to this  
bizarre MIME disposition (note I use "disposition" here, because  
"handling" is clearly wrong for this purpose)

If bob rejects the INVITE because he doesn't like the MIME  
disposition, bob has no way to say why he rejects the INVITE. He can  
reject the MIME type, but that is draconian and does not let alice  
know her deficiency is wanting to do something weird. bob may very  
well accept the MIME type with a different MIME disposition.   
Likewise, he may be very happy to accept a normal INVITE.

On Sep 23, 2008, at 10:07 PM, Xiangsong Cui wrote:

> Hello all,
>
> I want to make a supplement because I think the new-introduced  
> participant in the use case is a SEND-ONLY participant (fetching ...  
> to the participants),  how about the solution in this situation?
>

---

From: "Sedlacek Ivo" <[email-masked]>
Date: Mon, 29 Sep 2008 08:25:53 +0200

I would like to thank everyone for the opinions. I will consider all of that
in future work.

Kind regards

Ivo Sedlacek
Siemens
PSE CZ TMM MMA8
phone: +420 5 3877 6532

Mailcode: tL3PbjBL

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 23. září 2008 17:42
To: Sedlacek Ivo
Cc: 'ext Eric Burger'; 'SIP IETF'
Subject: Re: [Sip] [sip] extensions of "handling" parameter of

	Thanks,
	Paul