Subject: [Simple] Nickname scope

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Sun, 6 Jan 2008 11:12:44 +0100

I have seen three different scopes from the discussions on the list:
1. Chat room scope: [email-masked] or chat32.focus.example.org
2. Chat server or focus scope: focus.example.org
3. Domain: example.org

This tells me is that it is not the nickname that needs to be a URI, but
the scope of the nickname. 

What if we extended the conference package to include:
1. A nickname string
2. A nickname scope URI

We do not require the nickname string to be unique, but the combination
of the nickname and scope URI.

We could require the MSRP NICKNAME method to support scoping from the
start:
Set-Nickname: nicky [email-masked]
Set-Nickname: nicky focus.example.org
Set-Nickname: nicky example.org

If we still have to construct a SIP URI from the nickname string and the
nickname scope URI, multiple methods has been proposed on the list.

Geir Arne

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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 7 Jan 2008 15:47:05 +1100

I think the nickname string should be unique. If it is left to the
application to decide how to distiquish between identical nicknames,
then users will have trouble communicating. User1 to me is UserA to
you is User to someone else.

Also as I stated earlier, I think it should be unique per domain to
mimic chat rooms of today (you log into a chat service and create a
nickname, and then join chat rooms).

Hisham

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Mon, 7 Jan 2008 09:50:40 +0100

> From: Hisham Khartabil [mailto:[email-masked]]
> 

The current chat draft doesn't require the user part of the nickname URI
to be unique inside a conference, and no one has really proposes to
render the domain part of it to make it so.  That would probably violate
what most think of simple nicknames, and different rendering mechanisms
has been proposed - like nicky(1) and nicky(2).

What I propose is to extend the uniqueness to be at an URI level, and
not a domain level to include chat room scoping.  

Here is a simple use case: Alice and Bob have an MSRP session.  Alice
includes Carol, and Alice's SIP contact header changes to include the
isfocus feature-tag.  Now Alice is running a chat room, and she can
provision nicknames to be used in it.  The nicknames are scoped by
Alice's chat room URI, and not limited to her domain. She might not be
authorized to provision nicknames from her domain. If the participants
of her chat still want to have their nicknames scope at a domain level,
they still can.

This provides the possibility to have a nickname "president" of the
[email-masked], and a nickname "president" of the
[email-masked].  It doesn't stop [email-masked] or
[email-masked] to join the chat.  The UI still has to cope
having multiple presidents.

Thanks,
Geir Arne

---

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 8 Jan 2008 09:15:19 +1100

On 07/01/2008, Geir Arne Sandbakken <[email-masked]> wrote:
> render the domain part of it to make it so.

I am suggesting that it should be unique. I don't like the idea of 2
participants having the same nickname and leaving it to the
application to distinguish them for the user.

The domain can certainly help in making it unique, and the chatroom
service itself needs to make sure that they are unique.

>  That would probably violate

Do we want to standardise how the render is done by the application? I
think not.

> [email-masked].

Well, that's not how how I recall chat services work (it has been a
while though). There were a few people against what you just proposed
due to the fact that it will create confusion for people in both
chatrooms who just see "president" displayed.

Hisham

>  It doesn't stop [email-masked] or

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 8 Jan 2008 12:58:32 +0100

Comments inline.

> > [snip snip]

Think we agree here, but I want to extend the scope of uniqueness to be
inside the scope of an URI - and not only a domain.  The main reason for
this is to support simple ad-hoc chat sessions where one of the clients
acts as the server provisioning nicknames for the conference URI.
Requiring the client to have support for validating nicknames inside a
domain complicates the implementation of the server.

> Do we want to standardise how the render is done by the application? I

I'm not trying to standardize rendering, but refer to a suggested method
to avoid having to render a nickname like this:
[email-masked]

> [snip snip]

The plan was to always have scope associated to nicknames, and the UI
would have to relate to it.  Then there is no difference between a
domain scope and a room scope.  When there is scope - is there hope?  

Geir Arne

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 9 Jan 2008 12:59:12 +1100

As long as we have nickname uniqueness within a chatroom, I agree with
any mechanism you suggest to achieve that.

Thanks,
Hisham

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jan 2008 18:05:23 -0500

You seem to insist that the nickname HAS to be used to form an address.  We
don't need that to be true, and I argue that it makes more general use cases
harder for no advantage.  You have a URI and you have a nickname.  They are
distinct.  You use the URI for addressing.  You use the nickname for the UI.
There doesn't need to be ANY relationship other than they explicitly
represent the same user in the chat.

The URI is just a URI; it doesn't matter what the user part is.
The nickname is just a name.  It's not used for addressing.

Normally, your AoR is the address used.  If you want to be anonymous, you
can use an anonymous URI to join the chat, or the focus can give you a URI
to use.  It's up to it to make the URI unique.  That's all the client has to
know.  There is no need to create another URI for addressing using the
nickname.  That's just unneeded complexity.  If you allowed nick@domain as
an address, you ALSO have to allow an AoR as an address.  You can't restrict
addressing to nick@domain.  Therefore, allowing nick@domain makes everything
more complex.

We get confused when you try to force the nickname to be used as the user
part of a URI.  Just don't do that.

A nickname is a string.  It's used in a UI.  We can have rules in some forms
of nick use that have various uniqueness requirements if you want, but I
don't want to see a nick used as part of an address.  It's much closer to a
display name than a user part.

Brian

> -----Original Message-----
> From: Geir Arne Sandbakken [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2008 6:59 AM
> To: Hisham Khartabil
> Cc: [email-masked]
> Subject: RE: [Simple] Nickname scope
> 
> Comments inline.
> 
> > > [snip snip]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2008 19:27:12 -0500

I don't have any particular problem I can see with what you say, 
*except* that for a nickname to *be* unique we need to know who/what 
guarantees that uniqueness. IOW a nickname must have a scope and 
something that is responsible for that scope.

Either that scope is implicit, and up to the focus to determine, or else 
it is explicit. Having an implicit scope is IMO overly restrictive, but 
I know not all agree with me. I think what we had agreed is that for 
SIMPLE we will not provide any mechanism to request a new nickname in 
any but an implicit scope associated with the focus, nor would we 
specify how use of nicknames in other scopes would be authenticated, but 
we would *allow* nicknames in other scopes, if the focus has some way to 
authenticate that usage. The assumption was that the rest would be 
worked out by xcon.

But the end result of that is a need to identify a nickname and the 
scope in which the nickname is defined. I have been thinking of that 
being denoted by <nickname>@<scope>. Of course it need not be that way - 
there are other ways of conveying both pieces of info. And, aesthetics 
aside, that would be fine with me.

	Paul

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 15 Jan 2008 12:46:55 +0100

I thought I had explicitly argued against the nickname being a URI, and
that having such a nickname URI routable and changeable during the
conference will seriously break things.

What I do have argued for is that the nickname string used for display
purposes and easy reference to participants - needs to be associated to
a scope.  The purpose of the scope is to have the nickname string unique
inside of it.  IMHO the uniqueness aspect is what differentiates display
names and nicknames.  

The scope is currently proposed to be a URI, but the nickname string
itself is *not* part of it.  We have two pieces of information; the
nickname string and the nickname scope URI.  This allows for unique
nickname strings inside the scope of a conference URI (chatroom) like
[email-masked].  Having a nickname scope URI will also support
scoping inside of domains or IP addresses - whatever you can represent
as a URI. 

What we are constructing is something new.  It's not a display name, it
is not a SIP AOR, and not a routable SIP URI pretending to be a
nickname.  We have a nickname string which is unique inside a scope.

Geir Arne

> From: Brian Rosen [mailto:[email-masked]]
> 
> You seem to insist that the nickname HAS to be used to form an
address.
> We don't need that to be true, and I argue that it makes more general
use
> cases harder for no advantage.  You have a URI and you have a
nickname. 
> They are distinct.  You use the URI for addressing.  You use the
nickname > for the UI.
> to use.  It's up to it to make the URI unique.  That's all the client
has
> to
> don't want to see a nick used as part of an address.  It's much closer
to
> a

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jan 2008 13:55:00 -0500

Yeah, this is getting somewhat more confusing instead of less confusing to
me.

One of the purposes of a nickname asserted is linked with the notion of
anonymity.  If we allowed nick@domain, we have an anonymous URI.  There is a
problem here however; the conference event package would yield the real AoR
unless that was an anonymous URI.  So it would seem that using a nick for an
anonymous URI is not sufficient; the conference event package would have to
be changed or the URI in the roster would have to be an anonymous URI.  I
think the latter is the best answer.

There is a need to define the scope of uniqueness for a nickname.  We all
agree on that point.  The text of the draft suggests that since the nickname
is unique in the domain, nick@domain is unique, and proposes to make a URI
out of that.  I think this is too confusing, and we should just drop the
entire notion of creating a URI out of the nick; just use whatever is in the
conference roster.  

We're still left with defining the scope for which the nick is unique.  This
came up before.  The generalized mechanism makes the domain explicit, the
idea for MSRP chat was to make the domain something really simple.  The
simplest is the domain of the chat.  The largest it could be is the domain
of the server.  Remember that although it's possible that a chat uri is
[email-masked], it could also be [email-masked].  You can't use
the domain of the focus as the domain of the chat.  The simplest mechanism
to define for MSRP chat is that the nick is unique within the domain of the
conference (chat) URI.  That would be the conference for the former example,
and the server for the latter example.  If that bothers you too much,
uniqueness to the chat itself is fine with me.

So a concrete proposal:
1. Delete all references to creating a URI from a nickname. Just use the URI
in the roster.
2. Define the scope of uniqueness for MSRP chat to be at least the chat
itself, with the possibility that the chat server can permit a more
stringent (e.g. uniqueness to the domain of the chat URI) if it wants to.
The clients can't assume anything beyond uniqueness to a chat.

Brian

> Sent: Tuesday, January 15, 2008 6:47 AM
> To: Brian Rosen; Hisham Khartabil
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2008 16:26:05 -0500

Brian,

My concern is that what is done for simple be upward compatible with 
what is done for xcon. Simple may restrict the domain of uniqueness of 
the nickname to whatever scope the focus wants it to be. That won't 
result in any ambiguity as long as the conference really operates under 
the simple rules.

But xcon will hopefully allow nicknames defined in different scopes. 
Thus there could be two users in an xcon conference with nicknames that 
are the same except for being defined in different scopes. How will that 
be rendered to a user that only understands the simple rules? It will 
simply see two users with the same nickname.

To avoid that eventuality I think simple rules must recognize that 
nicknames have a scope, even if you can't request a particularly scoped 
nickname. And the UIs must be prepared to do something sensible in that 
case.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jan 2008 18:30:02 -0500

The problem isn't recognizing scope, the problem is the UI when the nick is
the same, but the scope (domain) is different.  Then UI has to do something
special.  In my proposal, there is no URI problem; there is only a UI
problem.

If we force MSRP chat to deal with multiple nicks, with or without explicit
scope, then we fix the problem in the beginning.  I like that, but we had a
lot of push back on that idea.

If MSRP chat clients don't have to do that from the get-go, then I see a
couple of alternatives:
1. The server, when it supports the generalized mechanism, can provide a
unique nick "fred(2)" when it supplies the roster to the simple client.
2. The server can determine if all parties support the generalized
mechanism, and only allow duplicate nicknames if they all can handle it.

The former seems to work, the latter probably doesn't because if the order
of appearance in the chat was:
Smart Client, nick=fred
Smart Client, nick=fred
Simple Client, nick=george

Then the server would initially allow fred to be duplicated, but would have
to rescind the permission when the dumb client showed up.

Neither solution requires scope to be declared for the simple client.  I
don't see how making scope explicit now helps the problem.  We can have
scope be implicitly the domain of the server (e.g. the domain of the
conference URI).  It could, by policy, further restrict to scope of the
chat.  That may help the generalized mechanism a little (default domain when
none is supplied). It doesn't seem to help the simple client.  Either it can
handle the UI for duplicate nicks now or it can't ever.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2008 4:26 PM
> To: Brian Rosen
> Cc: 'Geir Arne Sandbakken'; 'Hisham Khartabil'; [email-masked]
> Subject: Re: [Simple] Nickname scope
> 
> Brian,
>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 16 Jan 2008 11:28:14 +1100

I like Brain's suggestions in his previous email and 1. below. The
issue I see for 1. would be the acceptance of vendors to implement
SIMPLE specific handling. If we can generalise this, then I think we
are set.

Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2008 19:35:04 -0500

Brian Rosen wrote:
> the same, but the scope (domain) is different. 

Right.

> Then UI has to do something

I like it too. There needs to be a final decision on that.

> mechanism, and only allow duplicate nicknames if they all can handle it.

Yep, I agree.

> The former seems to work,

Yes, that had occurred to me as well. It is a way out.

> the latter probably doesn't because if the order

Yes. We had this discussion once before and that came up. It is unworkable.

> to rescind the permission when the dumb client showed up.

Rescinding is unworkable IMO.

> don't see how making scope explicit now helps the problem. 

Making the scope explicit means the problem of disambiguating 
semi-duplicate nicknames is left to the clients, who can then do it in a 
way that suits them.

Leaving it to the server means that *it* determines how a duplicate 
nickname is modified to disambiguate it. Some may like that, some may 
not. It has the potential to be confusing if I refer to my own nickname 
explicitly and others see me as having a variant of it.

> We can have

In the interest of making progress perhaps it is ok to assume your 
alternative 1. I think this means that for simple chat participants it 
will have to modify nicknames from other domains so that they are 
distinct from any nickname in its own domain that could possibly join 
the conference. How it does that is its business. It can affix "(n)" 
where the (n) identifies another domain, or it can affix "@<domain>", or 
whatever it wants to do.

	Paul

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 16 Jan 2008 12:00:53 +0100

Brian,

> [snip snip]
> So a concrete proposal:
> 1. Delete all references to creating a URI from a nickname. Just use
the
> URI in the roster.

I have done this for the upcoming version of the draft. The Nickname
itself is just a string, and there are no rules for making a routable
address from it.  

> The clients can't assume anything beyond uniqueness to a chat.

Currently the upcoming draft has the nickname scope called "Nickname
Scope URI" (lack of a better wording) - and it's a URI that can be the
chat URI itself.  Requiring a scope from the start will force the
clients to cope with equal nickname strings.

The reasons for not limiting the uniqueness to the domain of the chat
URI is to cope with having multiple chat rooms (conference instances) in
the same domain.  This would disallow users to have the same nickname
string in different chat rooms, and you can not easily select a unique
nickname in a chat room based on feedback the user gets from the
conference package.

Geir Arne

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 16 Jan 2008 14:25:58 +0100

> semi-duplicate nicknames is left to the clients, who can then do it in
a

Unfortunately relying on the clients to do the disambiguating will lead
to problems.  Often nicknames are referred to inside the chat itself,
and if two clients rendered the nickname differently they would be
referred to differently.  The chat could become a bit chaotic.

Geir Arne

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2008 08:58:33 -0500

> referred to differently.  The chat could become a bit chaotic.

Did you note that I bought into Brian's suggestion that the focus be 
responsible for the disambiguation of the conflicting nicknames?

But that does still present a problem, because the participant won't 
know if his own nickname has been modified to make it unambiguous.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 09:12:13 -0500

Hmmm, if clients have to deal with two nicknames that are the same, with
different scope, then there is no UI problem; all clients have to do that
themselves.

We also have to think about the generalized mechanism.  There too we must
have explicit scope.  Is everyone comfortable that the scope is a URI and
not a domain?

So for the generalized mechanism we might propose a new header:

INVITE [email-masked] 
To: [email-masked]
From: [email-masked]
Nickname: "Ronnie", "[email-masked]"

Which means that the UAC is asserting that it has been assigned the nickname
Ronnie for its AoR [email-masked] verifiable by an entity at
[email-masked].

Brian

> Sent: Wednesday, January 16, 2008 6:01 AM

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 16 Jan 2008 15:17:22 +0100

Comments inline.

> >> semi-duplicate nicknames is left to the clients, who can then do it
in
> responsible for the disambiguation of the conflicting nicknames?

Yes, but there is a catch doing this.  Having the simple client view the
nicknames differently than the smart client - would lead to the exact
same problem as having the clients do the disambiguating themselves.

> know if his own nickname has been modified to make it unambiguous.

I guess it could be returned in a 200 response to the NICKNAME method,
but I'm not sure I like that.

Geir Arne

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 16 Jan 2008 15:49:25 +0100

Comments inline.

> have explicit scope.  Is everyone comfortable that the scope is a URI
and

Realizing that scope would always have to be rendered in the UI to avoid
misunderstandings for references inside the chat itself - it's very
debatable.  

A quick optimization could be that if the scope URI is the same as the
conference URI, the client might skip rendering it.  Then only the
generalized nicknames would have its scope rendered - which actually
could make sense. 

> Which means that the UAC is asserting that it has been assigned the
> nickname Ronnie for its AoR [email-masked] verifiable 
> by an entity at [email-masked].

I like this. 

Geir Arne

> > > stringent (e.g. uniqueness to the domain of the chat URI) if it
wants
> > to.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2008 12:41:52 -0500

> generalized nicknames would have its scope rendered - which actually

Leaving the decision about how to render this to the UA is not bad IMO, 
as long as we make it clear that the UA must do it.

There are many ways it might be done, and we need not decide. The UA 
could render the first usage of the nickname that it observes with the 
actual nickname. And then when it sees a differently scoped version of 
the same nickname it could present it suffixed with "(2)" or "@domain" 
if the scope is just a domain, or it could present each different one in 
a new color, or ...

>> by an entity at [email-masked].

Yeah, I like it too. (Now if we just had a verifier protocol to go with it.)

	Paul