Subject: RE: [Simple] Chat sessions

From: [email-masked]
Date: Sat, 21 Feb 2004 22:21:46 +0200

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.

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.

> 
> More specific comments:
> 
> -----------
> 
>     .... Each message needs
>     to carry in it an identifier of the sender of the message.
> 
>     This is accomplished using the 'message/cpim' MIME type, 
> as defined
>     in [7]. The conference focus MUST insist on using the 
> 'message/cpim'
>     as the top-level wrapper type in the SDP, as defined in [12].
> 
> I think this is a little harsh. But as long as cpim support is 
> *required* of msrp implementations I guess it is ok. All that 
> is needed 
> to enforce it is for the focus to refuse any other format for 
> containers.

As you said, we didn't introduce the requirement for cpim. So this shouldn't be an issue.

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

> 
> ---------
> 
>     If the message is a addressed to the whole conference, the To
>     header of the CPIM message contains the conference URI.
> 
> That works. But it would be convenient by default if messages 
> containing 
> no To are addressed to the conference as a whole.
> 
> 

Ok, I guess the effect is the same.

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

> 
> Then, a conference server would only need to authenticate 
> endpoints when 
> they are connected to the focus, and verify that the From field of an 
> incoming cpim message matches the known identity of the source.
> 
> The roster is then available via the conference event 
> package, or via CPCP.
> 
> (However there would be serious problems with federated foci.)
> 
> 	Paul
> 

/Miguel

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

---

From: [email-masked]
Date: Mon, 23 Feb 2004 12:27:51 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul Kyzivat
> Sent: 20.February.2004 21:59
> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo)
> Subject: Re: [Simple] Chat sessions
> 
> 
> 

A nickname is just that. I can assign myself any nickname in a chat room, as long as my identity is asserted (using whatever authentication mechanism).

/Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 23 Feb 2004 09:19:02 -0500

I think you confuse current implementations with actual requirements.
Its not uncommon in video conferences to display the name of the
participants
as a text string in the video.  Commonly, this is a "Display Name", similar
to that in an email address.

For reasons that have more to do with history, and somewhat with the
size of a dialog box in current IM systems, participants are labeled with
nicknames.

What is the real difference? 

I don't think there is much.  It might be preferable to distinguish a
"display name" (like "Brian Rosen") from a "nickname" (like "br 65535"),
with a participant providing both and a client making its own decision
which to use.  That would apply to all conferences.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, February 21, 2004 3:22 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Simple] Chat sessions
> 
> 
> 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.
> 
> 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.
> 
> > 
> > More specific comments:
> > 
> > -----------
> > 
> >     .... Each message needs
> 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.
> 
> > 
> > ---------
> > 
> 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.
> 
> > 
> 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.
> 
> 
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 23 Feb 2004 09:19:02 -0500

Brian

---

From: [email-masked]
Date: Tue, 24 Feb 2004 09:23:43 +0200

Hi Brian:

Yeap, a nickname is not much different than a Display Name. There is one small difference though: a nickname should be unique within the address space of the conference focus/mixer, whereas a display name is fully chosen by the end user and need not be unique.

On the other hand, what we are addresing in the draft is how to convey nicknames (read, display names) in the conference, sub conferences, private messages and alike.

MSRP does no offer the functionality, that's the reason we adopted the From, To, Cc headers in the message/cpim.

/Miguel

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: 23 February, 2004 16:19
> To: Garcia Miguel.An (Nokia-NRC/Helsinki); [email-masked]

---

From: [email-masked]
Date: Tue, 24 Feb 2004 09:23:43 +0200

Hi Brian:

/Miguel

---

From: [email-masked]
Date: Tue, 24 Feb 2004 10:52:48 +0200

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

> Sent: 23.February.2004 18:56
> [email-masked] wrote:
> > 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.
> 
>  > 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?".
> 
>  > 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.
> 
> > 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.
> 
> > 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
> 
>

---

From: [email-masked]
Date: Tue, 24 Feb 2004 10:52:24 +0200

