Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Sat, 14 Aug 2004 11:40:21 -0700

Just to a add to Ben's summary,
There is additional the simplest and the best (in my mind) approach:

By including a "SourceID" header into MSRP, we allow for any type of
conferencing architecture (and other possible applications) to handle
MSRP sessions in the same way it chooses to handle RTP/RTCP sessions
WITHOUT requiring MSRP specs to discuss conferencing in any details.

Orit.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Friday, August 13, 2004 11:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Orit Levin;
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Simple] MSRP: Contributor ID

It does not seem like we are converging on a consensus here. Let me 
back up a level:

I think we have one high-level decision to make before we can decide on 
the details. That is, how much effort do we intend to put into making 
sure that the MSRP core spec can support all likely conference 
scenarios?

The working group's previous consensus was to simply say that, if you 
need to carry this sort of information, use CPIM. We did not discuss 
questions about whether the sender uses cpim, or a focus wraps received 
messages in cpim before sending them out, etc. We did not discuss 
situations where different nodes have different ideas about what 
identity should be used.

The opposite extreme would be to make an effort to define all the 
conferencing use-cases we care about, and choose the mechanism that 
best fits. Now, this may be a good thing to do, but it would once again 
be a case of delaying the completion of MSRP because we decided to add 
significant new requirements at the last minute.

A middle ground would be to consider one or two very simple use cases, 
such as a single-focus, and maybe a single-focus where at least 
participant is crossing a cpim gateway from another protocol.

So, can we reach a consensus about which of these three approaches to 
take? Personally, I think lack of consensus on this point means we do 
nothing. Do the chairs have an opinion?

On Aug 12, 2004, at 9:51 AM, <[email-masked]> wrote:

> That's definitely conference policy and is outside the scope of MSRP.
>
> /Hisham
>
>> -----Original Message-----
>> From: ext Cullen Jennings [mailto:[email-masked]]
>> Sent: 12.August.2004 03:55
>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki);
>> Orit Levin;
>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat
>> Cc: [email-masked]
>> Subject: Re: [Simple] MSRP: Contributor ID
>>
>>
>>
>> Sounds like a reasonable idea to me. I think we would want to
>> add that if
>> the user had requested Privacy either via the privacy header
>> or setting From
>> to Anonymous then the contributor id should not be revealed
>> here. Even if
>> the user authenticated via pins or something, the identity
>> should not be
>> revealed here if the original call was private.
>>
>>
>> On 8/9/04 11:27 AM, "Ben Campbell" <[email-masked]> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Aug 2004 11:57:32 -0400

> WITHOUT requiring MSRP specs to discuss conferencing in any details.

To pursue that philosophy, the "SourceID" should be as semantically 
similar as possible to that of RTP/RTCP. That would mean it should not 
be signed, or end to end secure, and should be be able to accomodate 
multiple values.

I'm inclined to think we would like to do something different than that, 
but need to do work with the conference team to figure out what. Is 
there really any problem is waiting for them to figure out what they 
need, and then add it?

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Aug 2004 11:04:35 -0500

On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote:

> I'm inclined to think we would like to do something different than 
> that, but need to do work with the conference team to figure out what. 
> Is there really any problem is waiting for them to figure out what 
> they need, and then add it?
>

If that means blocking completion on the MSRP base spec, I think we are 
trying to meet some deadlines from external liason groups. The chairs 
can probably clarify.

>> From: Ben Campbell [mailto:[email-masked]] Sent: Friday, August 13, 
>> 2004 11:35 AM
>> I think we have one high-level decision to make before we can decide 
>> on the details. That is, how much effort do we intend to put into 
>> making sure that the MSRP core spec can support all likely conference 
>> scenarios?
>> questions about whether the sender uses cpim, or a focus wraps 
>> received messages in cpim before sending them out, etc. We did not 
>> discuss situations where different nodes have different ideas about 
>> what identity should be used.
>> best fits. Now, this may be a good thing to do, but it would once 
>> again be a case of delaying the completion of MSRP because we decided 
>> to add significant new requirements at the last minute.
>> A middle ground would be to consider one or two very simple use 
>> cases, such as a single-focus, and maybe a single-focus where at 
>> least participant is crossing a cpim gateway from another protocol.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Aug 2004 14:02:53 -0700

This is starting to look like ....

1) CPIM would work
2) we could define something else later if we wanted without breaking
current stuff

This makes me think it is a separable problem and should be separated from
the MSRP base.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 16 Aug 2004 16:03:01 -0500

