Subject: [Simple] MSRP chat: SIP-based nickname negotiation

From: Miguel Garcia <[email-masked]>
Date: Tue, 08 May 2007 13:54:02 +0300

Hi:

We are trying to seek consensus and a bit more of discussion about the 
MSRP chat, to be precise, about the nickname capability, which is the 
most contentious issue so far. We don't discuss in this e-mail other 
issues, just nicknames.

According to the minutes of the meeting in Prague, we understood that we 
should be seeking a nickname negotiation mechanism outside MSRP. For 
example, SIP. For what I recall from conversations years ago, the 
mechanism should be also applicable to regular sessions, not only those 
that contain MSRP or not only conferences.

So, based on that, we would like to get comments on the following proposal:

- Model the nickname capability in SIP as a option tag in 
Supported/Require headers
	* Whether to have Require in outgoing INVITEs is open

- New header field "Set-Nickname" or something is added to the INVITE 
request.

- Value of the Set-Nickname header field:
Option 1) Either the header takes a single token value
	* URN scheme that embeds this token, and later goes into CPIM TO/From
	* Other option (maybe better) is to still use a naming
convention and SIP URIs.

Option 2) Another option is to have UA insert a Display-Name and SIP URI
         * The SIP URI represents the nickname and it is scoped to the 
chatroom or domain
	* The Display-Name is used for rendering purposes.
	* This is what the current draft says

- We create a new error response code 4xx: Nickname Not Accepted
	* Optional Proposed-Nicknames header field proposing alternatives

And before Keith jumps above me indicating that this work should be done 
in the SIP working group, yes, we are aware of RFC 3427, and this work, 
if agreed in SIMPLE, should move to SIP as some point in time. But let's 
see if SIMPLE agrees first.

BR,

       Miguel
-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Helsinki, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 May 2007 09:24:12 -0400

Miguel,

IMO the most straightforward way to handle nicknames is to treat them as 
a form of anonymization, provided by an anonymizer. Namely, you 
establish a nickname server, which is a form of B2BUA. You establish an 
account with it that defines a mapping between your actual AOR and the 
nickname you want to be known by, drawn from the address space of the 
server. Then you relay your request for the chat room (or whatever) 
through this server.

This can be a server entirely independent of the chat room. But it would 
also be fine for the provider of a chat room server to couple a nickname 
service with it, perhaps coupling the mapping of real name to nickname 
to the lifetime of a particular chat room.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 08 May 2007 16:35:06 +0300

Aren't you assuming that if a user is willing to use nicknames at the 
same time wants to remain anonymous from his SIP URI?

I thought these are two independent issues. I may want to reveal or hide 
my SIP URI, and I may want to reveal or hide my nickname.

/Miguel

Paul Kyzivat wrote:
>> According to the minutes of the meeting in Prague, we understood that 
>> we should be seeking a nickname negotiation mechanism outside MSRP. 
>> For example, SIP. For what I recall from conversations years ago, the 
>> mechanism should be also applicable to regular sessions, not only 
>> those that contain MSRP or not only conferences.
>>
>> And before Keith jumps above me indicating that this work should be 
>> done in the SIP working group, yes, we are aware of RFC 3427, and this 
>> work, if agreed in SIMPLE, should move to SIP as some point in time. 
>> But let's see if SIMPLE agrees first.
>>
>> BR,
>>
>>       Miguel

---

From: Aki Niemi <[email-masked]>
Date: Tue, 08 May 2007 16:54:15 +0300

> to the lifetime of a particular chat room.

This sort of thing is a very valid model, but I don't think we want to
require this to be the *only* way to acquire or use nicknames.

In fact, many IRC services out there offer a way for a user to grab hold
of a nickname permanently or semi-permanently. For example, one popular
service I know of has a policy where the nicks can be registered (via
web/email) and either get released by admin intervention or by being
inactive for a certain amount of days/months. The service still allows
people to connect and create nicks on the fly as well.

And the way you would prove you "own" a nick is by providing a password
along with the NICK command. This is definitely along the lines we were
thinking simple-chats would work as well, namely that the MSRP NICKNAME
method (or the equivalent SIP mechanism) would get challenged for Digest
authentication.

I think it is very important for us to define something that is easy to
implement and deploy without restricting more elaborate models being
deployed.

Cheers,
Aki

-- 
Aki Niemi

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 May 2007 11:34:14 -0400

> my SIP URI, and I may want to reveal or hide my nickname.

I guess the question is how many distinct models and mechanisms it makes 
sense to standardize.

We already have Display Name as an uncontrolled way to provide an alias 
for yourself in addition to your actual URI. If you are willing to 
expose your actual URI, and there is no requirement for uniqueness of 
nickname, then this is enough.

