Subject: RE: [Simple] Chat sessions

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

Paul:

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

> From: ext Paul Kyzivat [mailto:[email-masked]]
> 
> [email-masked] wrote:
> > 
> >>From: ext Paul Kyzivat [mailto:[email-masked]]
> >>
> > 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.

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. 

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

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

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.

> But I am not necessarily opposed to coupling nickname namespaces with 
> conference administration *if* the scoping can be made reasonable.
> 
> 	Paul
> 

/Miguel

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

---

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

Miguel - comments inline.

	Paul

> 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 ni…

This might work, but it troubles me somewhat. For conferences in general 
it isn't important to participants where the conference is hosted. But 
if nicknames are bound to a conference server then all of a sudden this 
becomes important.

Also, as I noted in an earlier reply, this causes trouble if you try to 
federate conferences that are hosted on different servers. Then the 
nicknames they use are drawn from different namespaces.

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

Certainly the detailed management of name assignments and their duration 
is a local policy issue. But it is going to be very confusing to use if 
nickname assignments aren't fairly stable. It would be really bad if you 
were BeerLover for the chat session associated with one simple wg 
meeting, and I took the BeerLover nickname for the chat session 
associated with the simple wg meeting the next day.

> 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 overl…

Yes, it would be slightly more complex to administer. But with the 
benefit that I can then be [email-masked] in any conference I want, 
regardless of who sets it up. It also means that conference servers 
don't need to manage nicknames at all.

This is really just a sort of a sip anonymizer.

>>conference administration *if* the scoping can be made reasonable.

I am going to take back the above statement. the conference federation 
issue suggests that the scoping *can't* be made reasonable.

Conceivably a conference server could also provide special purpose sip 
aliases for people who want them for its conferences. These would be 
just like the kind I am talking about, but would be managed by the 
conference server and would only function when the user was in one of 
its conferences.

	Paul

---

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

Paul

	Paul