My 2-cents an individual contributor:

I expect that we have many different ideas of what this
identifier means and what it should be used for. Because
of that, it's not clear to me where there needs to be
_protocol_ to solve the problem.

If we are going to pursue adding MSRP syntax, then we
will have, in this forum, to talk about the impact of
the behavior of that syntax, agree on the security 
properties we want around that behavior, and build the
mechanism to meet those properties. If we're looking
for anything more than a "because I said so" token
like CSRC or P-Asserted-Identity in other spaces,
we've got a lot to talk about. 

We have the option of leaving that conversation to
the application using MSRP. The original proposal
of using cpim is an existence proof that apps
can achieve much more than "because I said so" without
additional MSRP mechanics. As an individual contributor,
I think this is something we can leave to the application,
by way of doing "stuff" in the body (doesn't _have_ to
be CPIM wrapping if that tastes so bad). We can point to
something like CPIM wrapping as evidence that we aren't
making it impossible, and leave the long-hard discussion
we'd otherwise have to have for the conferencing work.

RjS

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Aug 2004 16:16:34 -0500

> This makes me think it is a separable problem and should be separated 

I agree, assuming we don't _later_ decide we need to add a new header. 
If that happens, since we don't have an extension negotiation 
mechanism, then many clients would not be able to participate in the 
conferencing solution.

However, if we stick to using something in the body for this, we at 
least have some mechanism for negotiating body content-types. 
Furthermore, if we can make it work with cpim, we have mandatory 
support for that.

So, after much flipping of opinions, I think I am back to thinking that 
we do not need to do anything in the base protocol definition.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Aug 2004 16:18:50 -0500

Just to be precise, I think you are proposing that we do not add 
anything new to the base protocol for this purpose, correct? That is, 
leave things as they are?

---

From: Robert Sparks <[email-masked]>
Date: Mon, 16 Aug 2004 16:49:36 -0500

Yes, with the possible addition of some forward looking text capturing
that we thought about the problem and expect to be able
to solve it without needing to change the MSRP protocol itself.

RjS

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Aug 2004 17:24:36 -0500

At the cost of putting in a "me too" post, I agree with Robert and Ben 
that there is no good reason to change the solution which we agreed to 
in Ottawa. The properties of identity in CPIM are well defined and 
clearly specified. They can clearly be leveraged solve the problem at hand.

It seems obvious that arguments like "it won't work" would be a valid 
reason to re-visit consensus.

At this late stage in the process, I think that anything *short* of "it 
won't work" shouldn't be entertained.

(Just from a practical perspective, allowing substantial changes to 
consensus around a valid functional solution months after that consensus 
has been reached gives detractors the opportunity to derail any effort 
at a whim. I take no position about whether such is occurring in this 
case, but worry about precedent if this topic is allowed to slow 
completion of MSRP. Chairs?).

/a

---

From: Alan Johnston <[email-masked]>
Date: Mon, 23 Aug 2004 12:19:56 -0500

At 05:24 PM 8/16/2004 -0500, Adam Roach wrote:
>that there is no good reason to change the solution which we agreed to in 
>Ottawa. The properties of identity in CPIM are well defined and clearly 
>specified. They can clearly be leveraged solve the problem at hand.
>

(Joining this discussion late, so my apologies.)

I suspect "it won't work".  MSRP must define in the base specification 
source identification and how mixing is done without loosing source 
identification.  Otherwise, MSRP will be dumber than RTP, and will be a 2nd 
class citizen in conferencing, unable to meet the basic requirements in the 
SIPPING conferencing framework.  MSRP can not be dumber than RTP.

The worst result possible would be for a conference unaware user agent in 
an MSRP conference to have all the participants messages be attributed to 
the focus because we left out basic source identification.  At a minimum, 
it would need to be attribute different messages to different participants 
without knowing who they are (this is the XCON problem).

Any acceptable proposal must rule out this possibility - I don't see how an 
optional CPIM encoding solves this problem.

Thanks,
Alan
sip:[email-masked]

>has been reached gives detractors the opportunity to derail any effort at 
>a whim. I take no position about whether such is occurring in this case, 
>but worry about precedent if this topic is allowed to slow completion of 
>MSRP. Chairs?).
>
>/a
>
>Robert Sparks wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Aug 2004 13:36:03 -0500

Alan Johnston wrote:

>> At the cost of putting in a "me too" post, I agree with Robert and 
>> Ben that there is no good reason to change the solution which we 
>> agreed to in Ottawa. The properties of identity in CPIM are well 
>> defined and clearly specified. They can clearly be leveraged solve 
>> the problem at hand.
>>
> identification.