If you really want your identity hidden and only your nickname to be 
exposed, then the nickname must be unique and routable. What I have 
suggested satisfies that, and works for any conference server, in fact 
for any call.

Is some mechanism between those two extremes worth the trouble, 
especially if it is limited to chat conferences based on MSRP? I may 
well participate in regular voice conferences using a conference server 
that provides access to a roster. I think I would want nicknames for 
that too. Do we provide another unique mechanism for that environment?

	Paul

> /Miguel
> 
> Paul Kyzivat wrote:
>> Miguel,
>>
>> IMO the most straightforward way to handle nicknames is to treat them 
>> as a form of anonymization, provided by an anonymizer. Namely, you 
>> establish a nickname server, which is a form of B2BUA. You establish 
>> an account with it that defines a mapping between your actual AOR and 
>> the nickname you want to be known by, drawn from the address space of 
>> the server. Then you relay your request for the chat room (or 
>> whatever) through this server.
>>
>> This can be a server entirely independent of the chat room. But it 
>> would also be fine for the provider of a chat room server to couple a 
>> nickname service with it, perhaps coupling the mapping of real name to 
>> nickname to the lifetime of a particular chat room.
>>
>>     Paul
>>
>> Miguel Garcia wrote:
>>> Hi:
>>>
>>> We are trying to seek consensus and a bit more of discussion about 
>>> the MSRP chat, to be precise, about the nickname capability, which is 
>>> the most contentious issue so far. We don't discuss in this e-mail 
>>> other issues, just nicknames.
>>>
>>> done in the SIP working group, yes, we are aware of RFC 3427, and 
>>> this work, if agreed in SIMPLE, should move to SIP as some point in 
>>> time. But let's see if SIMPLE agrees first.
>>>
>>> BR,
>>>
>>>       Miguel
>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 May 2007 09:36:47 +0300

Inline discussion

Paul Kyzivat wrote:
>> I thought these are two independent issues. I may want to reveal or 
>> hide my SIP URI, and I may want to reveal or hide my nickname.
> 

Well, this is the heart of the problem. The nickname has to be unique at 
least within a conference, otherwise I would find the same nickname 
repeated a number of times. I wouldn't be able to identify which one is 
the "beer lover" I was chatting a few minutes ago.

On the other hand, this is how most (if not all) the chat servers work 
today. The nickname is unique within the chat room. This requires a 
centralized repository for the nickname and a reservation mechanism, 
that is what we are trying to achieve.

Since we want to use nicknames for routing private messages via the chat 
server, then we concluded that the nickname has a display-name (what the 
user sees in his display) and a URI (what the protocol uses for 
routing). Whether one is derived from the other via some rules, or there 
is a composition, then it is up to discussion. We are not there yet.

> suggested satisfies that, and works for any conference server, in fact 

Yes. But I also want this other scenario where the user discloses his 
real identity in addition to his nickname. I don't think what you 
proposed satisfies that requirement.

> especially if it is limited to chat conferences based on MSRP? 

I think I heard people saying that what we do with nicknames should be 
generally applicable to non-MSRP conferences as well, although certainly 
the use case is MSRP.

> I may 

No, no. The mechanism that we have been suggesting, at the SIP level, 
will take care of reserving and negotiating a nickname for your non-MSRP 
conference as well.

With respect the roaster. The current version of the draft suggests to 
extend the conference event package with a new <nickname> element. It 
didn't do a formal description, it is more like a place holder for 
future work.

/Miguel

>>> nickname service with it, perhaps coupling the mapping of real name 
>>> to nickname to the lifetime of a particular chat room.
>>>
>>>     Paul
>>>
>>> Miguel Garcia wrote:
>>>> Hi:
>>>>
>>>> the MSRP chat, to be precise, about the nickname capability, which 
>>>> is the most contentious issue so far. We don't discuss in this 
>>>> e-mail other issues, just nicknames.
>>>>
>>>> According to the minutes of the meeting in Prague, we understood 
>>>> that we should be seeking a nickname negotiation mechanism outside 
>>>> MSRP. For example, SIP. For what I recall from conversations years 
>>>> ago, the mechanism should be also applicable to regular sessions, 
>>>> not only those that contain MSRP or not only conferences.
>>>>
>>>> - New header field "Set-Nickname" or something is added to the 
>>>> INVITE request.
>>>>
>>>>         * The SIP URI represents the nickname and it is scoped to 
>>>> the chatroom or domain

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 9 May 2007 17:32:34 +1000

> proposed satisfies that requirement.

what's wrong with a From-header plus P-Preferred-Identity (some similar) header?

Hisham

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 May 2007 10:39:06 +0300

> what's wrong with a From-header plus P-Preferred-Identity (some similar) 