I think we are mixing nickname with user ID (or usename). In a conference talking about beer, I would have a nickname of BeerLover. In a conference talking about MSRP, I would have a nickname MSRPLover. My user ID for both is [email-masked]. If I want to be anonymous, my user ID would be different.

I don't think this is the same as assigning aliases to user IDs. I believe this is what Paul is getting at. If you are talking about a nickname within an administrative domain or a conference server, then I believe it is the user ID that you are talking about, not a nickname.

/Hisham

---

From: [email-masked]
Date: Tue, 24 Feb 2004 12:46:56 +0200

Paul:

I mostly agree with your comments. Some minor tuning though.

> It clearly isn't good if the scope is a single conference.

Yeap, scopes is a non trivial issue. Basically, the requirement I had in my mind is that a user can freely move from one conference to another (all hosted by the same server) without loosing his nickname. 

> for as long as that user wants it to remain bound.

I guess this is a matter of local policy, some conference may extend the "nickname reservation" to a user for a period of time, others won't.

> nickname namespaces from the administration of conference servers.

Sounds good, but I guess the implementation would be a bit more complicated than our appoach. I don't see a big problem that the conference server does nickname administration, it is no a big overload.

/Miguel

---

From: [email-masked]
Date: Tue, 24 Feb 2004 12:51:13 +0200

> And then, do nicknames only apply to chat rooms? Or does every 
> conference act as a scope for nicknames.
> 

As I see it, nicknames could apply for conferences. A nickname should be unique within a conference server (as a minimum). It could be also unique within an administrative domain or confederation, or they could be also unique for some period of time.

/Miguel

---

From: [email-masked]
Date: Tue, 24 Feb 2004 12:51:13 +0200

/Miguel

---

From: [email-masked]
Date: Wed, 25 Feb 2004 09:13:16 +0200

Hi Paul:

In the draft we said that a nickname is the combination of the display name and the URI (invalid, allocated by the server) in the CPIM headers. The reason to add the URI into equation was to mitigate the clash of same display names of nickanmes in federated conferences.

This apprach allows to have two beerLover nicknames in the same conference, both sharing the same display name, but a different URIs (CPIM headers), e.g., [email-masked], [email-masked]

Still the URIs are scoped within the conference server, administrative domain, or confederation. And yes, managing of those nicknames in a multi-server environment is outside the scope of the document.

/Miguel

> Sent: 24 February, 2004 18:19
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); [email-masked]; Niemi Aki
> (Nokia-M/Espoo)
> Hisham,
> I don't think I agree with you. In the usage you describe, it 
> probably 
> would be ok for there to be multiple users calling themselves 
> "beerLover". But I believe what is being proposed here is a unique 
> identity within some scope. (The scope seems lack definition so far.)
> 
> My primary concern is to define the scope of names clearly. 
> My secondary 
> concern is to potentially separate the scope of these names from the 
> scope of the conference, or the conference server, itself. If 
> so, there 
> might be users with names from different scopes in the same 
> conference. 
> And in that case they start to look like URIs.
> 
> A case that now occurs to me is when two conferences are 
> federated, by 
> making one focus a participant in another conference. In that 
> case, if 
> nicknames are scoped by conference or conference server, and 
> the scope 
> is implicit rather than being passed around with each name, 
> then it will 
> not be possible to show nicknames for the users of a 
> federated conference.
> 
> 	Paul
> 
> [email-masked] wrote:
> > I think we are mixing nickname with user ID (or usename). 
> In a conference talking about beer, I would have a nickname 
> of BeerLover. In a conference talking about MSRP, I would 
> have a nickname MSRPLover. My user ID for both is 
> [email-masked]. If I want to be anonymous, my user ID would 
> be different.
> > 
> > I don't think this is the same as assigning aliases to user 
> IDs. I believe this is what Paul is getting at. If you are 
> talking about a nickname within an aokia-M/Espoo)
> > 
> >>>>Its good to think about things like this. But I think the 
> >>>
> >>goal should 
> >>
> >>>>However it is relatively trivial to be more accomodating, 
> >>>
> >>adding and 
> >>
> >>>>Nickname management is problematic. It seems as though 
> >>>
> >>nicknames will 
> >>
> authorized,
> real user.

