Subject: RE: [Simple] Chat sessions

From: [email-masked]
Date: Sun, 29 Feb 2004 15:15:53 +0200

Hi all,

I think this thread has been a useful discussion on various topics related to conferencing, chat, anonymity, nicknames, display names, sidebars and private messages. Let me try to list my opinions on the different points:

1. "Nicknames" are not specific to MSRP conferences, but can be applied to any type of conferences. There should be more clarity how to convey them in conference-info and in various media transports. Initially RTP and MSRP seem to be enough.

2. There seem to be different scopes of "nicknames":
   a) A single conference instance: I believe the mechanism (or any other mechanism based on INVITE or SDP) proposed in the draft should only address this. Negotiation happens when setting up a session with the focus, and it is thus confusing if it had wider meaning.
   b) A set of conferences that are somehow federated (typically run by the same provider). In this case I believe the reservation of the nickname should be done with an out-of-band mechanism (I guess an XCAP usage similar to reserving list URIs would work), and somehow there should be a "realm" so that it would be possible to determine from a conference URI whether it belongs to the federation or not. If a user has a registered nickname within a realm, he probably still uses the mechanism in a) to announce it within a single conference in this realm. It is then upto the conference server to authorize the usage of the nickname.  
   c) Any SIP services. Again some sort of out-of-band reservation, and then sending each request through a B2BUA that translates the "real" identity to the "nickname". This could be actually used simultaneously with the conference specific systems, i.e. having a "nickname" for a "nickname". 

3. In each case there is a SIP-element that actually knows the "real" identity of the user. In cases 2a) and 2b) it is the conference focus, in 2c) it is the B2BUA. Only the nickname is shown beyond this element, as intended. 

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 think the current draft needs to be split into at least two:
- Private IMs in MSRP conferences
- Nicknames in conferences (I suppose the above one would have a dependency on this one)
  This should solve the scope of 2a)

There could be further (XCAP usage?) drafts describing the solutions to 2b) and 2c).

Regards,
	Markus     

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Feb 2004 11:23:56 -0500

Before I comment on this, as a meta-comment, I dont see any agenda time 
allocated in either simple or xcon to continue this discussion. Have I 
missed it?

inline.

[email-masked] wrote:

> Hi all,
> 
> I think this thread has been a useful discussion on various topics
> related to conferencing, chat, anonymity, nicknames, display names,
> sidebars and private messages. Let me try to list my opinions on the
> different points:
> 
> 1. "Nicknames" are not specific to MSRP conferences, but can be
> applied to any type of conferences. There should be more clarity how
> to convey them in conference-info and in various media transports.
> Initially RTP and MSRP seem to be enough.

Well, a valid question that Brian has raised is if these nicknames are 
scoped to media or a dialog. In other words, can I be "jdr" for audio 
and "J.Rosenberg" for IM? I dont see much value in that. So, if we can 
use the same nickname across the media, then what we are really talking 
about is the way that *I* wish to be identified for this dialog, and 
thats the From field.

After that, identifying the talker in a specific media type is just an 
issue of placing that identifier into the identity mechanism provided in 
that media; From header in MSRP, or CNAME for RTP.

> 
> 2. There seem to be different scopes of "nicknames": a) A single
> conference instance: I believe the mechanism (or any other mechanism
> based on INVITE or SDP) proposed in the draft should only address
> this. Negotiation happens when setting up a session with the focus,
> and it is thus confusing if it had wider meaning. b) A set of
> conferences that are somehow federated (typically run by the same
> provider). In this case I believe the reservation of the nickname
> should be done with an out-of-band mechanism (I guess an XCAP usage
> similar to reserving list URIs would work), and somehow there should
> be a "realm" so that it would be possible to determine from a
> conference URI whether it belongs to the federation or not. If a user
> has a registered nickname within a realm, he probably still uses the
> mechanism in a) to announce it within a single conference in this
> realm. It is then upto the conference server to authorize the usage
> of the nickname. c) Any SIP services. Again some sort of out-of-band
> reservation, and then sending each request through a B2BUA that
> translates the "real" identity to the "nickname". This could be
> actually used simultaneously with the conference specific systems,
> i.e. having a "nickname" for a "nickname".

I think we need to define which we want. I dont like "all three". I tend 
to think its (b).

If, for some reason, two users end up using the same display name, then 
the server can add a 1 or 2 or something to disambiguate them when it 
redistributes.

If you want server assigned names, then basically that conference server 
is my SIP provider, and it would provide me the URI that I would use in 
the From field. So, in that case, what is needed is a way to obtain URIs 
from the server dynamically. GRUU actually does that. I'm not sure thats 
the right answer here, but its an option.

> 
> 3. In each case there is a SIP-element that actually knows the "real"
> identity of the user. In cases 2a) and 2b) it is the conference
> focus, in 2c) it is the B2BUA. Only the nickname is shown beyond this
> element, as intended.
> 
> 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?

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?

-Jonathan R.
-- 
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Feb 2004 11:23:56 -0500

inline.

-Jonathan R.

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Sun, 29 Feb 2004 19:39:46 +0200

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.
> 
> 
>  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

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Sun, 29 Feb 2004 19:39:46 +0200

REFER (to sidebar)
200 OK

INVITE (to sidebar)
200 OK
ACK

MSRP SEND
MSRP OK

BYE
200 OK

MSRP SEND (private)
200 OK

Cheers,
Aki