Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Wed, 25 Aug 2004 10:45:56 -0700

Inline. 

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Wednesday, August 25, 2004 6:31 AM
> To: Orit Levin
> Cc: Paul Kyzivat; Alan Johnston; [email-masked]
> Subject: Re: [Simple] MSRP: Contributor ID
> 
> Orit Levin wrote:
> 
> >I am back from my one week vacation :-) I can see at least two 
> >independent major problems when using CPIM wrapper for MSRP 
> >conferencing:
> >
> >1. Let's assume that CPIM support is mandatory but CPIM use 
> is optional 
> >as per Paul. If the sender is a conference-unaware 
> participant, there 
> >is no way to "negotiate" or to request the sender to wrap the MSRP 
> >message
> >  
> >
> 
> Yes, there is. In the SDP, you can indicate that the only 
> unwrapped type that you accept is CPIM. This forces the 
> remote endpoint to always send CPIM-wrapped messages.
> 
I understand. This case will work if a focus will always request for
(and insist on) CPIM wrap for both dial-in and dial-out calls. This
assumption needs to be explicitly stated in the core MSRP if we stick to
CPIM. I still have privacy concerns with this scenario, but they depend
on the solution to the second "problem" below.

> >2. Let's assume that the sender is a conference-aware 
> participant who 
> >also wants to convey its private identity in an encrypted 
> CPIM header 
> >to its peer(s). This is the original purpose for using CPIM 
> and it must 
> >be possible to convey the identity without letting any intermediate, 
> >including the focus, to learn it. The collison problem here is that
> >- the CPIM content is the peer-to-peer application 
> information and, as 
> >such, is transport independent and can be encrypted
> >- the missing from MSRP "Source ID" is the transport 
> protocol identity 
> >and can't be encrypted in order to be used by intermediates 
> Any focus 
> >(e.g. operated by XCON) must be able to include some 
> well-defined user 
> >identity in its (XCON, conferencing package) communications with the 
> >participants.
> >
> 
> This correlation is provided by the first element in the From-Path.
>
I hope I don't understand your answer.
Do you envision that for each real source a different From-Path value
will be generated by the focus? (a-la SSRC by mixer)

What is the perceived "dialog-id" or "session-id" for MSRP and how many
MSRP "dialogs" or "sessions" do you see being established (by SDP) and
maintained between a focus and its single participant?
> /a

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Aug 2004 14:36:52 -0500

> will be generated by the focus? (a-la SSRC by mixer)

I think Adam's point was, if the focus needs to know who sent a 
particular message, it can compare the From-Path value with the values 
used in the initial session creation, and infer the sender's identity.

> maintained between a focus and its single participant?

There is likely one MSRP session, and one SIP dialog between the focus 
and a given participant. Clearly that does not _have_ to be the case, 
but it will be the common case.

I think there are two basic models of focus operation we need to deal 
with, and your problem statement appears to be rooted in the second of 
them.

1) The focus tells each participant to identify themselves. The focus 
requires all messages to be wrapped in CPIM using the wrapped-types 
mechanism.

2) The focus says, no _I_ will identify you. The focus determines the 
identity from the session parameters, and inserts something attributing 
the message to a sender. This could be a header, or it could add its on 
CPIM wrapper. If the message already had a cpim wrapper, then the focus 
could choose to leave it alone, or put it inside yet another wrapper. 
(You can have nested cpim wrappers.)