---

From: [email-masked]
Date: Wed, 25 Feb 2004 09:13:16 +0200

Hi Paul:

/Miguel

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 25 Feb 2004 09:06:35 -0500

Generally, putting structure in text strings is a poor idea.  However, 
we have done that in an implementation here.

If you send From: "Brian (whoozitz) Rosen" <[email-masked]>, then 
"Brian Rosen" is a formal display name and "whoozitz" is a nickname.  
The UI can use the two forms of identity as appropriate.

I think that we should separate the concept of unique identity from human
readable names or nicknames.  The protocol mechanisms need the former,
the humans need the latter.  The URI is unique, and that is all we need
to make the protocol work.  Depending on a UI choice, you may need
display names, nicknames, or URIs.

Brian

> Sent: Wednesday, February 25, 2004 2:13 AM
> To: [email-masked]; [email-masked]
> In the draft we said that a nickname is the combination of 
> the display name and the URI (invalid, allocated by the 
> server) in the CPIM headers. The reason to add the URI into 
> equation was to mitigate the clash of same display names of 
> nickanmes in federated conferences.
> 
> This apprach allows to have two beerLover nicknames in the 
> same conference, both sharing the same display name, but a 
> different URIs (CPIM headers), e.g., [email-masked], 
> [email-masked]
> 
> Still the URIs are scoped within the conference server, 
> administrative domain, or confederation. And yes, managing of 
> those nicknames in a multi-server environment is outside the 
> scope of the document.
> 
> /Miguel
> 
> conference
> "nickname".

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 25 Feb 2004 09:06:35 -0500

Brian

---

From: [email-masked]
Date: Thu, 26 Feb 2004 08:50:12 +0200

Brian:

The only structure that the draft suggest is just a Display Name + a URI, something that is already existing in e-mail, SIP, and message/cpim. The new item is a convention that the Display in message/cpim is considered a nickname, the URI is not valid for routing purposes, but just for address space allocation.

I don't think this is a big deal.

/Miguel

> Sent: 25 February, 2004 16:07
> To: Garcia Miguel.An (Nokia-NRC/Helsinki); 
> [email-masked]; Khartabil
> Hisham (Nokia-TP-MSW/Helsinki)

---

From: [email-masked]
Date: Thu, 26 Feb 2004 08:50:12 +0200

Brian:

/Miguel

---

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
> > 
> >> 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
> >>>>> 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.
> >>>>
> >>>>
> >>> 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.
> >>>
> >>>
> >>> 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?".
> >>>
> >>>
> individual 
> >>>>> endpoints.
> >>>>> 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.)
> >>>>
> >>>>
> >>> 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.
> >>>
> >>> 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.
> >>>>
> >>>>
> >>> > We don't want that behaviour, we want a nickname to 
> remain a nickname,
> >>> > something meaningless.
> >>>
> >>> "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.
> >>>
> >>> conference. I could permit the conference server to disclose this 
> >>> address, and yet my true identity would remain hidden.
> >>>
> -- 
> 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: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Feb 2004 09:13:35 -0500

Miguel

I'm suggesting that there is need beyond IM for nicknames, and that perhaps
instead of inventing something just for IM, we do something more
generally applicable.  I'm also suggesting that even IM systems may want
to have a full display name, depending on their user interface.

Deciding that display name in message/cpim is a nickname is specific
to IM.

Brian

> Sent: Thursday, February 26, 2004 1:50 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> The only structure that the draft suggest is just a Display 
> Name + a URI, something that is already existing in e-mail, 
> SIP, and message/cpim. The new item is a convention that the 
> Display in message/cpim is considered a nickname, the URI is 
> not valid for routing purposes, but just for address space allocation.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Feb 2004 09:13:35 -0500

Miguel

Brian

---

From: [email-masked]
Date: Thu, 26 Feb 2004 16:20:58 +0200

Sure, sure... as we saw in another thread, we could extend the nickname support easily to RTP. We still need to define the means to transport the nickname in Instant Messages, and this is what this draft is trying to do.

