Subject: RE: [Simple] Chat sessions

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul Kyzivat
> Sent: 23.February.2004 18:56
> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo)
> Subject: Re: [Simple] Chat sessions
> 
> 
> 
> 
> 
> [email-masked] wrote:
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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?".
> 
> >>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.
> 
> Sounds good to me.
> 
> >>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 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.
> 
> >>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.
> 
> 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
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 11:19:14 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 11:19:14 -0500

Hisham,

	Paul