The P-Preferred-Identity/P-Asserted-Identity combination do not work
in the Internet at large due to lack of trust. So, in general, it is
not available.

On the other hand, I wouldn't like to hijack an existing header with 
existing semantics for adding a nickname. I think the results are mostly 
unpredictable in existing software.

/Miguel

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 9 May 2007 17:48:20 +1000

I was suggesting something similar to the p-preferred-identity header.
i.e. a header that carries a name that the user prefers.

Hisham

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 May 2007 10:52:58 +0300

So you mean something like the header where the user will indicate his 
preferred nickname? Well, yes, this is what the proposal says:

/Miguel

Hisham Khartabil wrote:
>> > what's wrong with a From-header plus P-Preferred-Identity (some 
>> similar)
>> > header?
>> >
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2007 07:53:59 -0400

I was thinking of something similar to what Hisham is suggesting, but it 
is different from what you are suggesting Miguel. In particular:

If I want to be known by a nickname within the conference, then I use an 
anonymizer to source my session with the identity of a nickname - as I 
first suggested.

If I also want to disclose my *actual* URI to participants of the 
conference, then I just include that in my request in some subordinate 
role/header. E.g. Reply-To.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 10 May 2007 10:11:03 +0300

Hi:

It has never been the purpose of this work to create a general mechanism 
for providing anonymity through nicknames. Rather than that, the goal is 
provide a mechanism that is compatible with existing chat rooms that 
implement other protocols, namely jabber/XMPP, perhaps IRC. The more we 
diverge from the current model, the more difficulties we will find.

This is imposing us some constraints that we can't forget. One of them 
is that the nickname provider is an inherent part of the chat room. You 
can model it as a co-located anonymizer with the chat room. So we are 
not going to model a separate entity, that will bring other questions.

Another constraint is that the nickname is a separate additional 
identity that resolves to the chat server. A UA that does not understand 
nicknames, should be able to operate without that notion. In particular, 
if we stick a nickname in a From header, we are overloading the meaning 
of it. There might be User Agents that allow, for example, to save in a 
Contacts application the URI listed in a From header. If that content is 
a temporarily scoped URI, then we will be braking the compatibility with 
existing UAs.

Now, I have been listening to many opinions on how to do things in 
different ways, generalize, and so on. But we need to keep focused on 
solving our particular problem, if we ever want to see MSRP chat 
deployed. And to do it, we have to provide protocol compatibility with 
existing deployments. So, I would appreciate if we can focus on the 
problems of the proposal that we sent earlier for our specific 
application, rather than providing alternatives.

/Miguel

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 May 2007 02:42:21 -0400

I think that at root, the problem is that we don't agree on requirements.
Perhaps we should start there, rather than discussing a particular proposed
solution.  I don't think it will take long to agree on requirements.

So far, I have heard:
It must be possible for a user to request a particular nickname
It must be possible for a service (conference server or domain) to require
uniqueness of nicknames within the conferenece/domain)
It should be possible for a nickname to be retained by a user for a long
time
It must be possible for a user to reveal their nickname, but not require
revealing an AoR
	Is it a requirement that the nickname "service" do this, or is it 
	Acceptable to get an anonymous AoR and associate a nickname with
that,
	making these two services independent of one another?  I think it
is.
Nicknames are not display names, are not user parts of AoR, and are not
other identities (i.e. P-Preferred-Identity); they are something new.  Of
course, nicks may be the same character sequence as one of the above if the
domain, or the user, wants them to be.

PERHAPS I have heard:
A nickname is an ADDITIONAL identity; not equivalent to an AoR.  A nickname
is bound to an AoR and used for display purposes, not addressing purposes

A nickname service may be separate or may be bound to a conference
server/domaim

--by domain, I mean the domain of an AoR: AOL maintains a domain of screen
names that are persistent and used in all chat rooms and IM conversations.
We need to maintain this style of nicknames as well as the temporary, join
the chat, pick a nick style.

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]]
> Sent: Thursday, May 10, 2007 3:11 AM
> To: Paul Kyzivat
> Cc: Niemi Aki Petteri; SIMPLE mailing list
> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation
> 
> Hi:
>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 14 May 2007 11:02:04 +0300

Hi Brian:

Perhaps you went to the heart of the problem... Anyway, I want to remind 
you that we wrote a requirements draft about two years ago... At that 
time, submitted to the XCON WG. This is the draft I am referring to:

http://tools.ietf.org/id/draft-garcia-xcon-private-messaging-reqs-01.txt

I guess this draft captures most of the requirements, if not all. 
Perhaps we have more information today, and we can clarify some of the 
requirements.

Now, some inline comments on your proposed requirements.

> It must be possible for a user to request a particular nickname

I agree.