/Miguel

> Sent: 26 February, 2004 16:14

---

From: "Andrew Allen" <[email-masked]>
Date: Thu, 26 Feb 2004 09:22:29 -0500

Brian

I agree. I know of at least one SIP application that is currently under development that is not IM that has a requirement for nicknames. In fact any conferencing type application may have such a requirement. Chat is just an instance of conferencing.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
European Mobile    +358 50 467 5870
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked]' <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
CC: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Feb 26 09:13:35 2004
Subject: RE: [Simple] Chat sessions

Miguel

Brian

---

From: [email-masked]
Date: Thu, 26 Feb 2004 16:20:58 +0200

/Miguel

---

From: "Andrew Allen" <[email-masked]>
Date: Thu, 26 Feb 2004 09:22:29 -0500

Brian

Andrew

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked]' <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
CC: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Feb 26 09:13:35 2004
Subject: RE: [Simple] Chat sessions

Miguel

Brian

---

From: "Spink, David" <[email-masked]>
Date: Thu, 26 Feb 2004 09:26:56 -0500

Brian is absolutely correct that IM systems may use full display names.  There is much interest among business and government in using Instant Messaging; many of whom will not want nicknames to be user-specified.  I think that there should be way to support both and that it should be independent of IM. 

David Spink  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Thursday, February 26, 2004 9:14 AM
To: [email-masked]'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Simple] Chat sessions

Miguel

Brian

---

From: "Spink, David" <[email-masked]>
Date: Thu, 26 Feb 2004 09:26:56 -0500

David Spink  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Thursday, February 26, 2004 9:14 AM
To: [email-masked]'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Simple] Chat sessions

Miguel

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Feb 2004 09:31:25 -0500

...snip
> If I understand correctly, the CNAME is similar to a display 
> name of a 
> To/From in message/cpim? We're not requiring display names to 
> be unique 
> either, but the URI part needs to be unique. In a voice 
> conference, you 
> won't direct RTP packets towards a particular CNAME, but in MSRP, you 
> need to be able to distinguish which "BeerLover" you want the private 
> message to go to.
This seems to be creating too much confusion.  You are requesting
anonymity, which is a concept we understand, and also asking for
a handle/nickname so that you can be identified as an individual,
without your identity.  I don't see what any SIP call should not
be afforded the same service.

...snip
> The functionality that we want is that a user is able to join the 
> conference using its asserted ID. But it wants to be seen in the 
> conference as someone else - lets call it a nickname - if the 
> conference 
> policy allows this. This other ID would be sent out in the 
> conference-info, and also in the message/cpim From field.
Again, any conference should have this capability, not just IM.
You might ask that any CALL have this capability; it's not clear to me
that most users/systems will accept anonymous calls, but for
normal identification purposes, a nickname rather than a display
name may be more appropriate.

> 
> Surely I can put my asserted ID + a display name in both of these 
> places, but that's really not a nickname with anonymity 
> anymore (even if 
> the ID is in fact an alias). In our draft, a nickname is really a 
> temporary ID that doesn't reveal any real-life ID. This is 
> made explicit 
> using the .invalud TLD. Every client will know the URI is useless 
> outside the conference.
I don't have a real problem with this aspect; it might be generalizable
beyond conferencing; consider a service that has a closed user group
where you will accept any calls that are authenticated as being within
the user group, but the actual caller is anonymous to you.  So the 
sender puts his actual identity in the call, which is sent to a B2BUA
that replaces that identity with an anonymous one, which is forwarded
to the destination.  Having a nickname may be useful.