Source identification can be performed by correlation between the 
initial "From-Path" header element and the session establishment. There 
isn't really mixing per se involved, simply message switching -- so all 
we need is a mechanism to identify (a) who originated the message (get 
this from CPIM), and (b) the "mixer" that sent it to you (get this from 
"From-Path.")

Does that address your concern, or did I misunderstand?

/a

---

From: Alan Johnston <[email-masked]>
Date: Mon, 23 Aug 2004 14:27:03 -0500

At 01:36 PM 8/23/2004 -0500, Adam Roach wrote:
>Source identification can be performed by correlation between the initial 
>"From-Path" header element and the session establishment. There isn't 
>really mixing per se involved, simply message switching -- so all we need 
>is a mechanism to identify (a) who originated the message (get this from 
>CPIM), and (b) the "mixer" that sent it to you (get this from "From-Path.")
>

I thought CPIM use was optional.   If so, this proposal seems to 
break.  Remember, the SSRC is RTP is not optional - it is a MUST in the 
spec.  MSRP needs similar strength or interoperability problems will result.

Thanks,
Alan
sip:[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Aug 2004 14:49:39 -0500

Alan Johnston wrote:

>> initial "From-Path" header element and the session establishment. 
>> There isn't really mixing per se involved, simply message switching 
>> -- so all we need is a mechanism to identify (a) who originated the 
>> message (get this from CPIM), and (b) the "mixer" that sent it to you 
>> (get this from "From-Path.")
>>
> break.  Remember, the SSRC is RTP is not optional - it is a MUST in 
> the spec.  MSRP needs similar strength or interoperability problems 
> will result.

I agree.

SSRC is mandatory in the same way that From-Path is mandatory. 
Semantically, they identify the same element.

CSRC is optional in the same way that CPIM is optional. Semantically, 
they identify the same element.

/a

---

From: Alan Johnston <[email-masked]>
Date: Tue, 24 Aug 2004 12:33:53 -0500

At 02:49 PM 8/23/2004 -0500, Adam Roach wrote:
>CSRC is optional in the same way that CPIM is optional. Semantically, they 
>identify the same element.

Well, CSRC is optional in RTP, which might explain why no one implements it 
today - not a good outcome that we wish to repeat.  It is not critical 
because with voice or video media, we can do the identification by sound or 
sight, so we get by.

For text, this is not possible, so I think the semantic equivalent of CSRC 
must not be optional, and must be fully defined in the base spec of 
MSRP.  Otherwise, in a few months, XCON will send SIMPLE a requirement to 
extend MSRP in order for text chat rooms and sessions to work properly.  We 
know the requirements - why not just do it now and be done with it?  'd 
rather not leave a big mess for XCON to have to clean up.

Also, even though CSRC is optional, it is fully specified in the base RTP 
specification - we need the same thing here in MSRP.

If CPIM is the right way (not clear to me, but I don't follow SIMPLE 
closely), the use of CPIM for CSRC needs to be mandated and fully specified 
in the base MSRP specification.

Thanks,
Alan
sip:[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 Aug 2004 12:52:05 -0500

Alan Johnston wrote:

> closely), the use of CPIM for CSRC needs to be mandated and fully 
> specified in the base MSRP specification.

I think we may actually be in agreement on this, but I need to poke at 
it a little bit.

What I think is reasonable is provisions that you MUST be able to 
receive CPIM, and you MUST be able to send CPIM if the remote side 
requests that you do so.

I do _not_ think that _mandating_ that every message use CPIM is 
reasonable. If you're sending MSRP point-to-point between two endpoints 
that want to do so without wrapping each message in CPIM, I think they 
should be allowed to do so.

Is that what you're arguing for, or do you want to force the use of CPIM 
in all cases?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Aug 2004 14:34:00 -0400

Alan Johnston wrote:
>> There isn't really mixing per se involved, simply message switching -- 
>> so all we need is a mechanism to identify (a) who originated the 
> I thought CPIM use was optional.   If so, this proposal seems to break.  
> Remember, the SSRC is RTP is not optional - it is a MUST in the spec.  
> MSRP needs similar strength or interoperability problems will result.

Support of CPIM is necessary for interop, but use isn't necessary.

If it is required in some context, e.g. in inputs to a conference mixer, 
then it is simple to negotiate a requirement for a CPIM wrapper on every 
message.

	Paul