> uniqueness of nicknames within the conferenece/domain)

I agree.

> It should be possible for a nickname to be retained by a user for a long

I agree, although the actual mechanism is not within the scope of the draft.

> It must be possible for a user to reveal their nickname, but not require

I want to clarify the requirement. There are two parties that can get 
the AoR: the conference server and participants.

The requirement is to make possible for a user to reveal their nickname 
to participants but not reveal their AoR to participants.

I don't think we have a requirement towards the conference server.

> domain, or the user, wants them to be.

Correct, perhaps clarifying that "Nicknames are not included in existing 
display names", because a nickname obviously is (or contains) a display 
name, which is not to override existing display names.

> is bound to an AoR and used for display purposes, not addressing purposes

More or less... I agree with everything, but not with the "not 
addressing purposes". Nicknames are used for addressing purposes when 
users send private messages.

So, perhaps two clarifications
- Nicknames do now a allow end-to-end addressing between users.
- Nicknames allow a user to address another one via the conference server

> A nickname service may be separate or may be bound to a conference

I think the "seperate" creates a bunch of problems. I think anyone is 
willing to deploy a generic nickname service. Here, we should focus on 
solving a real problem, and our real problem is that there are 
conference servers that provide nickname services. So, we should 
consider that, for the time being, we assume the nickname service to be 
a part of a conference service.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 May 2007 08:04:14 -0400

Brian,

Thanks. You make a good observation. And I agree with most of your 
points. Minor comments below.

	Paul

> 	making these two services independent of one another?  I think it

IMO it probably *should* be acceptable for these to be independent 
services. What I think is not clear is if/why it should be a requirement 
for these services to be combined.  I think I hear an assertion that it 
must be possible for them to be combined because some existing chat 
conference facilities do it that way. I don't know why that is pertinent 
unless it is for the building of gateways. But even then I think the 
requirement is for the building of gateways, because perhaps that would 
be possible without the full requirement.

> the chat, pick a nick style.

This seems to be a real requirement. I question if the converse is 
really a requirement - that nicknames per-conference when there are 
multiple conferences in the domain - is actually a requirement. I don't 
recall seeing any practical cases where that is true. Even if it is, it 
seems ill advised as it can be very deceptive.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 May 2007 08:14:59 -0400

I mostly replied earlier. Minor comments below.

	Paul

> name, which is not to override existing display names.

Is there really a requirement that a participant in a conference be able 
to have *two* nicknames - one for the AOR and one for the nickname? I 
question this.

> - Nicknames allow a user to address another one via the conference server

I think these requirements could stand to have some further 
clarification about what the intent is.

Is the goal to restrict when private messages may be sent? Or to 
guarantee that the conference server *mediates* all messages sent 
between participants? Or both?

I would distinguish between how this is implemented by existing servers, 
which may simply be just the best they could manage, and what the actual 
intent is.

> willing to deploy a generic nickname service.

I presume you mean "anyone is *free* to deploy a generic nickname service."

While that is true, it won't matter if a conference server doesn't 
permit users who are using such a service. In particular, it won't 
matter if the conference service only permits users whose AOR is hosted 
by a particular domain. AFAIK that is currently the situation for major 
providers such as AOL. So then the question is whether we are trying to 
address those kinds of service providers.

> Here, we should focus on

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 15 May 2007 15:07:29 +0300

Hi Paul:

Some inline comments.

> to have *two* nicknames - one for the AOR and one for the nickname? I 

I didn't understand your question, you spoke about two nicknames: one 
for the AoR and one for the nickname... Doesn't it go in circles?

As far as I know, the requirement is to have a nickname. One nickname.

> between participants? Or both?

There is no requirement to restrict when private messages are sent. 
There is a requirement that the conference server acts as an anonymizer 
to avoid end-to-end knowledge of identities. The solution is to place 
the conference server as a router of messages based on nicknames, so the 
second option you mentioned.

> address those kinds of service providers.

I think you are speaking about identities (AoR), in particular to 
asserted identities derived through direct authentication. It is true 
that some conference services have a policy that requires participants 
to have an identity provided by the conference server network, due to 
technical or policy reasons. I would say that we don't care about that, 
because this is related to AoRs, and the draft does not discuss that issue.

When we move the discussion to nicknames, we have the unique nickname 
requirement (at least within a conference), and the mechanism to 
represent nicknames for private messaging routing. Whether the nickname 
is "provided" by the conference server or not, is not really a 
requirement, but the uniqueness requirement may reveal that the solution 
is to let the conference server administer the nicknames. Again, these 
are not the AoRs, which will be used as an asserted identity.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 May 2007 09:44:19 -0400

