Subject: RE: [Simple] Chat sessions

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 00:46:52 -0500

Aki

When we were discussing sidebars, I made arguments like this against making
a sidebar
a separate session.  Sidebars, I argued, are just media (mixing) changes,
they have
nothing to do with session management.

I lost this argument, and I will be very unhappy if IM works differently.
One of
the reasons I lost it was the observation that a sidebar could include
participants
who are not main conference participants.  I think you have the same issue
here.

Brian

> -----Original Message-----
> From: Niemi Aki (Nokia-M/Espoo) [mailto:[email-masked]]
> Sent: Sunday, February 29, 2004 12:40 PM
> To: ext Jonathan Rosenberg
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Simple] Chat sessions
> 
> 
> 
> 
> ext Jonathan Rosenberg wrote:
> <snip />
> 
> >> 3. As Aki explained, sidebars and private IMs within a conference 
> >> are two different things. Sidebars are subconferences, that include
> >>  a certain subset of the participants in the main conference. They 
> >> need to be explicitly created and deleted. Private IMs within a 
> >> conference are also targeted to a subset of the conference 
> >> participants. But there is no need to setup a sidebar or any other 
> >> additional context to send them. The recipients can simply be 
> >> signaled within each message (as proposed by using CPIM To header).
> >>  This seems to be a specific property of IM, as this sort of 
> >> addressing would be impossible e.g. in RTP. In theory priate 
> >> messaging facility could be supported by sidebars, but in this case
> >>  the focus would need to have as many sidebars constantly setup, as
> >>  there are different possible participant subset combinations. Way 
> >> too complex and not needed.
> > 
> > 
> > I dont think that, functionally, what you are describing is 
> different
> >  from a sidebar. What differs is that the specifics of this media 
> > type allow for a more efficient implementation of the sidebar than 
> > would be possible for another media type, such as audio. 
> Indeed, the 
> > same is true for IM in general - why set up a session (ala 
> msrp) when
> > you can just send a pager mode?
> 
> The ultimate proof of difference in functionality is that private
> messages are usable and useful in a sidebar - in fact it makes no
> difference whether they're sent within the context of a conference, a
> conference sidebar, or a sidebar of a conference sidebar.
> 
> Let me provide a concrete example of an already existing service (IRC)
> that has what I think is a close approximation of both sidebar and
> private message functionality. (BTW, I feel strongly that if MSRP
> conferences aren't as feature rich as IRC is, and provide the 
> same user
> experience, we've failed miserably.)
> 
> Channels in IRC have identities, e.g., #helsinki, and 
> participant lists
> that are delivered in a very similar manner that the conference-info
> events would be delivered. Users join these channels using JOIN, at
> which time they get the participant list, and after that, 
> updates e.g.,
> whenever anyone leaves or joins the channel.
> 
> Users can send private messages to the other participants in 
> the channel:
> 
> 	PRIVMSG foobar :Some nick you got there foobar!
> 
> Usually, these messages are displayed in the same pane as the rest of
> the channel's messages, including information about the sender but
> marked accordingly as private.
> 
> A user can also invite others to a sidebar of sorts, that is, a new
> channel, whose properties can be set such that it can be joined by
> invitation only.
> 
> 	INVITE FunnyNick #my_channel
> 	INVITE BeerLover #my_channel
> 	INVITE ROOLZ #my_channel
> 
> Joining this new channel as a result of an invitation (with JOIN)
> usually results in a new window, moving the focus of conversation away
> from the original channel, but still maintaining the original channel'
> and its messages active in the background.
> 
> The users may again send messages either to the entire 
> channel (MSG), or
> to only one participant (PRIVMSG). A recipient of an INVITE will
> generally make a choice just like in a SIP invitation whether 
> or not to
> join the sidebar or not. Receiving a PRIVMSG requires no actions from
> the recipient. Indeed, it might even go unnoticed.
> 
> Taking this into account, I fail to see how sidebars alone can be made
> to work in providing similar functionality in MSRP conferences. Either
> sidears or private messages alone won't result in the same level of
> functionality.
> 
> Wrapping all private conversation inside a sidebar is incredibly
> inefficient and results in bad user experience, since there 
> is no way to
> distinguish a REFER that is to a sidebar whose sole purpose 
> is to send a
> single private message to the user or have a real ad-hoc conversation
> posibly consisting of a real exchange of messages. In fact, this would
> require 4 rounds of singalling (not including sidebar creation and
> tear-down), plus user interaction in between:
> 
> REFER (to sidebar)
> 200 OK
> 
> -Query/inform user whether wants to join-
> 
> INVITE (to sidebar)
> 200 OK
> ACK
> 
> (Note: would probably also require subscription to conference-info,
> because one would be interested to whom they are sending the private
> messages...)
> 
> MSRP SEND
> MSRP OK
> 
> BYE
> 200 OK
> 
> ...as opposed to a single round of messages:
> 
> MSRP SEND (private)
> 200 OK
> 
> (Note that enabling auto-answering wrt the REFER would in the 
> worst case
> result in a sidebar bombardment, or having a user be moved over to a
> sidebar in the middle of, say, message composition.)
> 
> The same level of functionality would also not be met with only using
> private messages. AFAIK, the purpose of a sidebar is to move the focus
> of the conversation temporarily outside the original conference. This
> requires being able to wrap a discussion into a separate 
> context. A very
> important aspect of this is to let the user decide whether to 
> joing such
> a sidebar, and when to join it. Determining to which context a
> particular received private message belongs to can in this 
> case only be
> done in the recipients head - there are no protocol elements to help.
> 
> As a conclusion, I don't see how sidebars alone can provide 
> the required
> functionality.
> 
> > 
> > So, the question is, do we see the perceived efficiency 
> improvements 
> > of a pager-mode sidebar as being sufficiently good to allow for 
> > defining a separate sidebar mechanism for it?
> 
> It is also about user interaction. When a user receives an 
> INVITE for an
> MSRP session, it can make a choice just like in a voice call between
> accepting the call or rejecting it. Page mode doesn't provide that 
> functionality.
> 
> Cheers,
> Aki
> 
> > -Jonathan R.
> 

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 05:41:17 -0500

Aki

My post was meant to point out that we had decided to implement sidebars
as separate dialogs from main conferences, which is similar to making
"private messages" separate dialogs from a main IM dialog.  In that
way, I think that sidebars and private messages are the same; they are
media sent to a subset of participants in the group.  If there
is a reason to allow a special way to subset destinations for a
private message rather than the entire chat group, then whatever
argument you make would apply to a sidebar.  

Brian

> Sent: Monday, March 01, 2004 2:58 AM
> To: ext Rosen, Brian
> Cc: ext Jonathan Rosenberg; [email-masked];
> Brian,
> I've never argued for private messages over sidebars. I still 
> maintain 
> that sidebars and private messages are different and *complimentary* 
> features, and that we need *both* to have a complete solution for IM 
> conferences.
> 
> Cheers,
> Aki
> 
> ext Rosen, Brian wrote:
> > Aki
> >

---

From: [email-masked]
Date: Tue, 2 Mar 2004 03:16:04 +0200

Hi,

It seems we are not getting the message through ;)

