Subject: RE: [Simple] Chat sessions

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.

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

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

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Tue, 02 Mar 2004 08:37:19 +0200

> another participant in a conference without consent.

In order to make this work, you'd have to design both the receiving UA 
and the sending UA. If one implements sidebars in the former way, and 
the other one the latter way, one of them (or both) will have bad user 
experience.

> see why that is different from a sidebar, or whisper.

And this is where we disagree.

<snip />

> You can use the same signaling for a sidebar or a whisper.

Hmm.. which systems are these? The ones I've used have both private 
messages *and* sidebars.

Cheers,
Aki

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Tue, 02 Mar 2004 08:37:19 +0200

<snip />

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 18:44:12 -0500

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

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: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 18:44:12 -0500

Paul

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 03 Mar 2004 02:36:55 +0200

ext Paul Kyzivat wrote:
<snip />
> senders that degree of control over recipients.

You could put it that way, yes. But this is dancing around the issue, 
which is that using sidebars alone to effect two different functions in 
a conference results in unpredicted user experience. Because REFERing 
another user to a sidebar is supposed to do both X and Y, but which one 
depends on the recipient's implementation.

That does not work. That's why IRC for example has a command for 
inviting someone to a sidebar channel

	INVITE user #sidebarchannel

*and* a command for sending a private message in a channel

	PRIVMSG user :This is a private message.

Of course this has UI implications, because these are separate 
functionality. This is the same thing as a MESSAGE having different user 
experience than an INVITE in SIP. A sender of a MESSAGE can certainly 
expect the recipient to behave differently than when it receives an 
INVITE. I thought this was basic protocol design!

Cheers,
Aki

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 03 Mar 2004 02:36:55 +0200

ext Paul Kyzivat wrote:
<snip />

Cheers,
Aki