Miguel Garcia wrote:
> Hi Paul:
> 
> 
> Some inline comments.
> 
> Paul Kyzivat wrote:
> 
>>
>> Is there really a requirement that a participant in a conference be 
>> able to have *two* nicknames - one for the AOR and one for the 
>> nickname? I question this.
> 
> 

Sorry! I didn't write what I meant. I meant:

Is there really a requirement that a participant in a conference be able 
to have *two* *display names* - one for the AOR and one for the 
nickname? I question this.

> second option you mentioned.

I'm trying to get a better handle on the requirement here.

I guess you are saying that you see a requirement for the conference 
server to mediate all requests addressed to a nickname. And that is in 
contrast to having some anonymizer that might *not* be part of the 
conference server doing the mediation. And my question is *why* that is 
a requirement.

As to the first part of my question above: what behavior do you think is 
required if a request is received for a nickname when the nickname may 
be used in more than one conference, and might be assigned to a 
particular user at times when the user is not in any conference.

I know the past proposals have always been that the nickname is not a 
first class addressable entity - that requests destined for a particular 
nickname have been addressed to a conference focus and sub-addressed to 
particular nicknames for the focus to act on. But that only works for 
MSRP. I can't imagine that working with RTP for voice conferences.

So I'm looking for the fundamental requirement rather than the mechanism 
used to achieve it. IMO the nickname could easily be a globally routable 
URI, mediated by an anonymizer, which may or may not be associated with 
a conference server. When requests are addressed to it, it will need to 
apply some sort of analysis to decide if the request should be routed 
on. Lots of rules are possible, from simple to complex:

- any time there is a known mapping between the nickname and
   the actual URI for the user then a request will be forwarded.
   (Where this is a static, configured mapping.)

- any time the user owning the nickname has registered to receive
   requests then the request will be forwarded. (The usual sip
   registration model, though perhaps the contact being registered
   might be an AOR in another domain.)

- the request will only be forwarded if the user owning the
   nickname is currently participating in some conference known
   to the anonymizer.

- The participation in a conference via a nickname anonymizer
   will result in the participant having an AOR (the nickname)
   and a contact address supplied by the anonymizer being visible
   to the conference focus and potentially the other participants.
   If other participants chose to send requests out of dialog to
   that contact address (a form of gruu), they could be forwarded,
   out of dialog, to the contact address the user is using for
   participation, via the anonymizer, to that conference. This
   would work when the user is in a conference, and would localize
   the request to the particular conference without there needing
   to be any connection between the anonymizer and the conf server.

>> I would distinguish between how this is implemented by existing 
>> servers, which may simply be just the best they could manage, and what 
>> the actual intent is.
>>
> 
> 
>>>
>> matter if the conference service only permits users whose AOR is 
>> hosted by a particular domain. AFAIK that is currently the situation 
>> for major providers such as AOL. So then the question is whether we 
>> are trying to address those kinds of service providers.
> 

I don't know where to go with the above. IMO if the conf service allowed 
arbitrary AORs then an external nickname service would be sufficient.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 16 May 2007 13:27:13 +0300

> nickname? I question this.

I think such requirement exists. Let's assume the following use case: I 
am logged into a chat room, where I can see the list of participants, 
learned through a subscription to the (potentially extended with 
nicknames) conference event package. I can do a right click on a 
participant and I get a context sensitive menu. If the participant is 
anonymous, I can send a private message to him/her. If the participant 
has disclosed his URI, then in addition to sending a private message, I 
can also save his SIP URI and other information in my phonebook or 
contacts application. I can also check his profile, I can check the 
capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could be 
done automatically, so the UI could change the color if, for example, 
the response from the OPTIONS indicates that the participant supports 
audio and video.

If we decide to hijack an existing header for describing nicknames, then 
we will break all this use cases. For example, I could be storing a 
non-existent name or URI in my phonebook (if the user was anonymous). Or 
if we decide to not disclose SIP URIs at all, then I wouldn't be able to 
  view profiles or query for capabilities.

My conclusion is that the nickname is an additional feature that 
shouldn't override the existing headers and features.

/Miguel

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 16 May 2007 17:09:01 +0300

Hi Paul,

what it is not clear, maybe because I have lost some steps,
in your proposal is where is located the anonymizer that should provide
the anonymity or the nickname, 
should be in the user domain or in the conference service domain?

/sal

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 May 2007 10:25:10 -0400

I think that a nickname is an unadorned "display name" thing.  There isn't
the displayname+user@domain combination as in an AoR.  So I think a display
name and a nickname are not the same thing, but there isn't both a visual
and an addressing component of a nickname; there is just a nickname.

My display name is usually "Brian Rosen".  My nickname is "br" or "brtech.
Those are very clearly different, and I agree with Miguel that we don't want
to re-use the display name in an AoR.

Brian

