Re: [Simple] Chat sessions

["Niemi Aki (Nokia-M/Espoo)" <aki.niemi at nokia.com>]

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
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple