Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Wed, 11 Aug 2004 10:10:54 -0700

Needlessly to say, I strongly disagree that this is out of scope to
MSRP. By assuming this, we are just inviting proprietary implementations
and a lot of fun at interop events.

Based on the SIPPING Conferencing Requirements and Framework, conference
unaware SIP UAs MUST be able to participate and be invited to a
conference. What kind of experience will this participant get without
having the real source of the message being displayed to him/her?

Why do you expect from XCON to address MSRP as a special media type and
treat it differently - when other media types (i.e. all the RTP based
streams) have this information in place?

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.

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: Wed, 11 Aug 2004 12:45:00 -0500

Just to clarify: Are you saying you believe that MSRP conference focus 
behavior should be specified in the MSRP core spec?

---

From: Aki Niemi <[email-masked]>
Date: Thu, 12 Aug 2004 01:05:25 +0300

> 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