> Sent: Wednesday, May 16, 2007 6:27 AM 
> To: Paul Kyzivat
> Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list'

---

From: "Bob Serr" <[email-masked]>
Date: Wed, 16 May 2007 11:12:28 -0400

I agree that the nickname should be an additional feature, beyond AOR
and display name, and that the feature should be optional. It is a
requirement that a user be able to select users in a participant list
and click into other modalities.

Regarding whether the nickname service is separate or part of the
conferencing server, it would be a simpler and easier to manage
architecture if it was part of the conferencing server. This will work
better in federated chat environments as it will be one less service
that you need to connect to in the federated environment. Additionally,
it will likely be the conferencing server, or even the
conference/room/channel that applies the policy about whether nicknames
are supported on the channel. For example, one room may allow anonymous
access while another may require that all user identities are known.

Bob

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2007 9:25 AM
To: 'Miguel Garcia'; 'Paul Kyzivat'
Cc: 'Niemi Aki Petteri'; 'SIMPLE mailing list'
Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation

I think that a nickname is an unadorned "display name" thing.  There
isn't
the displayname+user@domain combination as in an AoR.  So I think a
display
name and a nickname are not the same thing, but there isn't both a
visual
and an addressing component of a nickname; there is just a nickname.

My display name is usually "Brian Rosen".  My nickname is "br" or
"brtech.
Those are very clearly different, and I agree with Miguel that we don't
want
to re-use the display name in an AoR.

Brian

> > Is there really a requirement that a participant in a conference be
able

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 May 2007 12:21:26 -0400

> should be in the user domain or in the conference service domain?

I'm suggesting that it could be anywhere.

There could be an independent anonymizer service. (It could perhaps 
provide a variety of services. If you wish to make a single anonymous 
call and not be reachable then it could fill in an Anonymous identity. 
If you want to use a long lived nickname as a pseudonym then it could 
provide that.) If you use that sort of anonymizer to access a 
conference, then as far as the conference server is concerned the 
nickname is your actual AOR, and any authorization it does of you would 
be based on that.

The operator of conference servers could provide an anonymizer that 
provides nicknames for the convenience of users that have no better 
source. It could operate this in parallel but independently of its 
conference servers, or it could choose to couple them in some way. For 
instance it might only support using its anonymizer for originating 
requests to its own conference servers. It also might impose a filter so 
that out of dialog requests addressed to a nickname are only delivered 
if there is an active session for that nickname between the anonymizer 
and one of its conference servers. Authentication and authorization 
could also be coupled between the two servers.

I would hope that a provider of conference servers would not require use 
of its own anonymizer.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 May 2007 12:34:44 -0400

The disadvantage of having the nickname as part of the conferencing 
server is that the scope of the nickname is tied to the scope of the 
conferencing server.

For instance, suppose ietf maintained a conferencing server for use by 
the workgroups. I could have "paulk" as a nickname in that scope, for 
multiple conferences related to ietf things - sip, sipping, simple, etc.

Then perhaps SIPforum might have a conference server for use by the 
things it handles, such as SIPit. If it managed its own nicknames, then 
I might or might not be able to get the nickname "paulk". Its possible 
that somebody else might get that nickname there.

If the nickname anonymizer/provider could be independent of the 
conference server, then I could get
	paulk <sip:[email-masked]>
and use it as my identity in all of those conferences. Then people would 
know it was always the same person. With the nicknames coupled to the 
conf servers, even if I got "paulk" both places, people wouldn't 
necessarily know it was the same person.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 May 2007 14:46:01 -0400

Yep, that's the way I see it.  Anonymization of URI's is an independent
thing.  It may be common for a conference service to include an anonymizing
service.  No problem, but it's independent.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2007 12:21 PM
> To: Salvatore Loreto
> Cc: Miguel Garcia; 'SIMPLE mailing list'; 'Niemi Aki Petteri'

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 May 2007 14:54:02 -0400

I think the problem here is scope.

Within a domain, you could have a nick service.  AOL is a great example.
AOL could run a conference service, and use the same nicks.

However, www.freeconferencing.com can also run a conference service, and it
may not have anything interesting in its domain other than a conference
service.

Nicks are tricky, because of the uniqueness property.  They are typically
short, which means collisions on self selected nicks.  The bigger the
domain, the harder it is to maintain uniqueness.  I've used brtech as a nick
for a couple decades, and in most domains, I don't have a problem getting
it.  In AOL, I wasn't early enough; it was gone before AIM was available
outside the AOL paid service.  Of course brtech(3) is unique from brtech(1)
and a temporary hack like that for uniqueness within a conference service
works fine.

I think we couple a nick service to a domain, and not necessarily a
conference server.  The conference server almost always has a subdomain in
which it runs the nick service, of course.