> 
> And I think this is where the confusion lies - for clarity's sake, we 
> should probably denote a 'nickname' as an identity other than the ID 
> used to join a conference; a temporary nickname would be one that is 
> only valid inside a specific conference (uses the .invalid).
> 
> > useful for general conferencing as has been pointed out. 
> The only thing 
> I agree. It seems nicknames are generic enough to apply to all 
> conferences. I don't know if CPCP is the correct tool for 
> management of 
> nicknames. In fact, couln't this be set in the SDP at the time a 
> participant is joining a conference? Something like:
> 
> a=nickname:Darth Vader <im:[email-masked]>
> 
> or
> 
> a=nickname:Darth Vader <sip:[email-masked]>
> 
> This nickname would be used in conference-info instead of the 
> authenticated ID, used as CNAME in RTCP packets, or From/To in 
> message/CPIM, or even a display name in a video stream.
I'm not really thrilled with either CPCP or SDP, as it really is more
of a SIP header thing to me. CPCP means the mechanism is not
available to normal calls.  SDP doesn't have that problem,
but introduces another URI that I don't see as appropriate.

> > function that is not specific to IM. In fact, I dont see 
> how it differs 
> > from sidebars.
> 
> The main difference is as I see it, that to allow the same user 
> experience as that of private messages, one would have to by default 
> have a full mesh of one-to-one sidebars set up (plus the 
> combinatorics 
> involved when sending a private message to many).
I think the sidebar is established, one or more messages are sent,
and the sidebar is taken down.  To emulate current systems,
taking down the sidebar is probably a consequence of closing the
window, or just a timeout on one side.

> 
> I think private messages are a media feature, and it can actually be 
> easily combined with sidebars. I could imagine sending 
> private messages 
> within a conference sidebar as well...
I don't agree, you normally would be able to send an IM to all sidebar
participants.  If you want to send a message to a subset of the sidebar,
its the same as if you wanted to talk to a subset of the sidebar, which
is a sidebar in a sidebar.  Conceptually simple, although I'm not sure
we get that in the first release.

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2004 21:28:29 -0600

I agree with Jonathan's assessment of how this work should
proceed. Specifically, I want to reinforce the following
points:

 - Any nickname work should be done as part of a general
   conferencing solution, and should not be IM specific.

 - Sending of messages to a subset of users in a conference
   is *also* not IM specific, and will be addressed using
   media policy in XCON. It should not be defined using
   CPIM, since that will provide conflicting methods for
   providing this functionality.

Additionally, I feel *strongly* that specifying the use of
intentionally invalid URIs in the "From:" headers in CPIM
is a violation of the spirit of CPIM.

  "The URI indicates an address for the originator."

It would seem that creating intentionally invalid URIs
is counterindicated by the meaning of the word "address"
(in this context, a place where an entity may be reached
for the purposes of communication).

/a

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, February 25, 2004 13:11
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

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

---

From: [email-masked]
Date: Sun, 29 Feb 2004 18:02:47 +0200

Hi,

The intention of private messages is that 
a) sender does not need to know the valid addresses for the recipients beyond the scope of the conference
b) they are sent wihtin the context of the conference, which can thus also be visible in the UI
c) they can be sent without additional signaling to setup the list of recipients, i.e. the list needs to be conveyed inline of the message

My understanding of what sidebar is may be wrong, but I've thought there is some state associated with the sidebar, unlike in the above case. 

>From end-user's point of view private MSRP messages and private RTP communication may look the same, but from implementation point of view they are different. 

Markus  

> Sent: 29 February, 2004 06:59
> To: Niemi Aki (Nokia-M/Espoo)
> Cc: ext Adam Roach; [email-masked]
> Niemi Aki (Nokia-M/Espoo) wrote:
> > 
> \>
> > That's only if you think they provide the same 
> functionality. Read my 
> > previous post - I think sidebars are orthogonal to sending 
> a message to 
> > a subset of users in a conference (or in a conference 
> sidebar, same thing).
> 
> Certainly participants in a conference can try to note who 
> some of the 
> participants are and interact with them directly, and this is 
> orthogonal 
> with sidebars. But of course that only works if the participants 
> disclose addresses that can be used to communicate directly with them.
> 
> If you want the conference focus to act as a broker in establishing 
> communication between subsets of members of the conference, 
> so that it 
> can happen even when the participant identities are hidden, 
> then I think 
> you are very much into the realm of sidebars.
> 
> 	Paul
> 
>

---

From: [email-masked]
Date: Sun, 29 Feb 2004 18:02:47 +0200

Hi,

Markus