Let's see how sending a private message looks like as a sidebar vs. as proposed in the current draft. The case is this: Users A and B participate in the same conference, A wants to send a private message to B.

Sidebar case would be roughly like this:
1. A creates a conference for a sidebar using INVITE
   - new MSRP session is established between A and the new focus instance
2. A refers B to that conference
3. B joins the conference
   - new MSRP session is established
4. A sends MSRP SEND request to the conference
5. focus forwards it to B
6. A sends BYE
7. focus sends BYE to B

If B replies after 10 seconds, the whole process is followed again from 1 to 7.

Private message case:
1. A sends private message targeted to B over an existing MSRP session
2. focus forwards it to B

So which solution would you like to adopt? 

Markus

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: 01 March, 2004 12:41
> To: Niemi Aki (Nokia-M/Espoo)
> Cc: ext Jonathan Rosenberg; Isomaki Markus (Nokia-NRC/Helsinki);
> [email-masked]; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Garcia
> Miguel.An (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [Simple] Chat sessions
> 
> 
> Aki
>

---

From: [email-masked]
Date: Tue, 2 Mar 2004 03:16:04 +0200

Hi,

Private message case:

Markus

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 20:34:42 -0500

What is the difference between a sidebar and a private message?

I think the ONLY difference is the number of people involved.

A sidebar is two or more.  A private message is exactly two.

There is NO other meaningful difference.

Your argument on overhead is directly comparable to the argument
we went through when we defined sidebars as separate sessions.
I argued that we should NOT create a separate session, but
simply alter the media policy appropriately.  You are simply
repeating the arguments I made.

I lost that argument.  

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 8:16 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 
> [email-masked]
> Let's see how sending a private message looks like as a 
> sidebar vs. as proposed in the current draft. The case is 
> this: Users A and B participate in the same conference, A 
> wants to send a private message to B.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 20:34:42 -0500

I lost that argument.  

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 20:41:49 -0500

Probably, I just answered this.

A private message is a sidebar with exactly two participants.  A sidebar is
a set of private messages with possibly more than two participants.  The way
you render these could be the same, or different if you wish.  The only
thing that matters is whether there is any functional difference.  I don't
think that there is.

Consider a push to talk one-on-one voice connection within a conference.
That's pretty close to a private message.  If I implemented that, how would
you want me to do it?  As a sidebar?  As a media policy manipulation?
How about the "whisper" function in a call center.  Same thing.

Brian

> Sent: Monday, March 01, 2004 12:54 PM
> To: ext Rosen, Brian
> Please go back to my previous post where I make a comparison 
> to similar
> (if not identical) functionality in IRC. There, sidebars and private
> messages are clearly separate functionality.
> 
> If you can show that the analogy between IRC and IM conferences is
> false, or describe how sidebars alone are enough to implement this 
> functionality in IM conferences, I'm happy to back down on this
> issue.
> 
> Cheers,
> Aki
> 
> ext Rosen, Brian wrote:
> > Aki
> > 
> > My post was meant to point out that we had decided to implement
> > sidebars as separate dialogs from main conferences, which is similar
> > to making "private messages" separate dialogs from a main IM dialog.
> > In that way, I think that sidebars and private messages are 
> the same;
> > they are media sent to a subset of participants in the group.  If
> > there is a reason to allow a special way to subset 
> destinations for a

---

From: [email-masked]
Date: Tue, 2 Mar 2004 04:07:55 +0200

Hi,

I don't see us getting to agreement here... Still, see below:

> Sent: 02 March, 2004 03:35
> To: Isomaki Markus (Nokia-NRC/Helsinki); Niemi Aki (Nokia-M/Espoo)
> Cc: [email-masked]; [email-masked]; Khartabil Hisham
> (Nokia-TP-MSW/Helsinki); Garcia Miguel.An (Nokia-NRC/Helsinki);
> [email-masked]

I don't think we need to limit the number of recipients for the private message. The only thing is that they need to be conference participants.

> repeating the arguments I made.

My comment to that is that there are differences in medias that should be taken into account. As you see in the example I made, having only one solution leads to hugely unoptimal system.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 23:34:15 -0500

Doesn't work for me; you don't need a resource URI for a sidebar.  You might
be
able to use one, but its not necessary.  The only characteristic of a
sidebar
that matters is that the media goes to a subset of participants.

You need some identifier in all cases.  

Let me push this in another direction.

What makes a private message different from an instant message to a totally
arbitrary person (not related to the main conference)?  Is it just that the
set of possible destinations is limited to those in the main conference?
Why is that interesting in a protocol sense?

Brian

> From: Miguel Garcia [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 9:29 PM
> To: Isomaki Markus (Nokia-NRC/Helsinki)
> Cc: ext Rosen, Brian; Niemi Aki (Nokia-M/Espoo);
> [email-masked]; [email-masked]; Khartabil Hisham
> (Nokia-TP-MSW/Helsinki); [email-masked]
> Folks, what about this one:
> 
> A sidebar conference is a temporary scoped subconference. By 
> temporary 
> scoped I mean it exists  (has an associated resource URI) for some 
> duration time. The participants may or may not be part of the main 
> conference. Messages are addressed to the sidebar conference, in a 
> similar way a message is addressed to the conference. The 
> sender may or 
> may not know who are the members of the sidebar conference.
> 
> A private message is not temporary scoped and it is not 
> identified by a 
> resource URI. Unlike sidebar conferences, the participants 
> are a subset 
> of the conference. Unlike sidebar conferences, private messages are 
> addressed to each of the receivers, since there is not a resource 
> associated with it. The sender has to explicitly define the 
> receivers of 
> the message.
> 
> Miguel
> 
> Isomaki Markus (Nokia-NRC/Helsinki) wrote:
> 
> > Hi,
> > 
> > I don't think we need to limit the number of recipients for 
> the private message. The only thing is that they need to be 
> conference participants.
> > 
> > 
> > My comment to that is that there are differences in medias 
> that should be taken into account. As you see in the example 
> I made, having only one solution leads to hugely unoptimal system. 
> > 
> > 
> >>Brian
> >>
> >>
> >>>1. A sends private message targeted to B over an existing 
> >>
> >>MSRP session
> >>
> >>>>[email-masked]; Khartabil Hisham 
> >>
> >>(Nokia-TP-MSW/Helsinki); Garcia
> >>
> >>>>as separate dialogs from main conferences, which is similar 
> >>>
> >>>to making
> >>>
> >>>>"private messages" separate dialogs from a main IM 
> >>
> >>dialog.  In that
> >>
> >>>>way, I think that sidebars and private messages are the 
> >>>
> >>>same; they are
> >>>
> >>>>>that sidebars and private messages are different and 
> >>>>
> >>>>*complimentary* 
> >>>>
> >>>>>features, and that we need *both* to have a complete 
> >>>>
> >>>>solution for IM 
> >>>>
> >>>>>conferences.
> >>>>>
> >>>>>Cheers,
> >>>>>Aki
> >>>>>
> >>>>>ext Rosen, Brian wrote:
> >>>>>
> >>>>>>Aki
> >>>>>>
> >>>>>>When we were discussing sidebars, I made arguments like 
> >>>>>
> >>>>>this against making
> >>>>>
> >>>>>>a sidebar
> >>>>>>a separate session.  Sidebars, I argued, are just media 
> >>>>>
> >>>>>(mixing) changes,
> >>>>>
> >>>>>>they have
> >>>>>>I lost this argument, and I will be very unhappy if IM 
> >>>>>
> >>>>>works differently.
> >>>>>
> >>>>>>One of
> >>>>>>the reasons I lost it was the observation that a sidebar 
> >>>>>
> >>>>>could include
> >>>>>
> >>>>>>participants
> >>>>>>who are not main conference participants.  I think you have 
> >>>>>
> >>>>>the same issue
> >>>>>
> >>>>>>here.
> >>>>>>
> >>>>>>Brian
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>3. As Aki explained, sidebars and private IMs within a 
> >>>>
> >>>>conference 
> >>>>
> >>>>>>>>>are two different things. Sidebars are subconferences, 
> >>>>>
> >>>>>that include
> >>>>>
> >>>>>>>>>a certain subset of the participants in the main 
> >>>>>
> >>>>>conference. They 
> >>>>>
> >>>>>>>>>need to be explicitly created and deleted. Private 
> >>>
> >>>IMs within a 
> >>>
> >>>>>>>>>participants. But there is no need to setup a sidebar or 
> >>>>>
> >>>>>any other 
> >>>>>
> >>>>>>>>>additional context to send them. The recipients can 
> >>
> >>simply be 
> >>
> >>>>>>>>>signaled within each message (as proposed by using CPIM 
> >>>>>
> >>>>>To header).
> >>>>>
> >>>>>>>>>This seems to be a specific property of IM, as 
> >>
> >>this sort of 
> >>
> >>>>>>>>>addressing would be impossible e.g. in RTP. In 
> >>
> >>theory priate 
> >>
> >>>>>>>>>messaging facility could be supported by sidebars, but in 
> >>>>>
> >>>>>this case
> >>>>>
> >>>>>>>>>the focus would need to have as many sidebars constantly 
> >>>>>
> >>>>>setup, as
> >>>>>
> >>>>>>>>>there are different possible participant subset 
> >>>>>
> >>>>>combinations. Way 
> >>>>>
> >>>>>>>>from a sidebar. What differs is that the specifics of 
> >>>>
> >>>>this media 
> >>>>
> >>>>>>>>type allow for a more efficient implementation of the 
> >>>>
> >>>>sidebar than 
> >>>>
> >>>>>>>The ultimate proof of difference in functionality is 
> >>>
> >>>that private
> >>>
> >>>>>>>messages are usable and useful in a sidebar - in fact 
> >>>
> >>>it makes no
> >>>
> >>>>>>>difference whether they're sent within the context of a 
> >>>>>
> >>>>>conference, a
> >>>>>
> >>>>>>>Let me provide a concrete example of an already existing 
> >>>>>
> >>>>>service (IRC)
> >>>>>
> >>>>>>>that has what I think is a close approximation of both 
> >>>
> >>>sidebar and
> >>>
> >>>>>>>private message functionality. (BTW, I feel strongly 
> >>>
> >>>that if MSRP
> >>>
> >>>>>>>that are delivered in a very similar manner that the 
> >>>>
> >>>>conference-info
> >>>>
> >>>>>>>events would be delivered. Users join these channels 
> >>>>
> >>>>using JOIN, at
> >>>>
> >>>>>>>Usually, these messages are displayed in the same pane as 
> >>>>>
> >>>>>the rest of
> >>>>>
> >>>>>>>the channel's messages, including information about the 
> >>>
> >>>sender but
> >>>
> >>>>>>>A user can also invite others to a sidebar of sorts, that 
> >>>>
> >>>>is, a new
> >>>>
> >>>>>>>channel, whose properties can be set such that it can 
> >>>
> >>>be joined by
> >>>
> >>>>>>>invitation only.
> >>>>>>>
> >>>>>>>Joining this new channel as a result of an invitation 
> >>>
> >>>(with JOIN)
> >>>
> >>>>>>>usually results in a new window, moving the focus of 
> >>>>>
> >>>>>conversation away
> >>>>>
> >>>>>>>from the original channel, but still maintaining the 
> >>>>>
> >>>>>original channel'
> >>>>>
> >>>>>>>to only one participant (PRIVMSG). A recipient of an 
> >>
> >>INVITE will
> >>
> >>>>>>>join the sidebar or not. Receiving a PRIVMSG requires no 
> >>>>>
> >>>>>actions from
> >>>>>
> >>>>>>>Taking this into account, I fail to see how sidebars alone 
> >>>>>
> >>>>>can be made
> >>>>>
> >>>>>>>to work in providing similar functionality in MSRP 
> >>>>>
> >>>>>conferences. Either
> >>>>>
> >>>>>>>sidears or private messages alone won't result in the 
> >>>>
> >>>>same level of
> >>>>
> >>>>>>>functionality.
> >>>>>>>
> >>>>>>>Wrapping all private conversation inside a sidebar is 
> >>
> >>incredibly
> >>
> >>>>>>>single private message to the user or have a real ad-hoc 
> >>>>>
> >>>>>conversation
> >>>>>
> >>>>>>>posibly consisting of a real exchange of messages. In fact, 
> >>>>>
> >>>>>this would
> >>>>>
> >>>>>>>require 4 rounds of singalling (not including sidebar 
> >>>
> >>>creation and
> >>>
> >>>>>>>(Note: would probably also require subscription to 
> >>>>
> >>>>conference-info,
> >>>>
> >>>>>>>because one would be interested to whom they are sending 
> >>>>
> >>>>the private
> >>>>
> >>>>>>>messages...)
> >>>>>>>
> >>>>>>>MSRP SEND
> >>>>>>>MSRP OK
> >>>>>>>
> >>>>>>>BYE
> >>>>>>>200 OK
> >>>>>>>
> >>>>>>>result in a sidebar bombardment, or having a user be 
> >>>>
> >>>>moved over to a
> >>>>
> >>>>>>>The same level of functionality would also not be met with 
> >>>>>
> >>>>>only using
> >>>>>
> >>>>>>>private messages. AFAIK, the purpose of a sidebar is to 
> >>>>>
> >>>>>move the focus
> >>>>>
> >>>>>>>of the conversation temporarily outside the original 
> >>>>>
> >>>>>conference. This
> >>>>>
> >>>>>>>done in the recipients head - there are no protocol 
> >>>>>
> >>>>>elements to help.
> >>>>>
> >>>>>>>>of a pager-mode sidebar as being sufficiently good to 
> >>>
> >>>allow for 
> >>>
> >>>>>>>MSRP session, it can make a choice just like in a voice 
> >>>>
> >>>>call between
> >>>>
> >>>>>>>accepting the call or rejecting it. Page mode doesn't 
> >>>>
> >>>>provide that 
> >>>>
> >>>>>>>functionality.
> >>>>>>>
> >>>>>>>Cheers,
> >>>>>>>Aki
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>-Jonathan R.
> >>>>>>>
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Mar 2004 23:34:15 -0500

Brian

---

From: [email-masked]
Date: Tue, 2 Mar 2004 06:45:31 +0200

Brian,

> Why is that interesting in a protocol sense?

The difference is that the recipient must be able to distinguish whether the message comes within the context of the conference or separately. Only this way the message can be treated properly in recipient UA. If it's a private message within a chat, it typically appears among the other messages sent within the chat. If it's separate, it typically goes to some sort of inbox, and is displayed separately from the chat. 

Private messages are supported by almost all multiparty-chat systems, so MSRP conferences should be no different.

Markus

> Sent: 02 March, 2004 06:34
> To: Garcia Miguel.An (Nokia-NRC/Helsinki); Isomaki Markus
> (Nokia-NRC/Helsinki)
> Cc: Niemi Aki (Nokia-M/Espoo); [email-masked];
> [email-masked]; Khartabil Hisham (Nokia-TP-MSW/Helsinki);
> [email-masked]

---

From: [email-masked]
Date: Tue, 2 Mar 2004 06:45:31 +0200

Brian,

Markus

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Mar 2004 01:14:07 -0500

> I think what you're referring to is a private sidebar. Being able to 
> receive a private message sent inside a conference (or a 
> sidebar) would 
> require no additional action from the recipient, whereas setting up a 
> private sidebar requires that the invitee also agrees to have the 
> sidebar, joins it etc.
I don't understand this differentiation.  You can define systems
that require the user to agree in advance to some kind of communication,
or you can design them so that they don't need to agree before hand.

I can design a sidebar system that requires you to agree to participate,
and I can design an IM system that requires you to agree to participate.
Conversely, I can design systems for IM or voice that does not.
I have AIM set to require my consent before I receive a message from
someone not on my buddy list.  I could easily want such a feature
for a "private message".  Conversely, I might accept a whisper from
another participant in a conference without consent.

What you want is the logical equivalent of altering the mixing
function so that a subset of the users get the message.  I don't
see why that is different from a sidebar, or whisper.

> Of course you can't do private messages with voice. Voice and IM are 
> inherently different. You can't send private voice packets to another 
> participant of a conference, simply because there isn't a way 
> to single 
> out a participant in a conference by directly addressing 
> packets there. 
> It also makes mixing really complicated, because a private 
> voice stream 
> might overlap with the rest of the conference. These don't present a 
> problem for IM; the sender can single out the recipient using 
> the cpim 
> To header field and the recipient UA can simply mark a message as 
> private and render it to the same UI as the rest of the IMs in that 
> conference.
I protest.  There is no logical difference.  There is no protocol
difference.  In most cases, there is no practical difference.  You
send media to some address, you get media from some address.  You
render it.  IM or voice or video is all just media, and its handled
the same way.  You might have "centralized" or "distributed" mixers.
Most IM systems, as implemented, are centralized mixers.  You send
all media to the mixer, it sends media to you.  There is nothing
special with IM.  You need some signaling for a private message.
You can use the same signaling for a sidebar or a whisper.

---

From: [email-masked]
Date: Tue, 2 Mar 2004 08:35:19 +0200

How about this:

You are in a chat conference and you want to send a private message to 1 or more participants. If you expect to have side conversation (more than 1 message exchanged), then you create a side bar.

If you want to send a one-off message to some of the participants, then you send a SIP MESSAGE request to the focus using exploder techniques where the recipients addresses are carried in the MESSAGE itself. This introduces 2 problems:

1. How can the MESSAGE be related to the conference? This info can be carried in a header of the MESSAGE. Haven't thought what header yet.
2. If users are using nicknames (whatever that means, my definition here means that users are hiding their real identity), then the conference focus needs to find for which conference this private message is intended for participants in, using 1 above, and explode to them.

Of course, we just use MSRP within the existing session and avoid the 2 problems above. I believe this is what Aki, Markus and Miguel are trying to solve. It is really just like a page mode IM to participants in the conference.

Thanks,
Hisham

> Sent: 02.March.2004 06:34

---

From: [email-masked]
Date: Tue, 2 Mar 2004 08:35:19 +0200

How about this:

Thanks,
Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Mar 2004 20:07:01 -0500

How are we going to resolve this?

Most of us are here.  Can we get together?

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, March 02, 2004 6:44 PM
> Cc: ext Rosen, Brian; ext Jonathan Rosenberg; 
> [email-masked];
> Niemi Aki (Nokia-M/Espoo) wrote:
> > 
> >>> participant of a conference, simply because there isn't a way to 
> >>> single out a participant in a conference by directly addressing 
> >>> packets there. It also makes mixing really complicated, because a 
> >>> private voice stream might overlap with the rest of the 
> conference. 
> >>> These don't present a problem for IM; the sender can 
> single out the 
> >>> recipient using the cpim To header field and the recipient UA can 
> >>> simply mark a message as private and render it to the 
> same UI as the 
> >>> rest of the IMs in that conference.
> >>
> > Hmm.. which systems are these? The ones I've used have both private 
> > messages *and* sidebars.
> 
> It seems that in principle the difference between sidebars 
> and private 
> messages is simply one of UI design. A particular client 
> could support 
> one or the other, or both.
> 
> But you also seem to require that the initiator be able to 
> choose which 
> user experience the recipients will have. That turns it into 
> a protocol 
> issue. In general I would consider this a bad idea. But it is 
> largely a 
> human factors issue, and I don't feel qualified to comment on 
> it except 
> from the perspective of personal preference. But it seems that whole 
> discussion hinges on whether there is a valid requirement for giving 
> senders that degree of control over recipients.
> 
> 	Paul
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Mar 2004 21:19:45 -0500

Okay, lunch tomorrow. Meet at reg area.  

Brian

> Sent: Tuesday, March 02, 2004 9:12 PM
> To: ext Paul Kyzivat
> Cc: Rosen, Brian; ext Jonathan Rosenberg; [email-masked];
> [email-masked]'
> Yeah, me too. Lunch tomorrow sounds good.
> 
> Cheers,
> Aki
> 
> ext Paul Kyzivat wrote:
> > I'm game. Who cares? This is in the overlap area between 
> simple and xcon 
> > I think. How about lunch tomorrow, after xcon?
> > 
> >     Paul
> > 
> > Rosen, Brian wrote:
> > 
> >>>>>> Of course you can't do private messages with voice. Voice 
> >>>>>
> >>>>>
> >>> and IM are
> >>>
> >>>>>> inherently different. You can't send private voice 
> >>>>>
> >>>>>
> >>> packets to another
> >>>
> >>>>> the same way.  You might have "centralized" or 
> >>>>
> >>>>
> >>> "distributed" mixers.
> >>>
> >>> It seems that in principle the difference between sidebars and 
> >>> private messages is simply one of UI design. A particular client 
> >>> could support one or the other, or both.
> >>>
> >>> But you also seem to require that the initiator be able to choose 
> >>> which user experience the recipients will have. That 
> turns it into a 
> >>> protocol issue. In general I would consider this a bad 
> idea. But it 
> >>> is largely a human factors issue, and I don't feel qualified to 
> >>> comment on it except from the perspective of personal 
> preference. But 
> >>> it seems that whole discussion hinges on whether there is a valid 
> >>> requirement for giving senders that degree of control 
> over recipients.
> >>>
> >>>     Paul
> >>>
> >>
> >>

---

From: [email-masked]
Date: Thu, 26 Feb 2004 09:05:27 +0200

Jonathan:

Thanks for the review. I basically agree with your comments. I got enough comments as for to figure out how to progress this item. I also noticed that Paul agrees with you, so we are becoming closer to consensus.

A couple of comments though:

>RTP defines the scope of these nicknames as bound to a session, and does 
>not require uniqueness. Thats a bit different than what is being 
>proposed here.

I don't think RTP nickname scope is incompatible with the proposal in the draft. We are proposing a more restrictive allocation and management scheme that fulfills the RTP requirements for a nickname to be bound to a session.

Jonathan also mentioned:

>Note that we have always had a problem with SSRC/CNAME that there was no 
>easy way to map them to a SIP URI that could be used for signaling. That 
>is, the CNAME is not necessarily the SIP URI that one would want to use 
>to contact the user. For example, if I'm in a conference and I want to 
>have a private call with a user, outside of the conference, what SIP URI 
>to use?

This is a problem we are not addressing in our document, and I would consider that we have the means to solve it today with presence, private instant messages, etc. that can carry the URI of the two participants. It is desirable that mapping of the SSRC/CNAME to SIP URIs will take place in the conference server (mixer, I believe), to fulfill the privacy requirements of those users that don't want to expose their SIP URI.

/Miguel

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 25 February, 2004 21:11
> To: Paul Kyzivat
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Garcia Miguel.An
> (Nokia-NRC/Helsinki); [email-masked]; Niemi Aki (Nokia-M/Espoo)
> To answer this question, in RTP, the SSRC is used for identification. 
> The SSRC is mapped to a name through the RTCP SDES packets, 
> which come 
> every once in a while, and bind the SSRC to a CNAME. The 
> CNAME can also 
> be associated with supplementary data, such as the NAME 
> parameter, which 
> basically provides a nickname. Its described in RFC3500 thusly:
> 
> > 6.5.2 NAME: User Name SDES Item
> > 
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     NAME=2    |     length    | common name of source       ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >    This is the real name used to describe the source, e.g., 
> "John Doe,
> >    Bit Recycler".  It may be in any form desired by the user.  For
> >    applications such as conferencing, this form of name may 
> be the most
> >    desirable for display in participant lists, and 
> therefore might be
> >    sent most frequently of those items other than CNAME.  
> Profiles MAY
> >    establish such priorities.  The NAME value is expected to remain
> >    constant at least for the duration of a session.  It 
> SHOULD NOT be
> >    relied upon to be unique among all participants in the session.
> 
> 
> I see the IM nickname as being equivalent; an in-band 
> identifier of the 
> user name.
> 
> RTP defines the scope of these nicknames as bound to a 
> session, and does 
> not require uniqueness. Thats a bit different than what is being 
> proposed here.
> 
> Note that we have always had a problem with SSRC/CNAME that 
> there was no 
> easy way to map them to a SIP URI that could be used for 
> signaling. That 
> is, the CNAME is not necessarily the SIP URI that one would 
> want to use 
> to contact the user. For example, if I'm in a conference and 
> I want to 
> have a private call with a user, outside of the conference, 
> what SIP URI 
> to use?
> 
> I also agree with comments raised by Brian and others that 
> requirements 
> for management of nicknames - creation, deletion, and scope - are not 
> tied to IM. If we need that functionality, we should 
> introduce them as 
> requirements in the general conferencing work. Additionally, the 
> mechanism for this management should not be IM specific. Seems to me 
> like CPCP would be the ideal way to set them up. I believe 
> they would be 
> useful for general conferencing as has been pointed out. The 
> only thing 
> thats really IM specific is how such information is conveyed in the 
> message; usage of From in cpim seems reasonable to me.
> 
> One other thing in the draft that I would like to point out, is that 
> there is a feature that allows for private conversations. 
> This is done 
> by allowing a user to address an IM to one or more group 
> participants, 
> using To and CC CPIM fields. To me, this is also another conference 
> function that is not specific to IM. In fact, I dont see how 
> it differs 
> from sidebars.
> 
> Thanks,
> Jonathan R.
> 
> Paul Kyzivat wrote:
> 
> > Hmm. I was wondering about that too. I guess one 
> possibility would be to 
> > send the mapping from SSRC in RTCP. (I am not very 
> knowledgable about 
> > RTP, but I think RTCP carries a mapping from SSRC to text names.)
> > 
> > Another way would be for the SSRC to itself be considered a form of 
> > nickname and be published as part of the conference state. 
> (I guess that 
> > would require a facility for multiple nicknames per participant.)
> > 
> >     Paul
> > 
> > [email-masked] wrote:
> > 
> >> Just out of curiosity: how do you transport the display name (nick 
> >> name) for audio or video? In RTP? or does the recipient 
> have to have 
> >> local mapping between SSRCs and display names?
> >>
> >> /Hisham
> >>
> >>
> >>> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>> ext Paul Kyzivat
> >>> Sent: 23.February.2004 18:56
> >>> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> >>> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo)
> >>> [email-masked] wrote:
> >>>
> >>>> Thanks for your comments. See my comments inline.
> >>>>
> >>>>
> >>>>> From: ext Paul Kyzivat [mailto:[email-masked]]
> >>>>>
> >>>>> Its good to think about things like this. But I think the 
> >>>>
> >>>>
> >>> goal should
> >>>
> >>>>> not be to introduce special features for chat conferences. It 
> >>>>> should be to learn what features users of chat 
> conferences expect, 
> >>>>> and ensure that comparable features are available via our 
> >>>>> conference framework, and available with any media when 
> that makes 
> >>>>> sense. So I think some of these ideas need to flow back 
> into the 
> >>>>> conference framework.
> >>>>
> >>>>
> >>>> If we want to move things to the conference framework,
> >>>
> >>>
> >>> > then we need to develop a complete solution, based on
> >>> > requirements that... I dind't see so far. For instance,
> >>> > I believe all the requirements related to nicknames are
> >>> > addressing the session based conferences so far.
> >>> > We may want to extend those requriements, but there 
> aren't any now.
> >>>
> >>> I agree there aren't. I am suggesting that *where it makes sense* 
> >>> these should be advanced as requirements against conferences in 
> >>> general, rather than being focused as requirements only for chat 
> >>> conferences.
> >>>
> >>>
> >>>> Particularly, I don't know how useful is to use nicknames in
> >>>
> >>>
> >>> > an audio/video conference. The feature is useful in a conference
> >>> > of instance messages, but not so much in the other...
> >>> > Still, we may want to extend the conference package so that the
> >>> > user element can contain a <nickname> sub-element.
> >>> > This would allow a user to display the nickname of the 
> conferees,
> >>> > no matter what the media is.
> >>>
> >>> Exactly. This becomes interesting in multimedia conferences to.
> >>> For instance it becomes a tag to use in identifying 
> current speaker.
> >>>
> >>> It also may provide a better way to deal with anonymous 
> participants 
> >>> in all sorts of conferences, by giving them nicknames as 
> handles to 
> >>> reference them by.
> >>>
> >>> Then, instead of saying: "Will the anonymous participant with the 
> >>> deep voice please repeat his question?", you can say: 
> "Darth, will 
> >>> you please repeat your question?".
> >>>
> >>>
> >>>>> However it is relatively trivial to be more accomodating, 
> >>>>
> >>>>
> >>> adding and
> >>>
> >>>>> removing cpim wrappers according to the desires of the 
> individual 
> >>>>> endpoints.
> >>>>
> >>>>
> >>>> Basically, there are two ideas here: endpoints SHOULD use
> >>>
> >>>
> >>> > message/cpim when addressing a conference.
> >>> > The focus MUST use message/cpim. The idea is that the focus
> >>> > should indicate the nickname of the sender of the message,
> >>> > which is conveyed in the From header of the 
> message/cpim message.
> >>> > Endpoints SHOULD use messgae/cpim to relief the focus from
> >>> > wrapping messages when the focus distributes a copy.
> >>>
> >>> Sounds good to me.
> >>>
> >>>
> >>>>> Nickname management is problematic. It seems as though 
> >>>>
> >>>>
> >>> nicknames will
> >>>
> >>>>> need to be authenticated and authorized. But it isn't 
> at all clear 
> >>>>> that the focus is the right entity to do so. (The scope 
> is wrong.)
> >>>>
> >>>>
> >>>> I don't think a nickname has to be authorized. Users are 
> authorized,
> >>>
> >>>
> >>> > and once a user is authorized, she can choose any 
> available nickname.
> >>> > Is this what you meant?
> >>>
> >>>> Regarding the scope of the nicknames, I believe a 
> nickname should be
> >>>
> >>>
> >>> > unique within a conference server or an administrative domain.
> >>> > At least I don't see a valid requirement in getting nicknames
> >>> > valid across difrerent servers or different 
> administrative domains.
> >>>
> >>> I guess this depends on how large and long lived these scopes are.
> >>> It clearly isn't good if the scope is a single conference.
> >>>
> >>> It isn't good if it is a conference server either, if 
> that is just 
> >>> one of a large pool of independent servers that are 
> chosen at random 
> >>> as hosts for conferences.
> >>>
> >>> When the same group of users join in a number of 
> conferences over a 
> >>> period of time, within that scope a nickname should be bound to a 
> >>> user for as long as that user wants it to remain bound.
> >>>
> >>>
> >>>>> I think this would be better served by using real, 
> routable im: or 
> >>>>> sip: uris. As needed, service providers can exist to 
> host nicknames 
> >>>>> and forward requests addressed to them to other addresses.
> >>>>
> >>>>
> >>>> The point is that a nickname should not let you track 
> the real user.
> >>>
> >>>
> >>> > Only the conference server is able to map the real SIP 
> URI to the 
> >>> nickname,
> >>> > but not users. For instance, if user B receives an 
> instant message
> >>> > (through the conference server) from user A, B should 
> only see the
> >>> > nickname, unless A wants to disclose his real URI.
> >>>
> >>>> Making nicknames a real URI loose the semantics of the 
> "nickname".
> >>>
> >>>
> >>> > We don't want that behaviour, we want a nickname to 
> remain a nickname,
> >>> > something meaningless.
> >>>
> >>> That depends on how things are administered. There could be 
> >>> "nickname" servers, that are nothing but specialized 
> proxies. I would 
> >>> contract with one of these servers for whatever nicknames I want. 
> >>> These would be unique usernames within the domain managed by that 
> >>> server. Each would be configured to forward to an address of my 
> >>> choice. I would be given control to turn forwarding on and off 
> >>> selectively, so perhaps it would only work when I was 
> actively using 
> >>> a particular nickname in a conference.
> >>>
> >>> Then I could use the nickname as my address when joining a 
> >>> conference. I could permit the conference server to disclose this 
> >>> address, and yet my true identity would remain hidden.
> >>>
> >>> The advantage of this is that it decouples the administration of 
> >>> nickname namespaces from the administration of conference servers.
> >>>
> >>> But I am not necessarily opposed to coupling nickname 
> namespaces with 
> >>> conference administration *if* the scoping can be made reasonable.
> >>>
> >>>     Paul
> >>>
> >>>
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>