Brian

> Sent: Wednesday, May 16, 2007 12:35 PM
> To: Bob Serr
> Cc: Brian Rosen; Miguel Garcia; Niemi Aki Petteri; SIMPLE mailing list

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 May 2007 15:56:34 -0400

> which it runs the nick service, of course.

I'm not sure I understand what you are saying.

It seems clear that nicknames are only unique within the domain that 
assigns them. If they are of the <name>@<fqdn> format then the <name> is 
only unique within the <fqdn> but the combination is globally unique 
within the scope that agrees on this definition. If it is a URI or URN 
then we understand its uniqueness.

The issue is whether a conference server requires the nicknames to be 
from a particular domain. Maybe we can't legislate this completely, but 
I think we at least out to recommend that nicknames from arbitrary 
domains be supported.

 From a UI perspective there is a downside to allowing nicknames from 
arbitrary domains - the names are in general longer because they must 
carry the name of the domain. This is very much like what happened when 
mail services were first federated. It can be dealt with using a 
defaulting rule. The UI for access to the conference server can have a 
default domain. Nicknames in the default domain can have the domain name 
stripped off for presentation in the UI, and conversely on input.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 May 2007 16:30:19 -0400

I don't think we can do that.

Nicks have to be short to be useful.  Accepting any nick from any domain
won't work (albeit a conference server can use the suffix idea to force them
to be unique).  I think, in the end, the nick has to be unique within the
domain the conference server operates within, or at least declares (i.e.
www.freeconferencing.com could demand an AOL screenname even if it's not an
AOL domain).

I don't think a nick is nick@domain, or at least we never see it that way.
It is, of course, because if a nick is unique in a domain, then you need to
know the domain as well as the nick, but the domain is implied, not
explicit.  

The proposal circulating just has a way for a UA to declare its nick, with
an error from the server that complains about non-uniqueness.  I think that
needs to be fleshed out some, because I do think having some kind of longer
lived nick is useful.  The mechanism to register a long lived nick need not
directly tie to the conference nick declaration, and the conference server
can always reject a nick not associated with an AoR that it knows (that is,
if there is a registration of long lived nicks, it would be something a nick
registrar does, and the conference server could ask the registrar if the
asserted nick is the same as that associated with the AoR).

So I think we can have two mechanisms.  A way to register a long lived nick,
and a way to assert a nick in a conference.

Please remember that a nick is as useful in a two way IM exchange as it is
in a chat room.  I don't want to tie nicks to conference servers, just make
them work as well there as in a simple IM pager mode or session.  The
assertion mechanism should work the same there as it does in a conference.

Brian

> Sent: Wednesday, May 16, 2007 3:57 PM
> To: Brian Rosen
> Cc: 'Bob Serr'; 'Miguel Garcia'; 'Niemi Aki Petteri'; 'SIMPLE mailing
> list'

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 17 May 2007 11:03:38 +1000

This discussion is great and helpful to the XCON folks. What we are
doing in SIMPLE is a nickname service for an adhoc conference. In my
opinion, the solution that Miguel and Aki are proposing in their draft
is sufficient enough to satisfy the requirements of enabling a
chatroom participant to suggest a nickname for himself/herself and get
accepted into the chatroom or get rejected with a reason of conflict
in nicknames. This is on a first come first server basis.

If a domain wants to have the service where a user can have a unique
nickname across chatrooms, then it is an implementation issue behind
the scenes and does not require standardisation.

If there are any other requirements, including nickname uniqueness
across domains or the reservation of a nickname forever, I think they
should go to XCON.

Regards,
Hisham

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 May 2007 21:57:57 -0400

I can see the registration of a persistent nick as outside the scope here.
We could do some standardization, but we don't have to.

However, we do need to standardize how a nick user "validates" the nick
against the AoR, if that is what the domain wants to do.

Nicks are not tied to conferences.  They can be used in other circumstances.
The validation operation can't be tied to a conference server.  I don't
really care which IETF work group does the work.

In my experience, conferences are the least common use of nicks.  Persistent
nicks are much more common than temporary nicks.  If we're going to bias
solutions, we ought to bias them towards persistent, non conference nicks.
It's not clear to me that we need such a bias.

Brian

> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2007 9:04 PM
> To: SIMPLE mailing list

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 17 May 2007 09:20:39 +0300

Hi Hisham,

I'll send a note to XCON in case they missed this thread (some of them 
may not be subscribed to SIMPLE). I agree it is relevant to what XCON is 
doing.

Cheers,

Gonzalo

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 17 May 2007 16:25:47 +1000

Brian,

What we are doing in SIMPLE is specific to IM chat service (hence the
name of the draft). My opinion is that whatever is in the draft is
sufficient.

