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: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Mon, 01 Mar 2004 09:57:49 +0200

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

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Mon, 01 Mar 2004 09:57:49 +0200

Brian,

Cheers,
Aki