Subject: [Simple] Comments on MSRP - multiparty message session support

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 19:01:56 +0300

Hi All,

Since MSGFMT is no longer mandated (or is but only for CPIM gateways), 
how would a participant know where a message is coming from in a 
multiparty message session?

Also, when using MSRP in a conferencing system, the lack of To/From 
prevents sending private messages efficiently within a multiparty 
session using an MSRP mixer as a "router" for them.

So my question is this: what is the extensibility model for MSRP? For 
example, would it be possible to later on add this multiparty 
functionality as an extension, or would it be wise to think ahead 
already now?

The draft includes some extensibility, e.g., for authentication 
algorithms, but I didn't immediately find much about adding methods and 
headers, and what to do with unknown headers.

Regards,
Aki

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Fri, 17 Oct 2003 17:34:32 +0300

Hi,

I think Aki has a very important point here. I would say that one of the essential drivers for having messaging sessions in the first place is the ability to use them as "media" in the SIP conferencing framework (or in the centralized conferencing a la XCON). In these kind of "chats" it is obviously mandatory that the recipients sees who the originator is. (BTW, this is one of the SIP services that also 3GPP is working on.)

I see three ways forward:
1. Fix this in MSRP base spec (I see that many people woudn't want this anymore at this stage, but still...)
2. Define how MSRP can be extended and do this ASAP as the first extension
3. Use MSGFMT somehow to support this feature

My strong opinion is that MSRP should not allowed to proceed to IESG before there is some conclusion on this. At least to me MSRP without a simple way to support the conference scenario is worthless. There are already have plenty of solutions to send messages between two end-points and imitate a "session" (even SMS can do this), but SIP/MSRP solution's strenght should be really the multi-party case.

Markus 

> -----Original Message-----
> From: ext Aki Niemi [mailto:[email-masked]]
> Sent: 16 October, 2003 19:02
> To: [email-masked]
> Subject: [Simple] Comments on MSRP - multiparty message 
> session support
> 
> 
> Hi All,
>

---

From: [email-masked]
Date: Mon, 20 Oct 2003 13:37:14 +0300

> From: ext Ben Campbell [mailto:[email-masked]]
 > Sent: 17 October, 2003 20:36
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]
 > Subject: Re: [Simple] Comments on MSRP - multiparty message session
 > support
 > 
 > 
 > We talked about how this could be done in a couple of ways. 
 > One was by 
 > simply having the mixer remember the identity associated with each 
 > connection.

This would still not work, since there isn't a vehicle in the protocol to transport this "asserted-identity" to the recipient endpoints.
 
 > The mixer could also insist that all content be wrapped in 
 > message/cpim 
 > using our extension to the SDP format list negotiation.

Which is fine, if all MSRP endpoints are required to support it. Currently they aren't which potentially leaves a lot of MSRP clients incapable of participating in message session conferences.

Regards,
Aki

 > Aki Niemi wrote:

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:05:23 +0300

This is very much inline with Pekka's suggestion and I like it.

I vote for mandating message/cpim. Of course, we still need to signal what mime-types an endpoint supports, using SDP.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Ben Campbell
> Sent: Monday, October 20, 2003 4:31 PM
> [email-masked] wrote:
> 
> > 
> > This would still not work, since there isn't a vehicle in 
> the protocol to transport this "asserted-identity" to the 
> recipient endpoints.
> >  
> > Which is fine, if all MSRP endpoints are required to 
> support it. Currently they aren't which potentially leaves a 
> lot of MSRP clients incapable of participating in message 
> session conferences.
> 
> I am not opposed to requiring support for this. In 
> retrospect, I think 
> we intended to do that and it just didn't make it in.
> 
> > 
> > Regards,
> > Aki
> > 
> >  > Aki Niemi wrote:
> >  > 
> >  > > Hi All,
> >  > >

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:29:35 +0300

Yes, just support. If a conference server wants message/cpim, it indicates so in the offer or answer (dial out and dial in cases)

/Hisham

> Sent: Monday, October 20, 2003 9:25 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: Niemi Aki (NMP/Helsinki); [email-masked]
> Just to be sure that we are clear on this, I agree that we should 
> mandate _support_. _Use_ is still up to the endpoints to 
> negotiated. I 
> think this accomplishes what we need, without encumbering simple 
> point-to-point sessions with the extra overhead.
> 
> [email-masked] wrote:
> 
> > I vote for mandating message/cpim. Of course, we still need 
> to signal what mime-types an endpoint supports, using SDP.
> > 
> > /Hisham
> > 
> > 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Ben Campbell
> >>> > Subject: Re: [Simple] Comments on MSRP - multiparty 
> >>
> >>message session
> >>
> >>> > support
> >>> > 
> >>> > 
> >>> > simply having the mixer remember the identity associated 
> >>
> >>with each 
> >>
> >>> > connection.
> >>>
> >>> > > how would a participant know where a message is coming 
> >>
> >>from in a 
> >>
> >>> > > prevents sending private messages efficiently within a 
> >>
> >>multiparty 
> >>
> >>> > > functionality as an extension, or would it be wise to 
> >>
> >>think ahead 
> >>
> >>> > > already now?
> >>> > > 
> >>> > > The draft includes some extensibility, e.g., for 
> >>
> >>authentication 
> >>

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:29:35 +0300

/Hisham