Hisham

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 17 May 2007 08:35:03 -0400

Hisham

Do you think it would be wise for, let's say, a presence system which uses
nicknames have a different mechanism for informing its service of its
nickname than it would use for an IM chat?

Should the XCON mechanism be different?

I don't want to make this into a big deal, but nicknames are not peculiar to
IM chat.  I don't want an IM chat specific solution, especially when I don't
think we need a whole lot more than is proposed.  I think we need SOME more
to make a generalized nickname feasible.  Persistent nicks within a domain
is one of the big differences.

Brian

> Sent: Thursday, May 17, 2007 2:26 AM
> To: Brian Rosen
> Cc: SIMPLE mailing list

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 17 May 2007 23:28:30 +1000

Brain,

Thats fair enough. Why don't you get with Miguel and Aki and add some
text to the draft that makes it a generalised mechanism. I believe
Miguel are Aki are more than happy to make you a co-author of this
draft.

Hisham

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 18 May 2007 12:56:52 +0300

Hi,

regarding the scope of this work, my understanding was that SIMPLE was 
going to come up with an MRSP-specific solution for nicknames. A general 
solution for nicknames would be developed by XCON (SIP might be to be 
involved as well if SIP extensions were needed) at a later stage.

Therefore, the only requirement on the MSRP-specific solution would be 
that it is future-proof so that it does not keep us from developing a 
more general (while being backwards compatible) one in the future.

If my understanding of the process is correct, let's get the 
MSRP-specific solution finished and let's discuss the more general one 
somewhere else (e.g., XCON). If, on the other hand, this is not the 
process we want to follow, I would appreciate if somebody could clarify 
what our plan is.

Thanks,

Gonzalo

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 18 May 2007 07:35:57 -0400

Gonzalo

I don't want an MSRP specific solution.  I don't want an XCON solution.  I
want a SIP/IM/Presence/XCON... solution.  Nicknames are a common thing. 

The most common nicknames are things like AOL screen names.  They are
persistent, unique within a domain, and used with all forms of
communication.  Per chat temporary nicks happen to us techies that use
things like IRC, not to the real world.

I think this is a simple problem, with simple solutions.  I think it's
reasonably a SIMPLE problem, with possibly some SIP work for a header.  I
think we can first apply it to MSRP chat and expand it to XCON.

The proposal on the table needs only a little work, I think, to make it
generally useful.  I do think we need to agree on requirements first, but we
seem to be coalescing fairly rapidly on that.

Brian

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Friday, May 18, 2007 5:57 AM
> To: Hisham Khartabil
> Cc: Brian Rosen; SIMPLE mailing list
> >> > > I can see the registration of a persistent nick as outside the
> scope
> >> > here.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 10:16:42 -0400

> want a SIP/IM/Presence/XCON... solution.  Nicknames are a common thing. 

Right.

> communication. 

I agree with what you say here about the prior art. But I have 
difficulty relating the "unique within a domain" part to what we are doing.

That works for AOL because all communications, even the point to point 
kind, are mediated by a server in the AOL domain. Both ends share that 
domain and so the nickname namespace.

That fits with what the current proposal is, because it applies only to 
conferences, where again there is a common server mediating all 
communications.

But it doesn't generalize to the broader scope that you and I aspire to. 
In particular it doesn't generalize to point to point communications.

The real world is also more complex than this when you get to multiple 
providers. For instance I use a Gaim IM client, with connections to AOL 
and to a corporate Sametime server. The namespace for 
nicknames/screen-names is separate for the two domains but must be 
resolved in the client UI.

IMO the general solution must tag nicknames with their domain. That 
isn't so friendly if the domain shows up in the UI, but neither is it 
awful. It can be made better by a UI that does defaulting of the domain 
part of the nickname in a reasonable way.

	Paul

> Per chat temporary nicks happen to us techies that use

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 18 May 2007 13:57:04 -0400

Works for me.  So you really want nick@domain.
I try to separate what is displayed from what the protocol conveys.
nick@domain is unique, can be persistent, and I don't see any problem there.
Certainly, it's no stretch to have chatroom6.example.com as the domain.

[email-masked] and [email-masked] can be displayed as Bob(1) and Bob(2),
or any other way the UI wants to.

Brian

> Sent: Friday, May 18, 2007 10:17 AM
> To: Brian Rosen
> Cc: 'Gonzalo Camarillo'; 'Hisham Khartabil'; 'SIMPLE mailing list'
> >>>> IM chat.  I don't want an IM chat specific solution, especially when
> I
> >>>> don't
> >>>> think we need a whole lot more than is proposed.  I think we need
> SOME
> >>>> more

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 14:32:49 -0400

> or any other way the UI wants to.

Yeah, that's what I was thinking.

	Paul