Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Wed, 11 Aug 2004 16:05:44 -0700

XCON is an application protocol to control conferences and (indirectly)
"mixers". I am not advocating discussing (and supporting) XCON or any
other advanced conferencing design as a part of MSRP :-) Not at all!

I am saying that MSRP must have the basic hooks (as all other media
protocols have today) for allowing various conferencing designs to
happen and without requiring participants to support special extensions
in order to be invited to or dial-into a conference. This is the basic
SIPPING conferencing requirements which are possible with all other
media.

We could say that all MSRP clients MUST always be prepared to receive
CPIM as a part of the core MSRP. That is even when no end-to-end
security is being used. I think that it is a complete misuse of CPIM.

When you need or willing to use the end-to-end security, in addition to
using CPIM - you will do many other security related steps. Binding it
with simple conferencing under the claim that it makes the
implementations/architecture easer - doesn't sound reasonable to me. I
am afraid it is exactly the opposite:

Focus/mixer and end-to-end security don't live very well together and
using the same header for both - is a certain recipe for big troubles.

In some scenarios foci and GWs will have the dilemma of double wrapping
the data vs. aggregating the CPIM information: one as being received
from a participant and the other for e-to-e security purposes... and
this is just the tip of the iceberg.

Orit.

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2004 3:05 PM
To: Orit Levin
Cc: ext Ben Campbell; SIMPLE WG
Subject: RE: [Simple] MSRP: Contributor ID

On Wed, 2004-08-11 at 20:10, ext Orit Levin wrote:
> BTW the "whisper" functionality, according to XCON design, is being
> achieved very differently from what Aki envisions. The message is
> supposed to be "routed" based on the media policy kept in the media
> policy server - not as a result of a participant inserting the "final
> destination" information in one of the headers of a media/data stream.

Uh... This has been discussed at length in the past, and I do wonder why
people insist on this idea of requiring media policy manipulation in
order to do a simple thing like send a private message.

In any case, media policy alone still wouldn't solve the whole problem.
How would the recipient know that the received message was private and
not sent to all of the participants?

Anyway, I thought what I described *was* the XCON design - at least
that's what the conclusion we arrived somewhere around Seoul was. I
agree there is some configuration present in the media policy that then
allows temporary changes to happen in the mixing of an IM conference.
But those changes would be brought upon by something signaled in-band in
the media stream, e.g., using the CPIM To header.

Cheers,
Aki

> Cheers,
> Orit.
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Aki Niemi
> Sent: Wednesday, August 11, 2004 8:34 AM
> To: ext Ben Campbell
> Cc: SIMPLE WG
> Subject: Re: [Simple] MSRP: Contributor ID
> 
> Hi,
> 
> IMO, there are two things CPIM is needed for in a conferencing
scenario:
> 
> 1 - In your use case below, for a focus-inserted "asserted" identity
> identifying the sender of the message
> 
> 2 - For routing purposes, in order to route messages based on who the
> messages were addressed to. This is to enable whispering within a
> conference (i.e., sending a certain message not to the entire
> conference, but to one or a few of the participants). This has been
> discussed before at length.
> 
> Clearly, CPIM (ugly as it may be) can be made to handle both of these
> needs. Contributor-ID will only cover the first one - unless of course
> we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted
> by the client, to cover the second need.
> 
> Cheers,
> Aki 
> 
> 
> On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote:
> > Hi,
> > 
> > In last week's SIMPLE meeting, Orit brought up an issue about how we

> > planned to identify contributors when MSRP is used with a conference

> > focus. Previously, we had discussed using message/cpim wrappers for 
> > this purpose.
> > 
> > After thinking through the use case, I think Orit may be correct
that 
> > cpim is unwieldy for this purpose.
> > 
> > The use case I think we have in mind is, you have a text conference 
> > where each participant has an independent MSRP session with the 
> > conference focus. The focus acts as a reflector, forwarding messages

> > that come in on one participant session to each of the other 
> > participants. It needs a way to tell the receiving parties which 
> > participant sent the message. _How_ it determines what contributor
ID 
> > to attach to a given message is out of scope for MSRP--that problem 
> > belongs to XCON.
> > 
> > We had previously assumed the focus would simply wrap the inbound 
> > message in a message/cpim document, and use the CPIM "from" field
for 
> > this purpose. This, however, is problematic for chunked messages, as

> > the focus would need to buffer the message until it had received all

> > the chunks, wrap the completed message in the cpim document, and
then 
> > send that message out to the other participants, possibly
re-chunking 
> > in the process. This does seem to me to be burdensome on the focus;
it
> 
> > would be nicer if the focus could simply forward the individual
> chunks, 
> > and let the endpoints deal with re-assembling them.
> > 
> > Another approach would be to have the focus force the endpoints to
use
> 
> > a cpim envelope. However, there may be times where the identity that

> > the focus wants to insert may be different than the identity that
the 
> > endpoint inserts.
> > 
> > Therefore, I propose we add a new optional header called 
> > Contributor-ID, which can carry a name-addr. Normal endpoints would 
> > never insert this, but a conference focus could insert this header
on
> a 
> > per-chunk basis, and avoid the buffering requirement mentioned
above.
> > 
> > What do others think? Am I completely off base?
> > 
> > Thanks!
> > 
> > Ben. 
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 13 Aug 2004 13:23:02 -0500

> security is being used. I think that it is a complete misuse of CPIM.

We already have a MUST SUPPORT requirement for CPIM, to allow 
interoperability with other cpim compliant IM protocols. For the same 
reason, we also have a mechanism that allows an endpoint to require the 
peer to always use CPIM.

> this is just the tip of the iceberg.

Although the primary motivation behind cpim is to allow end-to-end 
security, it also works well for delivering identity information. I 
think this is a good thing, as it fits with the IETF philosopy of 
coming up with a few primatives on which many applications can be 
built, rather than a separate mechanism for each application. (Consider 
why SIP has a REFER method, rather than a TRANSFER method.)

I am not convinced that the double identity assertion problem does not 
exist even without the use of a cpim gateway, and therefore will also 
exist with a source identity header.