Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI

From: Miguel Garcia <[email-masked]>
Date: Wed, 01 Aug 2007 15:00:45 +0300

Hi:

Some inline discussion

Paul Kyzivat wrote:
> inline
> 
> Miguel Garcia wrote:
>> Jonathan Rosenberg wrote:
>>  >> An example of a nickname is:
>>  >>
>>  >>           sip:[email-masked]
>>  >
>>  > If a nickname is scoped to a conference, the URI has to include a
>>  > conference identifier so that such URIs are unique and properly 
>> scoped.
>>  > I'd suggest something like:
>>  >
>>  > sip:"msrp-nicknames" "/" <nickname> "/" <conf-uri-userpart> @ domain
>>
>> This comes as a side effect of the confusion with domain nicknames in
>> previous issues.
>>
>> So, I agree that the nickname URI has to include the conference
>> URI.
> 
> Why?
> 
> By my understanding we are not excluding domain nicknames - we are just 
> not requiring them or specifying how they might work. Any syntactically 
> correct nickname should be ok if the server finds it acceptable 
> according to its own policies.

I try to understand that Jonathan is heading towards having a 
well-specified nickname that is restricted to the conference URI, the 
rest, can be done ONLY with a generalize mechanism, but not with MSRP.

So, we are not excluding domain nicknames, we are just not standardizing 
them.

> 
> Perhaps there is need for some mandatory-to-implement naming convention 
> for nicknames that are intended to be per-conference.

Yes, this is what I believe Jonathan is suggesting.

> 
>> Earlier versions of the drat spoke about sip:nick@conf@domain,
>> and percentage encoding of the first '@' sgn. Please verify if the
>> text we used to have is still applicable
>>
>>    Let us take a look at an example.  Assume the chat room URI allocated
>>    to a given chat room is 'sip:[email-masked]'.  A user whose
>>    nickname identifier is set to 'nordicguy' is represented with the
>>    nickname URI: 'sip:[email-masked]'.
> 
> Some other possibilities:
> 
>     sip:[email-masked];conf=room34

I think this format does not match a conference URI, so I wouldn't even 
try to pursue it.

>  or    sip:[email-masked];name="nordicguy"

better, but I what is a 'name'. A parameter named 'nickname' would even 
be better. Still, I think we can reuse the already defined 'user' 
parameter of a URI to write a nickname in the userpart.

> 
>>    In another example the chat room URI does not include a username
>>    part.  For example, the chat room URI is 'sip:chat34.example.com'.
>>    In this context a user whose nickname is 'nordicguy' gets represented
>>    with a nickname URI of 'sip:[email-masked]'.
>>
>> Let me know if the percentage encoding of the '@' is ok or you really
>> want to go with the "/" sign.
>>
>> The second aspect you are you suggesting: we should create a
>> convention to represent nicknames so that they are distinguishable
>> from "regular" URIs. This corresponds to the "msrp-nicknames" in your
>> suggestion. I also think we need to do it, mostly for tracing and
>> debugging purposes, but I thought of using the user= parameter of a
>> SIP URI.
>>
>> So, what about this syntax?
>>
>>    sip:[email-masked];user=nikcname
> 
> The user=nickname is an interesting idea. Would this mean that it would 
> be possible to have both:
> 
>     sip:[email-masked]
>     sip:[email-masked];user=nickname
> 
> and the two would be distinct, potentially owned by different people? 

Yes, this is what it means. While it would be confusing if you are just 
taking a look at the SIP packets, it wouldn't be confusing for the logic 
in the software.

In any case, it will be hard to avoid that someone takes as a nickname 
other person's username (like you suggested). I consider this issue 
orthogonal from the syntax of the nickname URI.

> That sounds like a pretty confusing situation. Isn't it sufficient for a 
> particular domain name to be dedicated to either "regular AORs" or 
> "nicknames", if that makes sense? And why would it be bad to use a real 
> AOR (that you own) as a nickname if you want and the focus allows it?

   I think a nickname is a string of characters. If you want your string 
of characters to include an '@' sign and be charact-by-character equal 
to your (or someone else's) SIP AoR, I think it should be possible, 
although the server may impose policy restrictions. The '@' sign may 
need to be percent-encoded, though, but this is not a problem.

This would fit with almost any of the proposed nickname URI syntax that 
we have been discussing.

>     Paul

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 01 Aug 2007 15:14:46 +0300

Hisham,

I agree with your text below. However, I want to highlight a problem:

The Conference framework (RFC 4353) provide high-level guidelines for 
the creation of conference URIs. It says that the conference URI has to 
resolve to the focus, but does not say that the domain part has to 
resolve to the conference. Remember that a focus will typically host 
several conferences.

So, sip:[email-masked] is a valid conference URI, so is valid 
also sip:chat34.focus.example.com, providing that chat34 is a (perhaps 
virtual) focus that handles a number of conferences.

Ideally I would like to have a conference URI where the conference is 
part of the hostname (e.g., sip:chat34.focus.example.com), but I suspect 
this has some impact of the DNS configuration. I believe most network 
operators will configure the focus on DNS, but not each of the chat 
rooms (e.g., sip:[email-masked]). So, we need to leave with it 
and have a mechanism to embed the nickname in the URI, perhaps using 
separators "/" like Jonathan proposed, or percent-encoding the '@' sign.

/Miguel

Hisham Khartabil wrote:
> I think the nickname needs to include the conference identifier for the 
> reasons as follows:
>  
> I am in a chatroom where Alice is. I want to send a private message to 
> Alice, so my client just happens to pick Alice's nickname and send the 
> message to her in a normal SIP MESSAGE.
>  
> The way I think the MESSAGE should reach its destination of Alice's 
> client is via the chatroom server. So, in order for that to happen, the 
> domain part of the nickname should be routable to the chatroom.
>  
> So Miguel, looking at your examples 'sip:[email-masked] 
> <mailto:[email-masked]>' and 'sip:chat34.example.com 
> <http://chat34.example.com/>' being both valid chatroom URIs. In both 
> cases, I think the nickname URI should look like <nickname>@ 
> chat34.example.com <http://chat34.example.com>. The latter chatroom URI 
> is ok since it can be routable to the chatroom , but the former is 
> troublesom. Guidence is need to say that when a nickname is created and 
> the chatroom URI is in the form [email-masked] 
> <mailto:[email-masked]>, the 'room' should be put as a subdomain in the 
> form [email-masked] <mailto:[email-masked]>.
> Regards,
> Hisham
>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 3 Aug 2007 15:00:45 +1000

> virtual) focus that handles a number of conferences.

Something is messed up here in your defintion of a focus. In my definition,
the focus IS the chatroom. A focus is one instance of a conference, not an
instance of a conference server.

> separators "/" like Jonathan proposed, or percent-encoding the '@' sign.

you might have a point with the DNS issue. I don't really care which way we
represent it (although I do prefer a parameter rather than a username with
seperators), but I do care that a message sent to a nickname outside the
session IS routed via the chatroom to the correct recipient. This requires 2
pieces of information: nickname, conference ID.

Hisham

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 03 Aug 2007 09:17:18 +0300

Inline...

Hisham Khartabil wrote:
> 
> 
> On 01/08/07, *Miguel Garcia* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hisham,
> 
>     So, sip:[email-masked]
>     <mailto:sip:[email-masked]> is a valid conference URI, so
>     is valid
>     also sip:chat34.focus.example.com <http://chat34.focus.example.com>,
>     providing that chat34 is a (perhaps
> Something is messed up here in your defintion of a focus. In my 
> definition, the focus IS the chatroom. A focus is one instance of a 
> conference, not an instance of a conference server.

Yeap, you are right: the focus is the SIP UA that instantiates the 
conference. Still we have one problem: the SIP conference framework does 
not provide any requirements for the creation of the SIP URI of the 
focus. Assume a conference server whose URI is sip:conf.example.com, you 
can still have two types of URIs for a given focus, for example:

     sip:[email-masked]
     sip:chat32.conf.example.com

So, most likely implementations use the former but not the latter.

>     part of the hostname (e.g., sip: chat34.focus.example.com
>     <http://chat34.focus.example.com>), but I suspect
>     rooms (e.g., sip:[email-masked]
>     <mailto:sip:[email-masked]>). So, we need to leave with it
> you might have a point with the DNS issue. I don't really care which way 
> we represent it (although I do prefer a parameter rather than a username 
> with seperators), but I do care that a message sent to a nickname 
> outside the session IS routed via the chatroom to the correct recipient. 
> This requires 2 pieces of information: nickname, conference ID.

Right. Earlier versions of the draft had that property, but then we 
introduced this ability to use a general nickname, although not fully 
supported, which won't have the property you requested.

I think I have an idea how to get your comments into the draft. Thanks.

/Miguel
>     <mailto:sip:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>' and
>     'sip: chat34.example.com <http://chat34.example.com>
>      > chat34.example.com <http://chat34.example.com>
>     <http://chat34.example.com>. The latter chatroom URI
>     <mailto:[email-masked]>
>      > <mailto: [email-masked] <mailto:[email-masked]>>, the 'room'
>     should be put as a subdomain in the
>      > form [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>.
>      > Regards,
>      > Hisham
>      >
> 
> 
>     --

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Aug 2007 09:32:15 -0400

I’m working on the more generalized nickname mechanism and I did run across
a related issue:
Do we permit nicknames with syntax that doesn’t conform to the syntax of the
user part of a URI?

The ability to form a URI with the nickname and the domain of the conference
can be useful but the primary purpose of nicknames is in user interfaces.
Do we want to restrict what the user interface can do in order to allow a
URI to be created from the nickname?

Brian

________________________________________
From: Hisham Khartabil [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 1:01 AM
To: Miguel Garcia
Cc: Paul Kyzivat; SIMPLE mailing list
Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI

So, sip:[email-masked] is a valid conference URI, so is valid
also sip:chat34.focus.example.com , providing that chat34 is a (perhaps
virtual) focus that handles a number of conferences.

part of the hostname (e.g., sip: chat34.focus.example.com), but I suspect

Hisham

/Miguel

Hisham Khartabil wrote:
> <mailto:[email-masked]>' and 'sip: chat34.example.com
> <mailto: [email-masked]>, the 'room' should be put as a subdomain in the
> form [email-masked] <mailto:[email-masked] >.
> Regards,
> Hisham
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Aug 2007 12:41:08 -0400

I'm neutral about whether more is allowed than what is permitted in the 
user part of a URI. (But that covers pretty much everything once you 
take into account escaping.)

But it should *at least* allow everything permitted in a URI.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Aug 2007 08:25:30 +0300

> Do we permit nicknames with syntax that doesn’t conform to the syntax of the

Can't they be percent-encoded to be represented in a username? If yes, I 
don't see a problem.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Aug 2007 08:32:28 +0300

Let me try to seek consensus on the issue of the Nickname URI.

We have been hearing that we need to allow URIs to be issued by any 
entity as well as the chat server. We agreed that the MSRP chat draft 
will tackle only the latter.

We haven't really agreed whether we envision MSRP chat operations 
(namely the NICKNAME method) with domain URIs in the future. The current 
version of the draft leaves open space for it, but this has created some 
misunderstanding. Since there is current work on generalized nicknames I 
would suggest that we take the assumption that the MSRP NICKNAME method 
only deals with chat room server scoped nicknames. Domain nicknames are 
not considered with the NICKNAME method.

We are having discussions on the representation of a nickname URI. Some 
of these problems come from the fact that we don't really know how to 
represent domain nicknames and we don't know the relation of them to the 
chat room server. I've been thinking that we should decouple the 
nickname itself from its representation in a URI. So, my suggestion is 
that the MSRP chat draft goes ahead with its representation of nicknames 
in a URI, for the purpose of reservation/validation (NICKNAME method), 
having into account that those nicknames are scoped to the focus of the 
conference. Other representation of nicknames (domain-scoped nicknames) 
may appear in From and To headers in CPIM, but not in NICKNAME method.

Representation of chat room scoped nicknames. We need a mechanism to 
identify that a nickname URI is effectively a nickname URI, and be able 
to extract the nickname (for rendering in the UI) from the rest of teh 
URI. Jonathan proposed:

which is correct in my opinion. While there have been other suggestions, 
  I haven't heard anyone indicating that Jonathan's proposal wouldn't 
work. So, I suggest we go for it.

/Miguel

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 6 Aug 2007 16:57:53 -0400

Having agreed to proceed with the nickname stuff in MSRP chat, BUT having
the benefit of the discussion on generalizing nicknames in the Chicago
meeting, I'd suggest we simplify as much as possible the MSRP mechanism.
Specifically, I suggest the following:

1. We don't need a display name on a nick name.  Just delete it.

2. We agree that there is a nickname, scoped within a domain, and you need
to be able to form a URI from it.  The domain in MSRP chat is always the
chat itself.  There is the complication that the domain of the chat may have
content prior to the "@".  This problem exists in XCON also.  This means
there needs to be a construction rule to form URI from the nick and the
domain, handling this problem.  OTOH, there really isn't a reason why the
domain needs to be mentioned in the Set-Nickname.  You can't use a NICKNAME
method outside the domain of a chat, so we know a-priori what the chat
domain is. 

4. Jonathan proposed a construction rule.  I don't understand why we need a
prefix.  We could easily put a rule that said, for example, in an MSRP From:
or To:, a slash must be escaped unless it separates nick from chat domain
user-part.  You already imply a rule that says you can't have
"msrp-nickname" with slashes as a URI in From:/To:.  

So: I propose that Set-Nickname simply have the nickname as the parameter:
Set-Nickname: joebob

I propose a construction rule from nickname+chat-domain to a URI useable in
MSRP From:/To: be to separate the nick from the domain with a slash IFF the
domain has a userpart.  So, for example:
sip:joebob/[email-masked]

Include the rule that a normal URI in From:/To: that has a slash needs the
slash to be escaped.

One other thought: the URI construction rule bothers me.  I don't like
forcing new syntax on the user-part, and restricting what the URI can look
like.  Consider making the nick a parameter to the domain URI in From:/To:
like:
sip:[email-masked];nickname=joebob
You could allow this syntax always (at least as an alternative)
sip:chat34.example.com;nickname=joebob

Brian

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]]
> Sent: Monday, August 06, 2007 1:32 AM
> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan
> Rosenberg
> Cc: 'SIMPLE mailing list'

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Aug 2007 09:57:17 +0300

Some inline comments

> 1. We don't need a display name on a nick name.  Just delete it.

Agreed. No changes with respect the current version of the draft, which 
already includes the following text:

    The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' to
    prepend the actual URI.  For the purpose of conveying nicknames,
    display-names MUST NOT be used, because the username part of a
    nickname URI provides its rendering property.  If the display-name is
    included in an Use-Nickname header field, it SHOULD be ignored.
    Implementations are RECOMMENDED to use only the user part of the
    nickname URI for rendering purposes.

> method outside the domain of a chat, so we know a-priori what the chat

I am trying to understand the benefit of it.

On one hand, the MSRP endpoint needs to understand the construction for 
nickname URIs defined by the document. This is because it is going to 
receive participant's nicknames via the conference event package, and it 
needs to be able to extract the nickname out of the URI for rendering 
purposes.

On the other hand, in the future, there might be participants who have 
non-chat-server-scoped nicknames. So, the endpoint needs to know the 
structure of the URI.

If the endpoint needs to know the structure of the URI I would prefer to 
be explicit and send in the Set-Nickname the full nickname URI that the 
user wishes to set. Somehow, I feel more comfortable being explicit.

> prefix.  

I think the prefix serves for two purposes. On one side, it is trying to 
avoid clashes between regular SIP URIs and nickname URIs in the chat 
room server/mixer.

But more important, I think the prefix also indicates the structure or 
scheme used in the nickname URI. Assume in the future we come up with 
another way to represent nicknames in a URI (perhaps the general 
nicknames), then we should have a mechanism to clearly identify which 
structure is used. I think the "msrp-nickname" prefix gives us such 
property.

 > We could easily put a rule that said, for example, in an MSRP From:
 > or To:, a slash must be escaped unless it separates nick from chat
 > domain user-part.

In CPIM From and To. But yes, I agree, slashes must be escaped unless 
used for the purpose of separating nicknames from the chat room name.

 > You already imply a rule that says you can't have

You could. Nothing prevents to you to add the string "msrp-nickname" as 
part of your nickname. That would lead to:

sip:msrp-nickname/msrp-nickname/[email-masked]

The prefix tells you how to decode the username part; the second 
"msrp-nickname" is your actual nickname. If you want to add slashes, you 
escape them.

> So: I propose that Set-Nickname simply have the nickname as the parameter:

As I said, I prefer to be explicit. I don't think we gain anything, and 
we loose a lot.

> sip:chat34.example.com;nickname=joebob

I also proposed the nickname parameter earlier, but there is something I 
don't like from it: parameters should be modifiers of the resource that 
add new characteristics to the resource. Here the resource is the 
chatroom URI (as opposed to the user URI), so if we take it literally, 
the nickname parameter represents the chat room nickname, not the user's 
nickname.

The idea of the nickname URI would be OK in the generic nicknames that 
you are working on, so I could write my SIP URI including a nickname, 
for example: sip:[email-masked];nickname=wine-expert

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2007 09:04:43 -0400

> the nickname parameter represents the chat room nickname, not the user's 

I don't see the problem here. The parameter does indeed modify the 
resource (chatroom), identifying a "sub-resource" - one of the nicknames 
owned and assigned by the chatroom. I don't see why it is necessarily an 
identifier of the chatroom itself.

> for example: sip:[email-masked];nickname=wine-expert

That would also be consistent - "wine-expert" is a nickname owned and 
assigned by [email-masked].

I also see this as pretty consistent with what Brian suggested. When 
using MSRP to request the nickname, simply send in the requested 
nickname part, and hopefully get back a URI containing that nickname. 
That way the focus can decide what scope it wants to use when assigning 
the nickname. It can use itself, or it can use something else. And that 
leaves open the door for getting nickname URIs some other way, while the 
consistent use of the parameter provides a common way to know what part 
should normally be displayed.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 09:40:38 -0400

I think you are too hung up on the fact you can create a URI out of a
nickname.  There is no more comfort in explicitly providing the URI and
forcing the UA (and the server) to decode it to extract the nickname, then
in sending the nickname and forcing construction of the URI.  I think:
Set-Nickname joebob
is much preferable to 
Set-Nickname sip:msrp-nickname/joebob/[email-masked]

I didn't remember the detail about how you extend the conference package.
It's much simpler to just have the nickname be the string, and not the URI.
It's an extension; there is no reason to require the URI, and we can make it
anything appropriate.  Keep it simple.

I'm trying to keep this mechanism as close to the generalized mechanism as
possible.  I want to go the other way from you: if you declare a nickname
with the generalized mechanism, I want the conference package extension to
not change, I want you to be able to (generally) mix and match use of the
generalized Set with the MSRP Set and I want the form of the construction to
be the same.  If we get away with that, we won't usually need to distinguish
how we set the nickname in the URI.  Even if we keep the text pretty much as
is, I'd prefer to change the prefix to just "nickname".

To be honest, we actually DO need to have an explicit domain in the
generalized SET, because it may not be the domain of the
chat/conference/whatever.  I want that in the generalized mechanism and not
in the msrp mechanism.  I don't want a client with the generalized mechanism
to be able to send a non local domain in the msrp Set.  I'm worried that the
client may not know that the chat server does not support the generalized
mechanism before he tries that, or using the Supported header for the
generalized mechanism to imply what can or cannot be sent in the msrp Set.

I'd make the domain in the generalized Set a separate parameter in the (sip)
header, not the constructed URI:
Set-Nickname joebob nickserver.example.com

I think you are mistaken about what the constructor rule does to user part
syntax.  If I choose a username of msrp-nickname/joebob, you can make a
valid nickname uri from it, but if I send a regular message, it looks like
it's from a nickname.  You would have to get a full set of nicknames from
the server and figure this out to know what my actual URI was and
distinguish it from my nickname.  I worry that there will be implementations
that will able to be failed by fooling them in this way.  I think the text
should say that usernames can't start with the prefix we choose, and the
server should enforce the rule.

When you use a nickname the message is always sent to the switch.  You
cannot address any form of message directly to the constructed URI.  This is
why the parameter works.   You ARE sending it to the switch, it is
translating the URI you send into an actually addressable entity.

Brian
> Sent: Tuesday, August 07, 2007 2:57 AM
> To: Brian Rosen
> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan Rosenberg';
> 'SIMPLE mailing list'

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Aug 2007 17:24:37 +0300

Inline.

Paul Kyzivat wrote:
>> I also proposed the nickname parameter earlier, but there is something 
>> I don't like from it: parameters should be modifiers of the resource 
>> that add new characteristics to the resource. Here the resource is the 
>> the nickname parameter represents the chat room nickname, not the 
>> user's nickname.
> 

Yes, it is a sub-resouce. I thought we wanted to have parameters that 
modify the resource, not use it to identify a sub-resource.

> assigned by [email-masked].

Yes, I see this other format more consistent. We are not using the 
nickname for sub-resourcing, but as a property of the resource. It is 
different from the example in the chat room.

> nickname part, and hopefully get back a URI containing that nickname. 

OK, if the endpoint gets back the full URI, I don't have a major 
problem. The endpoint needs to determine its own full URI and get the 
other participant's full nickname URIs. This is because the CPIM From/To 
headers require absolute URIs.

> should normally be displayed.

This is not going to work. What do you mean by "something else"? I think 
we ought to write very clear semantics that the Set-Nickname header in 
the NICKNAME method are intended to set a chat-room scoped nickname. How 
can it be that it could be in its own domain or something else?. I think 
the endpoint will go nuts if it doesn't know how the nickname is 
reserved and what is the structure of such nickname.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Aug 2007 18:15:33 +0300

Inline

> Set-Nickname sip:msrp-nickname/joebob/[email-masked]

I would agree on the implicit version providing that the response 
contains the full URI.

Still I don't really understand what are we achieving....

> anything appropriate.  Keep it simple.

The conference event package is extended with a new element surprisingly 
called <nickname>. It currently contains the URI.

I think the conference event package needs to send the full URI. 
Otherwise, there might be conflicts if one person with say a local 
nickname shares the nickname with a general domain nickname. When a user 
sends a private message to one of these nicknames, if the nickname is 
not a URI the server is not going to know how to route the message.

> not change, 

Agreed. The current extension holds a URI, so if you can represent a 
general nickname as a URI, then it is not a probelm.

> I want you to be able to (generally) mix and match use of the
> be the same.  

Generally agreed. I was assuming that the general Set nickname will 
require a domain, so it does the chat-room scoped nickname. But you seem 
to be suggesting the opposite, so I am confused.

The other thing: I believe we came to an agreement that on the 
procedures, we will use Set-Nickname in NICKNAME to set the chat-room 
scoped URI only. Setting a general nickname will be done by some other 
general procedure. Just wanted to confirm that we are on the same page.

> If we get away with that, we won't usually need to distinguish

Ok, we can change the prefix name to "nickname".

> chat/conference/whatever.  

Exactly

> I want that in the generalized mechanism and not
> to be able to send a non local domain in the msrp Set. 

Ok, I can agree with it. As long as the response contains the full URI, 
as I said before.

> I'm worried that the

ok, not a big difference with a uri: sip:[email-masked]

> server should enforce the rule.

The problem of knowing what is my real nickanme URI is solved if the 
nickname URI returned in the response to the NICKNAME method.

I don't have a problem to say that nicknames can't start by the prefix. 
Paul wanted that feature, but I don't have a problem in either way.

Miguel

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 11:46:56 -0400

We're getting closer!

> not a URI the server is not going to know how to route the message.
Let me make sure I get your problem:
I have a nickname in nickserver.example.com, say joebob.  

Now, you use the msrp NICKNAME method to create a local nickname, also
joebob
NICKNAME
Set-Nickname joebob

So, now I have two definitions of joebob, one declared in the chat, one a
more permanent one at nickserver.example.com.  The nickname is the same, the
domains are different.

As we discussed, the generalized mechanism need local policy to decide if
the server allows such a conflict (same nick).  I think the notion that
because they have different domains they are different is wrong.  You can
keep them separate for addressing purposes, but you force the UI to deal
with them as the same.  I think if nickname part is the same there is a
collision, and either it's allowed or not, and the domain is not part of
that.  If it's allowed, the client and the server have to deal with the
issue. 

This is not an issue for msrp chat: the text does not allow two users to
have the same nickname.  When we get to the generalized mechanism, we have
to make it work for same name, different domain and same name, same domain.

Brian

> Sent: Tuesday, August 07, 2007 11:16 AM
> To: Brian Rosen
> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki'
> >>> chat itself.  There is the complication that the domain of the chat
> may
> >> have
> >>> I propose a construction rule from nickname+chat-domain to a URI
> useable
> >> in
> >>> MSRP From:/To: be to separate the nick from the domain with a slash
> IFF
> >> the
> I
> user's
> >>>> misunderstanding. Since there is current work on generalized
> nicknames
> >> I

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2007 14:41:24 -0400

Joebob - comments inline.

	Paul

> that.  If it's allowed, the client and the server have to deal with the

I don't like this approach. IMO at the *protocol* level nicknames must 
be unique - except possibly that if one user has two sessions he may use 
the same nickname for both. (That needs further consideration.)

The point of having domains is to deal with that, and allow two joebobs 
only when they are in different domains.

It is then an issue for the UI to deal with the collisions as it sees 
fit. Some things it might do:
- distinguish by colors - e.g. (red)joebob, (blue)joebob
- distinguish with suffixes - e.g. joebob, joebob(2), ...
- display first without domain, others with domain:
   joebob, [email-masked]
- display all with domains: [email-masked], [email-masked]

It needn't be our problem to figure out this part.

But when I reply to a particular joebob thru my UI, the protocol must 
identify the particular joebob I meant.

> to make it work for same name, different domain and same name, same domain.

I think we could eventually get into a situation where we have a server 
that supports the msrp nicknames and the more general ones as well. Some 
clients may use msrp to get their nicknames, and others the other 
method. They need to interoperate.

I see the nickname method in msrp to be just a limited way to *assign* a 
nickname, but it doesn't limit to *use* of nicknames assigned that way.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Aug 2007 21:43:30 +0300

I understand the potential conflict between a generalized nickname URI 
and chat-room scoped nickname. Yes, we spoke that the policy in the chat 
room will determine whether it is allowed or not. I am afraid that, in 
case the conflict is allowed, it is the UI's responsibility to avoid the 
clash towards the user, rendering them differently.

This bring another issue. If a chat room does not allow clashes in the 
nicknames, then he should prevent them also between different domains 
([email-masked] and [email-masked]). And it would be very easy 
to prevent that a user with a legitimate nickname, issued by his 
nickname server, would never be able to use it in a chat room. We just 
need a rouge guy who sets the chat-room scoped nickname joebob, 
preventing the other two to use their regular permanent URIs.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Aug 2007 21:45:08 +0300

I agree with Paul.

/Miguel

Paul Kyzivat wrote:
>>>>>> Include the rule that a normal URI in From:/To: that has a slash 
>>>>>> needs
>>>>> the
>>>>>> slash to be escaped.
>>>>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 16:28:48 -0400

I think this leads to users not understanding why their nicknames work
sometimes and not others:

Example 1:
My nickname is joebob.  Your nickname is joebob.  Neither of us is
registered. We both ask the chat server to give us joebob.  I get there
first, and you get an error.

Example 2:
My nickname is joebob.  Your nickname is joebob.  I am registered at some
other domain.  We both ask the chat server to give us joebob.  I get there
first, but this time it works for you.

You would have to know that I registered my nick somewhere else, so my URI
is unique, to know why you got an error in the first example, but didn't in
the second.  Normally, the URI isn't visible to the users, only the names
are.

If you allow a nickname collision, you incur costs at both the server and
the clients.  You can't avoid them.  Collision really is the name; the
domain MAY help you, but since it can't fix the whole problem, it isn't
useful.

Note that we are discussing the generalized nickname mechanisms, not the
msrp-chat.  We're projecting a problem onto that mechanism and trying to
solve it here.  In msrp-chat, you can't have a collision.

Brian

> Sent: Tuesday, August 07, 2007 2:45 PM
> To: Paul Kyzivat
> Cc: Brian Rosen; 'SIMPLE mailing list'; 'Niemi Aki'
> >>>> It's much simpler to just have the nickname be the string, and not
> the
> >>> URI.
> >>>> I'm trying to keep this mechanism as close to the generalized
> mechanism
> >>> as
> >>>> with the generalized mechanism, I want the conference package
> extension
> >>> to
> >>>> not change,
> >>>> I'd make the domain in the generalized Set a separate parameter in
> the
> >>> (sip)
> >>>>>     The 'name-addr' ABNF in RFC 3261 allows an optional 'display-
> name'
> >>> to
> >>>>>     nickname URI provides its rendering property.  If the display-
> name
> >>> is
> >>>>>> 2. We agree that there is a nickname, scoped within a domain, and
> you
> >>>>> need
> >>>>>> to be able to form a URI from it.  The domain in MSRP chat is
> always
> >>> the
> >>>>>> domain, handling this problem.  OTOH, there really isn't a reason
> why
> >>>>> the
> >>>>> receive participant's nicknames via the conference event package,
> and
> >>> it
> >>>>> If the endpoint needs to know the structure of the URI I would
> prefer
> >>> to
> >>>>>> 4. Jonathan proposed a construction rule.  I don't understand why
> we
> >>>>> need a
> >>>>>> prefix.
> >>>>> I think the prefix serves for two purposes. On one side, it is
> trying
> >>> to
> >>>>>> forcing new syntax on the user-part, and restricting what the URI
> can
> >>>>> look
> >>>>>>> version of the draft leaves open space for it, but this has
> created
> >>>>> some
> >>>>>>> only deals with chat room server scoped nicknames. Domain
> nicknames
> >>> are
> >>>>>>> represent domain nicknames and we don't know the relation of them
> to
> >>>>> the
> >>>>>>> nickname itself from its representation in a URI. So, my
> suggestion
> >>> is
> >>>>>>> having into account that those nicknames are scoped to the focus
> of
> >>> the

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 16:33:02 -0400

> preventing the other two to use their regular permanent URIs.

This problem occurs in msrp-chat nicknames.  The rogue fellow asks for
jeobob, and you can't get it.  You can't avoid it.  The generalized
mechanism, with clients and servers that can deal with collisions might be
able to handle it, but the msrp-chat nickname mechanism can't.  The domain
is always the chat domain, and thus you can only have one user with a given
nickname.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2007 17:20:15 -0400

Brian Rosen wrote:
> registered.

Neither of us "has" the nickname joebob. We both *want* the nickname 
joebob in the scope of this conference.

> We both ask the chat server to give us joebob.  I get there

We both wanted it, and one of us won. What do you *want* to happen?

The conf server could hand out two nicknames that are both joebob in 
different domains that the server controls, if it wants to do that. It 
depends on what its policy is for duplicates.

> first, but this time it works for you.

In that case you *do* *have* the nickname joebob in some domain. Its 
more than a wish. So this isn't surprising.

Are you assuming that anyone can ask for any nickname from any server, 
and always get it, even if someone else also has the same nickname from 
the same server? If so, the protocol and the UI can't distinguish them 
and I can't selectively send to one or the other. I find that entirely 
unacceptable.

> the second.  Normally, the URI isn't visible to the users, only the names

This would be no different than me being the 2nd user rather than the 
first to show up.

You think this is unacceptable, but I find it way more acceptable than 
not being able to discriminate between two distinct joebobs.

As I said above, if you want more-or-less this behavior then we must 
allow the MSRP server to accept multiple requests for nickname joebob 
and give them *different* URIs in return.

> solve it here.  In msrp-chat, you can't have a collision.

No. I think this is lapping over to the msrp-chat nickname issue to 
because of needing to sort out what happens when two people request the 
same nickname.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 18:11:32 -0400

Inline

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2007 5:20 PM
> To: Brian Rosen
> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki'
I want an error, especially in msrp-chat declared nicknames

> depends on what its policy is for duplicates.
Not in msrp-chat nicknames.  Yes, if that is its policy in the generalized
mechanism.  The generalized mechanism needs a way to have unambiguous URIs
if it has a policy of allowing collisions on nicknames.

> more than a wish. So this isn't surprising.
It is surprising to the user, who doesn't understand the difference

> and I can't selectively send to one or the other. I find that entirely
I am not assuming that.  I am assuming that if the policy for nicknames is
that collisions are allowed, that a collision exists whether the domain of
the nickname is the same or different as long as the nickname itself is the
same.

If the policy is that collisions are not allowed then two users requesting
the same nickname that happen to have different domains would be rejected
with an error.

Of course, it would also reject, with the same error, if the domains were
the same, specifically if they were requested from the using domain (the
chat server).  This would always be the case in an msrp-chat nickname
declaration because I want this mechanism to always disallow collisions.

> not being able to discriminate between two distinct joebobs.
I think if collisions are allowed, collisions exist if the nicknames are the
same, and the mechanism must provide a way to construct a unique URI.  If
the domains are different, then it's easy.  If the domains are the same,
more work is needed.

> and give them *different* URIs in return.
Yes, I agree with this, but only in the case of the generalized mechanism,
where the policy of the chat server (which is could mint nicknames using the
generalized mechanism) was to allow collisions.

> because of needing to sort out what happens when two people request the
In msrp-chat, I want it to not be allowed.  If two users request the same
nickname, I want an error on the second (and succeeding) requests.  The
problem we are discussing: same nickname, different domains, cannot exist.
The only acceptable domain is the domain of the chat.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2007 20:01:31 -0400

> I want an error, especially in msrp-chat declared nicknames

OK. That helps. But then I think your desires are inconsistent, or else 
I don't understand what you are saying.

I'm saying that the *clients* of this server must be prepared for the 
case where the server supports the more general mechanism, where some 
participants may have nicknames in some other domain, and ones with 
identical names but different domains. This is so even though it might 
not be possible for that to arise using only the MSRP mechanism.

> if it has a policy of allowing collisions on nicknames.

OK, if you want to make that rule for the msrp mechanism, then that is 
ok, so long as you then only allow one request for a given nickname to 
succeed at any given time. (Which I now see you do want.)

> It is surprising to the user, who doesn't understand the difference

Users already must understand the difference between permanently signing 
up for a nickname vs not doing that and just trying to get one when they 
enter a chat. This is not unfamiliar.

And if you want, you can make a rule that an msrp nickname request will 
always fail if there is already someone in the chat using an external 
nickname that "clashes". BUT, that isn't a complete solution unless you 
also prevent anyone using an external nickname from later joining the 
chat if their nickname clashes. While you *could* do that I think it 
would be a bad way forward.

As long as the UIs are prepared for this from day 1 I think the users 
will cope.

> the same nickname that happen to have different domains would be rejected

I think there is some confusion here. There is requesting to have a 
nickname *assigned* to you within some scope/domain, when it otherwise 
wasn't, and there is requesting to *use* a nickname in a particular 
session. The msrp method does both, binding the scope/domain of the 
assignment to the session you are establishing.

There can be collision on assignment, and there can be collision on use. 
And there can be collision on the name+domain or on just the name.

I believe the policy you are suggesting applies to collision on just 
names, for *use*, not assignment. I agree you can go either way on that, 
though it will ultimately be an annoying system if it forbids it.

For assignment we always allow collision on names if the domains are 
different - that is the point, and there is no way to forbid it if the 
assignment is administered independently per domain.

For assignment collision on name+domain is probably a bad idea, unless 
the entities doing the requesting are really the same in some sense. If 
they are then there probably aren't multiple assignments. So I think 
this is a non-issue.

Collision on use at the name+domain level must be carefully controlled 
or users of the system will not be able to make any sense of it. I think 
the same name+domain can be used for multiple sessions with the focus 
*if* all the sessions belong to the same user, whatever that means. Its 
probably easy if they authenticate with the same credentials. Otherwise not.

> the same,

I think you are saying what I said in last paragraph above.

> specifically if they were requested from the using domain (the

I'm not sure if we are agreeing or not.

> the domains are different, then it's easy.  If the domains are the same,

If you want to use something other than domain for further 
discrimination (e.g. an URI parameter), for the msrp case, then I can 
probably live with that, pending the details.

> generalized mechanism) was to allow collisions.

Again I don't know if we are agreeing or disagreeing.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 20:28:21 -0400

Let's break this down piece by piece, because we each don't yet understand
what the other is saying.

I propose that msrp-chat not allow nickname collisions.  If two users do
Set-Nickname with the same nickname, the second gets an error.

Do you agree to that?  Miguel?

I think we all agree that the generalized mechanism will allow collisions.
Let's see if we can agree on when these happen:
1. Two users with externally defined nicknames, where the domains are
different
2. Two users request the same nickname from the local server

In the hope that we all do agree, I'll press on one more (big) step.

3. I propose that the generalized mechanism allow an external domain to
permit the same nickname for multiple users, and a chat server or other user
of nicknames could allow that in a single chat/conference/whatever.  I'm not
sure that a domain who registers nicknames will have a policy that does
permit it, but I don't see a fundamental reason why we would accept two
users with the same nicknames in the local domain, but not two users with
the same nicknames from an external domain.  To make either work, somehow, a
URI has to be minted that is unique.  We don't have to specify how to do
that yet, but a parameter on the URI is one way that would work.

I'm going to pause to see if we agree or don't.

Brian

> Sent: Tuesday, August 07, 2007 8:02 PM
> To: Brian Rosen
> >>> is unique, to know why you got an error in the first example, but
> didn't
> >> in

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 8 Aug 2007 10:40:57 +1000

> not considered with the NICKNAME method.

Agreed.

> work. So, I suggest we go for it.

I agree with the above.

Do we also have concensus that a nickname URI is routable to the focus
(chatroom) outside the session?

Hisham

/Miguel

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 8 Aug 2007 11:01:03 +1000

(adding SIMPLE again)

I don't have the participant's URI to message him outside the session. The
only way to reach him is through his nickname in the chatroom. It is a sort
of private message where the user is not reachable after the chat session is
terminated.

Hisham

On 08/08/2007, Brian Rosen <[email-masked]> wrote:
> No
> For one thing, we don't know what that means.  For another thing, we know
> we
> will be permitting the domain of the URI to be outside the focus domain in
> the generalized case, and it won't work at all.
>
> The only thing we define the URI to be able to be used for is in an msrp
> from: and to:.  In xcon, there may be more operations defined, but none of
> them are outside the session.
>
> Why do you want to do this?
>
> Brian
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2007 23:16:05 -0400

> Do you agree to that?  Miguel?

I'm ok with that, though I don't think we *must* do that. But I don't 
feel strongly about it.

> 1. Two users with externally defined nicknames, where the domains are

Yes.

> 2. Two users request the same nickname from the local server

As I noted before, I distinguish between requesting the ownership of a 
nickname and trying to use it in a conference.

I believe the requesting/assignment of ownership for a nickname is 
probably out of scope for us - it could simply be something you do at a 
web site. I don't think it makes any sense for one to be assigned to 
more than one "entity", but one might be usable with a bunch of 
different sets of credentials / used in conjunction with multiple user ids.

I do think "collision" in the use of a single nickname should probably 
be ok as long as each session that asserts it is *authorized* to use it, 
however that is determined, which is still TBD. But if somebody wants to 
enforce a policy that forbids it then I guess that is their business.

I also think that collision in *use* of a nickname should be ok (if 
policy permits) even if the nickname is *assigned* via msrp. But exactly 
how that would work needs some consideration.

> that yet, but a parameter on the URI is one way that would work.

I think I agree with this. Lets see how my comments above go.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2007 23:25:43 -0400

>     work. So, I suggest we go for it.

I think this will work with conference scoped nicknames. But it seems 
less than ideal for nicknames that are more broadly scoped. Frankly I 
would prefer something like 
sip:<nickname>[/conf-uri-userpart]@domain;user=msrp-nickname. Here the 
user param indicates a particular syntax for the user part. Other URIs 
used as nicknames but without this user parameter would be treated 
differently.

> (chatroom) outside the session?

Whether it is routable should be a policy of the minter of the nickname. 
I believe it would be good for an msrp-assigned nickname to be routable 
while it is being used, but not otherwise. For externally assigned 
nicknames the policy might be more involved:
- might be routable all the time, like an alias
- might only be routable when the nickname is being used
   in one or more sessions. (But I don't know how the minting domain
   would know that.)
I don't think we need to specify this except to say that it might be, 
might not be, might sometimes be.

	Paul

> ------------------------------------------------------------------------
>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 08 Aug 2007 09:00:31 +0300

You guys had a long discussion while I was sleeping. I'll try to get my 
opinion to this e-mail. Inline.

 > Do you agree to that?  Miguel?

Of course. Yes. This is the current behavior. The draft defines a 423 
response: "Nickname usage failed; the nickname is not allocated to this 
user".

> I think we all agree that the generalized mechanism will allow collisions.

Yes, let me clarify that sentence. The generalize mechanism will allow 
collisions in the username part of the URI, i.e., with two different 
domains. This means: there are collisions for UI rendering, but there 
aren't collisions for routing private messages.

> 1. Two users with externally defined nicknames, where the domains are

Yes, no problem. In this case, we have the UI rendering collision, but 
no the routing of private messages problem.

> 2. Two users request the same nickname from the local server

This should not be allowed, because it will lead to two users with 
exactly the same byte-by-byte nickname URI, including the domain name. 
If these two users having the exactly same nickname URI are in the same 
conference, it wouldn't be possible to determine which of them is the 
legitimate recipient of a private message addressed to that nickname 
URI. I think this shouldn't be allowed.

> that yet, but a parameter on the URI is one way that would work.

I don't think we should  go into that direction. Permanent nicknames 
should be exclusively allocated to a given user. Otherwise people are 
going to get very confuse when they see [email-masked] in a 
conference, send him a private message, and then realize is a different 
person from the [email-masked] they previously messaged.

I think allowing non-exclusive access to nicknames would be like issuing 
shared e-mail addresses. Can you imagine if [email-masked] is shared 
by you, Paul, Hisham, and me? It would be fun though....

/Miguel

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Aug 2007 09:27:19 -0400

Okay, progress.  Slow, but progress.

Miguel, you think that there can be UI collisions.  You worry that if we
allow domain collisions, we can't create distinct URIs.

I'd like to point out, as I did with Paul, that users won't really be aware
of the domains.  It may well be that a user registers his nick with some
service, but the domain won't show up anywhere they can see (normally).
Most importantly, whether I register a nick at some external domain or not
shouldn't affect what YOU see.  I may be aware of my nick's domain, but you
are not.

This, to me, is the problem with your position on this issue.  You want to
not allow a local domain to have two users with the same nick, but you are
okay with two users from external domains (or one internal and one external)
having the same nick.  You think the UI can deal with the nickname part, but
you are concerned we won't have a way to create a unique URI. 

I think, to a user, the cases look the same, and especially to a user who
did not register their nick with an external service, they may be able to
get a nick with a collision sometimes (if the other guy used an external
service) but not other times (if the other guy used the local service).
Since the domain is normally not visible, that is poor design.

I also think it's easily fixed.  

I've been thinking about this for a while now, and have come to the
conclusion that we have made a leap of assumption we should not have made.
The leap is that you construct the uri from the nickname.

Let's think about not doing that for a moment.

Suppose that nicknames were associated with a URI, but the association was
not a construction rule using the nickname, but rather just a URI minted by
the chat server, a full fledged anonymous URI.

Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, whether
using the msrp-chat mechanism or the generalized mechanism was that it
returned an anonymous URI.

Now, everything works: you always have a unique URI to use.  The name
collision can be dealt with by the UI, and it works the same way no matter
what the domains the nicknames are declared in are.

And Hisham's notion that maybe you can make that URI work outside the
session could be made to work by the chat-server, if it wanted to.

And to Paul's notion that only collision on use is important, it addresses
that issue as well.

And it gets us out of funny escaping, new parameters, and other weirdities
of a construction rule
 
Brian

> Sent: Wednesday, August 08, 2007 2:01 AM
> To: Brian Rosen
> >>> I am not assuming that.  I am assuming that if the policy for
> nicknames
> >> is
> >>> that collisions are allowed, that a collision exists whether the
> domain
> >> of
> >>> the nickname is the same or different as long as the nickname itself
> is
> >> the
> >>> same.
> >>>>> You would have to know that I registered my nick somewhere else, so
> my
> >>>> URI
> >>> I think if collisions are allowed, collisions exist if the nicknames
> are
> >> the
> >>> where the policy of the chat server (which is could mint nicknames
> using
> >> the
> >>>>> If you allow a nickname collision, you incur costs at both the
> server
> >>>> and
> >>>>> msrp-chat.  We're projecting a problem onto that mechanism and
> trying
> >> to

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Aug 2007 11:15:30 -0400

> shouldn't affect what YOU see.  I may be aware of my nick's domain, but you

I don't agree with your assumptions. This all depends on how the UI is 
managed for the client, and is somewhat speculative because its all 
about functionality that doesn't currently exist.

To use this capability you will need to register for a nickname with 
some service, and tell your IM client to use that one. Surely this will 
be apparent to the user as something different than telling the IM 
client to try to use an unregistered nickname in conferences.

I would also expect that a good IM client would have a way of 
discovering the details about a participant that it doesn't display be 
default. So I should be *able* to see your domain if I ever care.

This is a lot like how addresses are managed in email clients. Lots of 
clients seem to hide the actual URL by default and only show the display 
name. But typically there is a way to cause the URL to be displayed, or 
to at least query for it if you care. Some people go through life 
thinking there is only one John Smith, because they only get email from 
one. But when they reply, it is to the right one.

> you are concerned we won't have a way to create a unique URI. 

I think you are mixing up "domain" and "nickname assignment service". A 
single nickname assignment service, whether an independent entity or 
part of a conference focus, can potentially allow collisions on the name 
part of a nickname URI by assigning URIs that are distinct in some other 
part of the URI, whether that be by using two domain names, or by adding 
a parameter, or whatever.

So if two users both want to be joebob in a conference with focus 
sip:[email-masked], then one possibility might be:
- sip:joebob/[email-masked];user=msrp-nickname
- sip:joebob/[email-masked];user=msrp-nickname;instance=2
or
- sip:joebob/1/[email-masked];user=msrp-nickname
- sip:joebob/2/[email-masked];user=msrp-nickname

Of course these would require us to agree on the conventions about what 
part is typically displayed.

If those two users wanted to request joebob from an independent service 
that owns domain nick.name then it could do it as:
- sip:[email-masked]
- sip:[email-masked]
or
- sip:[email-masked]
- sip:[email-masked]
or
- sip:[email-masked]
- sip:[email-masked]
or
- sip:[email-masked];instance=1
- sip:[email-masked];instance=2

And there are lots more possibilities. With these the display convention 
could simply be to use the username part by default, and qualify it in 
some way when there is more than one in the same conference.

> And it gets us out of funny escaping, new parameters, and other weirdities

How is what you are suggesting different from a display name on an 
anonymous URI?

It is essential that a nickname only be used when authorized. Of course 
that is the unresolved issue with externally assigned nicknames as well.

This of course wouldn't be a problem if the nickname service was a full 
fledged anonymizer. When messages when through the anonymizer, the 
source address would be replaced with the nickname, and the nickname 
would be what was authorized by the recipient/focus.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Aug 2007 11:35:12 -0400

Is there a reason to want a construction rule for the URI?

The nick could be a display name on an anonymous URI.  You would send a
nickname to the nick service, it would return the anonymous URI with the
display name.  

I think we have a problem in marking.  How does anyone know that this is
what the URI means?  Can we do this without marking the URI itself, and know
by where it goes in various messages?

I don't think users managing nicknames by turning on and off display of URIs
is going to work.  I don't think we NEED to cause such confusion, and I'd
prefer to not create the situation in the first place.

Brian

> Sent: Wednesday, August 08, 2007 11:16 AM
> To: Brian Rosen
> >>> permit the same nickname for multiple users, and a chat server or
> other
> >> user
> >>> of nicknames could allow that in a single chat/conference/whatever.
> I'm
> >> not
> >>>>> mechanism.  The generalized mechanism needs a way to have
> unambiguous
> >>>> URIs
> >>>>>>> My nickname is joebob.  Your nickname is joebob.  I am registered
> at
> >>>>>> some
> >>>>>>> other domain.  We both ask the chat server to give us joebob.  I
> get
> >>>>>> there
> >>>> probably easy if they authenticate with the same credentials.
> Otherwise
> >>>> not.
> >>>>
> >>>>>>> the second.  Normally, the URI isn't visible to the users, only
> the
> >>>>>> names
> >>>>>>> are.
> >>>>> same, and the mechanism must provide a way to construct a unique
> URI.
> >>>> If
> >>>>>>> Note that we are discussing the generalized nickname mechanisms,
> not
> >>>> the

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 09 Aug 2007 15:20:27 +0300

Inline

> shouldn't affect what YOU see.  I may be aware of my nick's domain, but you

I think this is not the case, at least in e-mail clients. You can 
usually see the display name (equivalent to nickname). If you hover over 
the nickname, you can see the full From header.

I was expecting similar but not exactly the same behavior in chat rooms. 
The client will allocate separate identifiers to nickname collisions, 
such us joebob, joebob(2), joebob(3). If the user wants to send a 
private message to one of this, and it doesn't know which one is the 
target, he can hover over any of them.

> you are concerned we won't have a way to create a unique URI. 

I re-read this paragraph a few times, and I think I understand you and 
see where we have been disagreeing. So, let me try to clarify your words.

Terminology:
nickname-string: refers to the visible (UI) identifier.
nickname-URI: refers to the associated URI.
nickname: not used to avoid misleading.

So, are you saying that two users of the same domain could have the same 
nickname-string but different nickname-URI? If this is possible, I don't 
have any problem. This would require to add something like a unique 
identifier to a each nickname-URI.

For example:

sip:nickname/joebob/[email-masked]
sip:nickname/joebob/[email-masked]

The UI will display joebob(1) and joebob(2) in the chat room, but the 
user can perhaps hover to get the full nickname-URI, or perhaps also the 
SIP AoR (if available).

I don't have a problem with this. In the past, I have been always 
thinking that a nickname-string in a domain will create a unique 
nickname-URI.

This is becoming GRUU, by the way.

> The leap is that you construct the uri from the nickname.

This is another possibility that we somehow explored in the past. If the 
nickname-string is not connected to (and can be derived from) the 
nickname-URI, it behaves essentially as a display name. The conference 
event package will have to send both (which is not a problem).

So, the linkage between nickname-URIs and nickname-strings will exist in 
the chat room server only, although the endpoints will get it (mainly) 
via the conference event package.

> And it gets us out of funny escaping, new parameters, and other weirdities

Yeap, I think this works. I may also add one step more. We could make 
the focus to create a GRUU per participant that requests a nickname. The 
GRUU will resolve to the focus, but it will have a unique identifier 
that is available to the user that requested it. This allows private 
messaging, in and outside the conference (as per Hisham's request).

The nickname-string is merely a display name. We have display names in 
the From/To headers in CPIM.

So, a user would send the NICKNAME method with the Set-Nickname header 
set to the nickname-string: joebob. It will get back the nickname-string 
plus nickname-uri, for example:

"joebob" <sip:[email-masked];gr=3298sd0d98s>

This can be used in From/To headers, or announced via the conference 
event package.

If there are several "joebob" in the same chat room, the UI will 
differentiate it. But since the nickname is unique, there is no problem 
to route private messages.

Comments?

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Aug 2007 10:03:55 -0400

There are comments inline below. But I have one general observation to make:

As we discuss this I am beginning to see this as almost the same, or a 
very similar, problem as SIP Identity and "callerid" functionality. 
Namely we need for some trusted party to vouch for the claimed identity. 
For SIP Identity it needs to be in the signaling path. In our case we 
sometimes are using the focus and mixer as the trusted party, but when 
the identity is assigned elsewhere then we may need that to be on the 
path. Unfortunately, if we intend to send these identities in the msrp 
media stream then the trusted party may need to be on that path. But 
maybe not if we also trust the mixer to verify the identity with the 
actual trusted party. (But of course that is the transitive trust that 
people aren't very happy with.)

Casting this as an identity problem may make it much harder to solve, 
but if that is what it is then there is no getting around it, and we 
might as well apply all the expertise available on that subject.

> target, he can hover over any of them.

I agree.

> thinking that a nickname-string in a domain will create a unique 

I don't have a problem with this either.

> via the conference event package.

They could get it otherwise. The msrp "mixer" could add the nickname (as 
a display name) to the From header of msrp messages when the From header 
contains the corresponding id.

If the mixer promised to police this so that those nicknames could be 
trusted, then it might work out. OTOH, would it also police display 
names when the From of the msrp message contained an actual participant 
AOR rather than a nickname? I don't think it could. And the recipient 
can't tell the two cases apart, can it?

> to route private messages.

In this approach the nickname-string is carried in the display name. But 
apparently it isn't policed. Which means I could request a nickname, get 
the corresponding URI, and then proceed to send messages using whatever 
nickname string I want.

And I don't see how the recipient knows when a message carries a 
nickname, in contrast to a From in the msrp that carries the senders AOR 
and an arbitrary display name that wasn't intended to be a nickname.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 9 Aug 2007 13:49:57 -0400

Okay, no replies.  Perhaps the day job beckons.  Anyway, I propose that we
change the msrp-chat text on nicknames to say:

Set-Nickname takes a string; the proposed nickname
The response is an anonymous URI with the nickname as the display name.

The URI can be used, as described, in msrp From:/To:

The conference package extension includes the anonymous URI with display
name.  I'd actually prefer to have the conf package have the string distinct
from the URI, but I would accept just using display name of the URI.

I think that the msrp-chat mechanism should say explicitly that it does not
support name collisions (it implies it by the errors).  I think it should
say that as defined in this document, the URI is only valid in the context
of the chat in which it was used.

Then I think the generalized mechanism basically does the same thing using a
SIP header.  It WILL allow collisions.  It WILL allow the URI to be used
outside the session, at the option of the minter.  The SIP mechanism will
have an AoR and a domain, which is used for validation.  The Set-nickname
has the optional AoR.  We'll define an operation (probably not a SIP
mechanism) to ask the domain if the nick is valid for that AoR.

Brian

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2007 11:35 AM
> To: 'Paul Kyzivat'
> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI
> 
> > > shouldn't affect what YOU see.  I may be aware of my nick's domain,
> but
> > you
> > > are not.
> >
> > > This, to me, is the problem with your position on this issue.  You
> want
> > to
> > > having the same nick.  You think the UI can deal with the nickname
> part,
> > but
> > > not a construction rule using the nickname, but rather just a URI
> minted
> > by
> > >>> I propose that msrp-chat not allow nickname collisions.  If two
> users
> > do
> > >>> URI has to be minted that is unique.  We don't have to specify how
> to
> > do
> > >>>>>>> I think this leads to users not understanding why their
> nicknames
> > >> work
> > >>>>>> different domains that the server controls, if it wants to do
> that.
> > >> It
> > >>>>>> and always get it, even if someone else also has the same
> nickname
> > >> from
> > >>>> the entities doing the requesting are really the same in some
> sense.
> > If
> > >>>>> Of course, it would also reject, with the same error, if the
> domains
> > >>>> were
> > >>>>> the same,
> > >>>>>>> the clients.  You can't avoid them.  Collision really is the
> name;
> > >> the
> > >>>>>>> domain MAY help you, but since it can't fix the whole problem,
> it
> > >>>> isn't
> > >>>>>>> useful.
> > >>>>>>>
> > >>>>>> because of needing to sort out what happens when two people
> request
> > >> the
> > >>>>>> same nickname.
> > >>>>> In msrp-chat, I want it to not be allowed.  If two users request
> the
> > >>>> same
> > >>>>> problem we are discussing: same nickname, different domains,
> cannot
> > >>>> exist.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 9 Aug 2007 16:49:40 -0400

My email server was borked and I didn't get the email from Miguel and Paul,
so this email is more or less not relevant any more.

Brian

> Sent: Thursday, August 09, 2007 1:50 PM
> To: 'Brian Rosen'; 'Paul Kyzivat'
> > > > Miguel, you think that there can be UI collisions.  You worry that
> if
> > we
> > > > I'd like to point out, as I did with Paul, that users won't really
> be
> > > aware
> > > > Most importantly, whether I register a nick at some external domain
> or
> > > not
> > > > not allow a local domain to have two users with the same nick, but
> you
> > > are
> > > > I think, to a user, the cases look the same, and especially to a
> user
> > > who
> > > > did not register their nick with an external service, they may be
> able
> > > to
> > > > Suppose that nicknames were associated with a URI, but the
> association
> > > was
> > > >> You guys had a long discussion while I was sleeping. I'll try to
> get
> > my
> > > >>> 3. I propose that the generalized mechanism allow an external
> domain
> > > to
> > > >>> permit it, but I don't see a fundamental reason why we would
> accept
> > > two
> > > >>> users with the same nicknames in the local domain, but not two
> users
> > > >> with
> > > >>>>>>> My nickname is joebob.  Your nickname is joebob.  Neither of
> us
> > is
> > > >>>>>>> registered.
> > > >>>> OK. That helps. But then I think your desires are inconsistent,
> or
> > > else
> > > >>>>>> The conf server could hand out two nicknames that are both
> joebob
> > > in
> > > >>>> OK, if you want to make that rule for the msrp mechanism, then
> that
> > > is
> > > >>>> ok, so long as you then only allow one request for a given
> nickname
> > > to
> > > >>>>>> In that case you *do* *have* the nickname joebob in some
> domain.
> > > Its
> > > >>>> up for a nickname vs not doing that and just trying to get one
> when
> > > >> they
> > > >>>> And if you want, you can make a rule that an msrp nickname
> request
> > > will
> > > >>>> nickname that "clashes". BUT, that isn't a complete solution
> unless
> > > you
> > > >>>>>> the same server? If so, the protocol and the UI can't
> distinguish
> > > >> them
> > > >>>> There can be collision on assignment, and there can be collision
> on
> > > >> use.
> > > >>>> names, for *use*, not assignment. I agree you can go either way
> on
> > > >> that,
> > > >>>> different - that is the point, and there is no way to forbid it
> if
> > > the
> > > >>>> or users of the system will not be able to make any sense of it.
> I
> > > >> think
> > > >>>> *if* all the sessions belong to the same user, whatever that
> means.
> > > Its
> > > >>>>>>> You would have to know that I registered my nick somewhere
> else,
> > > so
> > > >> my
> > > >>>>>> URI
> > > >>>>>> This would be no different than me being the 2nd user rather
> than
> > > the
> > > >>>>>> first to show up.
> > > >>>>>>
> > > >>>>>> You think this is unacceptable, but I find it way more
> acceptable
> > > >> than
> > > >>>>> the domains are different, then it's easy.  If the domains are
> the
> > > >> same,
> > > >>>>> more work is needed.
> > > >>>>>> No. I think this is lapping over to the msrp-chat nickname
> issue
> > to
> > > >>>>> nickname, I want an error on the second (and succeeding)
> requests.
> > > >> The

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 9 Aug 2007 17:08:26 -0400

Only the generalized mechanism has a validity problem.  We need an AoR or
other URI specified in the generalized "Set-Nickname" along with the domain
of the nickname service.  The validation operation asks the domain to
validate that it assigned the nickname to someone with that URI.
I don't think we loop the SIP signaling through the nickname service.  I
think we use a non-sip mechanism for validation.

I think that using display name causes the policing problem that Paul is
worried about.  We could try to fix it with some spec words that says that
UAs have to get nicknames from the conference event package, and not pay
attention to the From:/To:.  I think that way will not really work well, and
I think we would be better off not making the display name of the GRUU the
nickname.  Just make the Set-Nickname specify a string, and the only way a
UA gets the string is from the conference roster in the event package.

That means
Set-Nickname joebob

...
Proposed-Nickname joebob sip:[email-masked];gr=3298sd0d98s

And in the event package:

The generalized one would be
Set-Nickname joebob [email-masked] nicks.example.com

with the same return.

I guess I can live with having the msrp mechanism handle collisions.  I'd
rather make this a feature of the generalized system and keep the msrp
system simple, but I think there is a problem with backwards compatibility
with that: the conference server would have to know that all participants in
a conference were able to handle the generalized mechanism before it allowed
a conflict.  But of course it starts handing out nicknames before it knows
that.  If we require all UIs to handle collisions from day 1, we don't have
that problem.

Brian

> Sent: Thursday, August 09, 2007 10:04 AM
> To: Miguel Garcia
> >> but you
> >> want to
> >> part, but
> >> minted by

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Aug 2007 17:51:31 -0400

I think we might be getting close!

> think we use a non-sip mechanism for validation.

That works as long as we accept that nicknames are only usable through a 
conference focus. While it might be nice to go beyond that it seems a 
reasonable restriction. It also means that you trust the conference 
focus to properly represent the identities. But if you are using a 
conference server with a star architecture then you already trust it, so 
there is no extra loss here.

> worried about. 

Yes.

> We could try to fix it with some spec words that says that

That solves the problem. It does however impose the limitation that even 
with msrp-only conferences that are being addressed here it will still 
be necessary to use the conf event package. Is that ok?

> Proposed-Nickname joebob sip:[email-masked];gr=3298sd0d98s

Note that this approach opens the possibility of separating nicknames 
and anonymity, which I think is an excellent thing.

If you want anonymity, then request that the focus assign you an 
anonymous URI (which can be a gruu it constructs). You could then use 
that instead of your actual address.

If you want to use a nickname, then simply ask to use your chosen 
nickname within the conference. If it is accepted then it will be made 
available in the conf event package.

You could use an anonymous URI, a nickname, both, or neither. There will 
be many circumstances when using nicknames without anonymity is desirable.

Separating them will require some added syntax.

> Set-Nickname joebob [email-masked] nicks.example.com

So "nicks.example.com" is the nickname service? and 
[email-masked] is the AOR bound to the nickname?

I don't see why you need to provide the AOR in this request. It will 
need to be provided by the focus when it requests verification from 
nicks.example.com. But the AOR it provides must be the identity it 
authenticated you with when you connect to the focus. So it is 
presumably your sip From address or perhaps the P-Asserted-Identity, 
depending on the authentication mechanism in use.

IMO it might as well just be

	Set-Nickname joebob
   or	Set-Nickname [email-masked]

The first form means you want to focus to use a service of its choice, 
and do an assignment as well as a verification, while the second form 
says you only want it to do a verification at the specified domain.

And of course there is no reason why we couldn't allow both forms in 
MSRP as well. (The server can reject the request with a domain if it 
doesn't accept that form, or if it doesn't know how to verify with that 
domain.)

With anonymity, as well, the syntax might be:

	Set-Nickname joebob;anonymous
   or	Set-Nickname [email-masked];anonymous

And I guess you would get the URI via the conf event package too.

But I'm not remembering how anonymity works in the conf event package 
now. As I recall, there is some way to be anonymous, which I guess means 
no URI is visible for me in the conf event package. But in that case 
what shows up in the From in MSRP?

Maybe one of you who knows more about the conf framework can better 
suggest how to separate these.

> that.  If we require all UIs to handle collisions from day 1, we don't have

Right. The backward compatibility is the killer. We have the opportunity 
to avoid the problem now.

	Thanks,
	Paul

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 10 Aug 2007 10:19:54 +1000

(apologies if you get a duplicate of this email. The first one got held up
for moderator approval due to size of email)

I think I'm ok with this.

I have one suggestion regarding scope. To keep things simple for MSRP, can
we keep external nickname assignment out? For MSRP, I think having the chat
server itself assign nicknames for now is good enough. If you want to join a
chatroom, you have create a nickname within that chatroom domain.

For the general mechanism that Brian is working on, we can tackle external
nickname service issues.

What do you guys think?

Hisham
 - Hide quoted text -

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 9 Aug 2007 20:46:36 -0400

In line.  Indeed we may be close.  Need to hear from Miguel.

> Sent: Thursday, August 09, 2007 5:52 PM
> To: Brian Rosen
Well, it can also work in a simple two way call if that is interesting.
It could also work with a PUBLISH for presence if that was interesting
I think your point is that if someone needs to see the nickname, either the
UA asserting the Set-Nickname has to be sending it to the entity that needs
it, or something like the conference package has to be available to get it.
I think that is okay.

> be necessary to use the conf event package. Is that ok?
See above.  You can use it directly, or with conf event, or something
similar, and I am okay with it.
> available in the conf event package.
Sure.

> be many circumstances when using nicknames without anonymity is desirable.
Agree
> Separating them will require some added syntax.
Okay.

> [email-masked] is the AOR bound to the nickname?
Yes

> depending on the authentication mechanism in use.
I'm not sure that will always work.  Suppose, for example, that the AoR you
use in your From: is what you registered your nick with.  Let's say the
service you send your INVITE to the conference with adds a P-A-I and it's
different in some way from the registered URI.  The conference server would
have to know to use From: and not P-A-I to validate.  If you specify to the
conference server what the URI is registered under, it can make a policy
decision if it will accept that.  Without being explicit, it would have to
do something like try both of them and see if one worked.  Yuck.

> doesn't accept that form, or if it doesn't know how to verify with that
I'd prefer to make that an extension to the MSRP mechanism rather than
defined in msrp chat.  I don't want to hold up msrp-chat while we figure out
the validation mechanism.

> And I guess you would get the URI via the conf event package too.
I'm okay with the anonymous, and I agree you get the URI with the conf event
package

> what shows up in the From in MSRP?
RFC4575 says the URI is an actual anonymous URI
(sip:[email-masked]).
> suggest how to separate these.
xcon-framework doesn't add anything to this.

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Aug 2007 08:47:08 +0300

> suggest how to separate these.

The answer is in RFC 4579:

    A focus MUST support a participant's request for privacy, either
    through conference policy or as expressed through the signaling.  For
    example, a participant joining a conference and including a Privacy
    header field [10] must not have identity information revealed to
    other participants by the focus.  If other signaling protocols are
    used, privacy signaled through them also must be respected.

So, if the UA sends an INVITE with Privacy: id, then the focus MUST not 
disclose the SIP AoR through the conference event package.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Aug 2007 08:48:39 +0300

> to avoid the problem now.

We also agree that endpoints need to be able prepared for handling 
collisions. No doubt. This will happen from day 1.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Aug 2007 08:49:31 +0300

Hisham Khartabil wrote:
> I have one suggestion regarding scope. To keep things simple for MSRP, 
> can we keep external nickname assignment out? For MSRP, I think having 
> the chat server itself assign nicknames for now is good enough. If you 
> want to join a chatroom, you have create a nickname within that chatroom 
> domain.
>  
> For the general mechanism that Brian is working on, we can tackle 
> external nickname service issues.
>  
> What do you guys think?
> 

Yes, agreed. This has always been the assumption.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Aug 2007 09:24:02 +0300

I think I am ok with Brian's e-mail below. To summarize, for people who 
are bored of following the discussion, and to confirm myself, I believe 
we agreed:

For the MSRP reduced scope (only nicknames resolved to the conference 
focus). Let's analyzed the simplest sunny case:

a) Setting the nickname:

- The NICKNAME method is the mechanism to bind a nickname-string with a 
temporary SIP GRUU allocated by the conference server.
- The NICKNAME method contains a Set-Nickname header
- The Set-Nickname header contains the requested nickname-string. Example:

   Set-Nickname: joebob

- The focus/mixer assigns a GRUU which is valid for the duration of the 
conference. The GRUU resolves to the conference focus and obfuscates the 
SIP AoR of the user.

- The 200 OK for the NICKNAME method contains a header, perhaps 
Nickname, that contains the assigned URI (GRUU). Perhaps something like 
this:

    Nickname: joebob <sip:[email-masked];gr=3298sd0d98s>

b) Learning participant's nicknames

- The focus disseminates the nickname (string and URI) in the conference 
event package. We spoke about separated elements.

- Endpoints need to be ready to receive collisions in nickname-strings

c) Using the nickname:

- From and To headers in CPIM can contain nickname URIs. They never 
carry nickname-strings, which are only bound at the endpoints and the 
conference server.

- Side effect: It is also possible to use the nickname URI outside the 
conference, for example, in a MESSAGE, while the user is participating 
on it.

I thought a bit about the anonymity parameter in the Set-Nickname, but I 
think it is not required for MSRP chat, but just for the generalized 
mechanism. The reason: the returned nickname-URI (GRUU) is always 
anonymous, at least, you cannot derive the SIP AoR out of it. The user 
selects the nickname-string, so he can set any random string, if he 
wants to remain discontinued from being "joebob".

Comments?

/Miguel

---

From: Aki Niemi <[email-masked]>
Date: Fri, 10 Aug 2007 09:56:43 +0300

Inline.

>    Nickname: joebob <sip:[email-masked];gr=3298sd0d98s>

??

So why the heck would the user even bother with the NICKNAME method, if
it anyway ends up getting a GRUU from the focus.

I see we're now back to using display-names as nicks... That is not how
the rest of the world works. Sorry.

> - Endpoints need to be ready to receive collisions in nickname-strings

Don't agree. I don't think it is at all reasonable to assume UIs handle
collisions like this, i.e., that you don't require nicks to be unique.

First, I saw someone suggest a UI could show as a popup the URI if one
hovers over the roster. With what do you hover over a URI if all you
have is a 12-keypad and two softbuttons?

Second, are users immediately supposed to see that
<sip:[email-masked];gr=3298sd0d98e> and
<sip:[email-masked];gr=76d6589d77e> are indeed a different
user, although both have "joebob" as display name? Excuse me, but only
geeks handle hex that well.

Third, doing automatic suffixes like joebob(2) and so on will just
create nonsense as soon as someone sets their display name as joebob(2).
And I don't even want to go into explaining how some UTF-8 strings look
the same when aren't.

Why?

> conference, for example, in a MESSAGE, while the user is participating

This doesn't depend on whether the URI is a simple:

<sip:[email-masked]>

or some GRUU.

> wants to remain discontinued from being "joebob".

Again, that's not a nickname any more. Please take a look at XMPP MUC or
IRC as a reference of what a nickname is. As interesting as it may be to
reinvent wheels, the SIMPLE WG is about 20 years late in this field. I
think it's a bit too late to rethink the essence of the nickname.

One key decision we would however need to reach is whether a nick is
scoped to a chatroom or the chat server. XMPP seems to have the former
model, whereas IRC has the latter. I have no idea what model we have here.

My proposal:

Nicknames are *always* scoped to the conference server (like in IRC).

Nicks are reserved so that the server enforces uniqueness. (In fact, it
can even enforce its own policies, like disallowing nicknames that look
too similar. Some systems do that today.)

The nickname is a simple string (SIP URI userpart ABNF production rule),
and each participant is accessible from the outside as well, using the
nick in the userpart of the chat server URI, e.g.:

<sip:[email-masked]>

There is no such thing as an external nickname. By definition, nicknames
are additional handles that participants at a chat server may have.

However, to gain anonymity, a user might join with an external identity
as their *real* ID. For example, instead of my INVITE being from
sip:[email-masked], I would join as
sip:[email-masked], if the server
allows it.

Is there a specific reason why the above would not be acceptable?

Cheers,
Aki

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 10 Aug 2007 09:56:04 -0400

In line.  We're not quite there

> Sent: Friday, August 10, 2007 2:24 AM
> To: Brian Rosen
You only get the GRUU if you request anonymity.  If you don't the URI would
be your AoR which you entered the chat with.

> conference. The GRUU resolves to the conference focus and obfuscates the
If you request anonymity

>     Nickname: joebob <sip:[email-masked];gr=3298sd0d98s>
Yes, although the URI occurs only if you request anonymity

Yes
Yes
> carry nickname-strings, which are only bound at the endpoints and the
Well, of course they can contain the SIP AoR.

> conference, for example, in a MESSAGE, while the user is participating
Did we agree to make this mandatory or optional depending on policy at the
server?  Of course this applies to the GRUU.

> wants to remain discontinued from being "joebob".
Well, that is because you thought you always got the GRUU.  I don't see why
you get the GRUU unless you request anonymity

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 10 Aug 2007 10:13:52 -0400

Sure would have been nice if you had chimed in a while ago :(

> From: Aki Niemi [mailto:[email-masked]]
> Sent: Friday, August 10, 2007 2:57 AM
> To: Miguel Garcia
> Cc: Brian Rosen; 'Paul Kyzivat'; 'SIMPLE mailing list'
It's not a display name.  It can't be a display name.  Look back through the
thread.  You can get a GRUU associated with this nickname which you can use
in an msrp From:/To: to effectively send via nickname.

The nickname is a string, the GRUU is an address.  They are linked. 
Now, indeed we have some confusion, because I think you only get the GRUU if
you ask for anonymity.  If you do that, the only identity other chat members
get is your nickname and the anonymous GRUU associated with it.  You display
the string, and use the URI if you want to send a message to that user.

> And I don't even want to go into explaining how some UTF-8 strings look
That's a local UI issue, and it's pretty straightforwardly solvable except
when a user intends to defraud.  Then it's not so easy.  So far, we're not
addressing that issue, but it deserves at least a mention in the security
considerations sections.

> > carry nickname-strings, which are only bound at the endpoints and the
It stems from the non-uniqueness property, but generally, From/To has
addresses and not strings

> <sip:[email-masked]>
You are correct, although your example doesn't work if the server at
chats.example.com is hosting lots of conferences and the domain of the
conference is [email-masked].  Read back in this thread where we
have talked about URI construction using nicknames.  We concluded that is a
bad idea.  If you need an address, we provide a GRUU, or you can use the
AoR.

> model, whereas IRC has the latter. I have no idea what model we have here.
We have decided they can be scoped to the chatroom.  Policy or
implementation can restrict it further, but the clients have to work if it's
scoped to the chatroom.

> Nicknames are *always* scoped to the conference server (like in IRC).
I disagree with this limitation

> too similar. Some systems do that today.)
We believe that since we will allow non-uniqueness some times, we want all
clients to deal with the problem from day 1.

> <sip:[email-masked]>
This doesn't work if the scope of the nickname is the chatroom

> are additional handles that participants at a chat server may have.
We're not promoting external nicknames in msrp-chat.  The generalized
mechanism will support that idea.

> sip:[email-masked], if the server
We discussed requiring external anonymous URIs as the only anonymity
mechanism; I don't think this is adequate.  The chat server should be able
to maintain anonymity.  The proposal we have does that inexpensively (the
chat server can provide an anonymous GRUU to be linked with a nick if the
user desires anonymity.

> Is there a specific reason why the above would not be acceptable?
Yes, see above

---

From: Aki Niemi <[email-masked]>
Date: Fri, 10 Aug 2007 17:48:52 +0300

Inline.

> The nickname is a string, the GRUU is an address.  They are linked. 

You say the nickname is a string for which no-one guarantees uniqueness.
 A non-unique string does not a unique handle for the user make.

> the string, and use the URI if you want to send a message to that user.

In other words, now the user does *not* get to pick its nickname (and
know that nobody else can use that same nickname), and instead the
server generates one for the user. Completely opposite to how Jabber and
IRC work.

> addressing that issue, but it deserves at least a mention in the security

Sure it's a local issue. But guess what happens if, say, the Psi
developers ever find out about the SIMPLE chat spec and (lo and behold)
try to accommodate it into their *existing* UI.

And in any case, nobody has yet to demonstrate what is so horribly
broken with the way existing systems use nicknames so that SIMPLE needs
to muck with it.

> addresses and not strings

What you say has no bearing on how that URI is generated. The nickname
can just as easily be part of that address.

> conference is [email-masked].  

That's not a domain, chats.example.com is the domain. Now granted, in my
model you could not determine whether something was a chat room or a
user just by looking at the URI. But that can easily be solved,
*without* GRUUs. (I will, however, point out that that model would have
its own benefits, like being able to list a sidebar to a room as a
roster item.)

> Read back in this thread where we

Well obviously I disagree with it being a bad idea.

Ultimately this boils down to a limitation in the SIP URI; we could take
a completely different path and specify a new URI parameter for the
nickname similar to how Jabber handles this (and I believe someone
already suggested that).

I just don't get at which point in this thread we concluded that since
we need the ability for the *user* to select its own nickname, we need
the server to dish out a random GRUU for him. That just doesn't make any
sense to me.

> implementation can restrict it further, but the clients have to work if it's

Fine.

> clients to deal with the problem from day 1.

I have no idea why we would need to allow unique handles for users in
chat rooms to *sometimes* be non-unique. What chat system out there
allows this?

> This doesn't work if the scope of the nickname is the chatroom

<sip:[email-masked];nick="THisChatRoomIsNowpwned">

> mechanism will support that idea.

Again, it we bring this discussion back to current systems, this sounds
like federation, which may not be that relevant since we work with URIs
to begin with.

> chat server can provide an anonymous GRUU to be linked with a nick if the

That still doesn't require a GRUU. It's a simple flag on the server
whether to allow the real ID (the one in your From header field in the
INVITE) to show in the roster or not.

Cheers,
Aki

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 10 Aug 2007 11:15:46 -0400

In line.  It's not so bad Aki, really.

> Sent: Friday, August 10, 2007 10:49 AM
> To: ext Brian Rosen
> Cc: 'Miguel Garcia'; 'Paul Kyzivat'; 'SIMPLE mailing list'
The UI can make it unique any way it wants to.
The word "handle" can be used in a UI sense or a program/protocol sense.
The string is for the UI, the URI is for the program/protocol.

> server generates one for the user. Completely opposite to how Jabber and
I don't know where you got that idea.  The user picks a nickname.  The
server doesn't generate strings, only the URI, and, in my proposal, only if
it requests anonymity. Otherwise the URI is the AoR.

The server MAY, by policy, restrict nicknames to be unique.  The client MUST
handle non unique strings.  We always have unique URIs.

> try to accommodate it into their *existing* UI.
They can either restrict use of their existing UI to existing servers,
restrict to servers that don't allow non-unique nicknames, or be
incompatible with the standard, their choice.

> broken with the way existing systems use nicknames so that SIMPLE needs
Non unique nicknames with local display of something different has been
done, right?  We didn't invent that idea.

> can just as easily be part of that address.
No, it cannot, at least without a lot of mucking around, or the restriction
that uniqueness is to the server and not the chat.  Lots of existing
implementations won't work with THAT restriction.

> its own benefits, like being able to list a sidebar to a room as a
If the domain that nicks must be unique in is the chat, and not the server,
then the domain of the chat is [email-masked].  It is only when
you restrict uniqueness to the server that you can get away with assuming
the domain for the URI has nothing before the "@".  

> nickname similar to how Jabber handles this (and I believe someone
Yes, we went through that discussion.  It's possible.  The current proposal
avoids the problem in a different way.  It simply doesn't use the string in
the URI.

> the server to dish out a random GRUU for him. That just doesn't make any
In my proposal, you only get the GRUU if you request anonymity.  In that
case, you NEED a GRUU (or something equivalent).  If you don't need
anonymity, then you don't need a URI other than your AoR at all, so don't
make one up.

A nickname needs a string for the UI.  We supply said string.  We don't use
the string to make an address out of.  That's pretty simple, isn't it?

The uniqueness issue is a forward looking one.  If you EVER want to be able
to have non unique nicknames, you need to do it from day one.  

> > implementation can restrict it further, but the clients have to work if

Not so fast.  If it's fine to scope to the chatroom, then you have a
[email-masked] as the domain of the chat, and you are back to a
complex URI construction rule if you use the string in a URI.

> chat rooms to *sometimes* be non-unique. What chat system out there
Again confusion on what a "handle" is.  A UI element that the local UI has
to deal with non-uniqueness of a string locally or a program/protocol
element where we have a unique URI always, but it doesn't have the string in
it?

> like federation, which may not be that relevant since we work with URIs
No, it's not federation.  It's allowing the domain of a nick to not be the
domain of the chat.  This lets you have a nickname registered once and
accepted with multiple services.

> INVITE) to show in the roster or not.
No, you need a unique address to use in msrp From/To which doesn't break
anonymity but can be used to address a message to that anonymous user.  The
GRUU is that address.

Brian

---

From: Aki Niemi <[email-masked]>
Date: Mon, 13 Aug 2007 10:00:47 +0300

> In line.  It's not so bad Aki, really.

Perhaps I'll be the judge of that. ;)

> The string is for the UI, the URI is for the program/protocol.

Again, this is counter to all existing systems, so you better first
explain what is so horribly broken with IRC and Jabber that SIMPLE needs
to behave differently.

> it requests anonymity. Otherwise the URI is the AoR.

I know you have all along argued for this idea that we just use the
display-name for the purposes of a nickname. However, that is not how
current systems work.

> handle non unique strings.  We always have unique URIs.

This is nonsensical. Can you please explain where this requirement for
non-unique nicknames comes from?

> incompatible with the standard, their choice.

Well I tend to think we are here to serve the implementor community, and
not vice versa. If the standard makes no sense, then we clearly aren't
serving them well (especially if we now, after 20 years of running
systems, come up with a concept that says is the same thing but isn't).

> done, right?  We didn't invent that idea.

Where has it been done? Not in IRC or Jabber, so yes I think you did
invent that idea on your own.

> implementations won't work with THAT restriction.

I don't understand. Could you elaborate on which existing systems you're
referring to here, and what exactly you mean by "mucking around"?

> anonymity, then you don't need a URI other than your AoR at all, so don't

Right, I understand you're proposing that we simply use the display name
as a "nickname". In addition, you've proposed this additional mechanism
to request anonymity. This is something you've been proposing as long as
I remember. And as long as I remember, I've said this is *not* how
nicknames work in other systems.

> the string to make an address out of.  That's pretty simple, isn't it?

Simple and useless, I might add.

Can we forget about UIs for a moment? We don't do UIs here, and if you
look at IRC or Jabber, they definitely use the nickname as an
on-the-wire identifier of a channel/chat room participant. Do you disagree?

Now, in your proposal, you use the GRUU as an on-the-wire identifier,
correct?

You must admit these are a different concept altogether.

> to have non unique nicknames, you need to do it from day one.  

The point is, by design, you NEVER want to be able to have nicknames
collide. That's the whole point!

>> <sip:[email-masked];nick="THisChatRoomIsNowpwned">

How is that complex?

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 13 Aug 2007 13:07:32 +0300

> parameter of a URI to write a nickname in the userpart.

How about just specifying a "nickname" parameter? That would avoid
embedding the nick in the userpart, which was I believe something Brian
didn't like.

Also, when you say "reuse the already defined 'user' parameter", this
gives me an instant allergic reaction. Are we really running out of the
URI parameter namespace?

Also, this would be specification reuse -- of a couple of lines in ABNF
at best -- and *not* code reuse. Not worth it.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Aug 2007 10:05:52 -0400

Aki,

I'm not going to respond point by point below, because it will just 
confuse things. (I'm not entirely in line with Brian, or others, yet 
though I thought we were getting close.) But let me explain my reasoning 
behind "non unique nicknames":

- IMO per-chatroom nicknames aren't good enough in general,
   though they may be appropriate in some cases. When there
   is a set of related chat rooms that are visited by many of
   the same people then you would like some confidence that
   a nickname references the same person in all of them.
   (I would not like to be surprised to find that "Aki"
   wasn't you in one ietf-sip-related chatroom.) So IMO there
   must be *some provision* for nicknames to be reserved to a
   particular person on a broader basis than one chatroom.

- If there is an ability to reserve a nickname for multiple
   chatrooms, then there must be some agency responsible for
   doing so. But we certainly don't want to endorse a single
   such agency. If there are to be multiple agencies assigning
   nicknames, then nicknames will only be unique within a
   particular agency.

- If I have reserved my nickname with some particular agency
   then, IMO, I should be able to use that with any chatroom.
   The set of chatrooms frequented by a community of users may
   not all be managed by the same entity. In this case, two
   users may have reserved the "same" nickname from different
   nickname agencies. And these may be used in the same chatroom,
   leading to a "collision".

As I was originally conceiving this, the nicknames were all scoped by 
the name of the assigning agency (a domain name). (Note that this is 
entirely compatible with a chatroom serving as a default nickname 
assigning agency for participants.) Hence as long as you consider the 
nickname to include that domain name there aren't really any collisions. 
It is only if you choose not to display the domain name part that there 
are collisions. I considered that to be a UI issue that could be solved 
in many ways.
- there could be a default nickname agency/domain per room or server.
   The UI could suppress the default domain when displaying nicknames,
   but display it (using "@" notation) otherwise.
- When displaying nicknames, a UI could suppress the domain from all
   nicknames from the same domain as the user's own nickname.
- The UI could suppress the domains of all the nicknames, but assign
   a suffix (e.g. (2), (3)) to distinguish duplicates, or display
   duplicates with different colors, etc.

Personally, I think that concept would still be entirely workable. But I 
have been able to agree with some of the other ideas that have been 
proposed.

A somewhat separate issue has been the routability of nicknames. The one 
part of that which has been present from the beginning of the proposal 
from you guys has been routability via MSRP via the To address in the 
CPIM header. While I don't have a particular problem with that I find it 
limiting since it only works for IM. If nicknames are to be routable for 
one medium then I think they ought to work for other media as well. In 
general I think that means that they must be usable for routing sip.

If nicknames were always of the form <name>@<domain> (before the UI 
fiddles with them for display purposes) then it is natural to think that 
they could be turned into a URI, like sip:<name>@<domain>, and then be 
routable. If the domain happens to be served by the same server that 
handles a chatroom, then participant status in a chatroom can be used to 
influence the routing rules. If the domain server doesn't happen to be 
collocated with a chatroom it can still forward requests using a variety 
of interesting policies.

However others wanted to separate the routability from the name itself. 
Hence there came the notion of having the *usage* of a nickname in a 
conference be associated with some routable URI. The nickname is of 
course associated with a participant, and hence with the contact address 
of that participant. So, if you want to route something to a participant 
you have selected by nickname you could route to the corresponding 
contact address. But if the participant chooses to be anonymous, then 
that doesn't work. So, somebody suggested having the focus assign 
surrogate contact addresses (gruus) for those participants that choose 
to be anonymous. While this wasn't my original concept, I have no 
problem with it. It seems to work fine, and separates the nickname for 
routability. That means that external nickname agencies don't have to 
deal with that.

Brian took that one step further: Qualification of a nickname with a 
domain is only necessary during the process of associating a nickname 
with a conference participant. That domain need not be exposed to other 
participants. Instead, other participants see only the name part, and 
distinguish them based on their routable contact address - either the 
real one or the surrogate gruu. His motivation (if I can put words in 
his mouth) seemed to be to allow multiple participants to use the same 
nickname (the displayed part) even if they were all using the focus 
itself as the nickname assigning agency.

Personally I could care less about this last aspect. I think it has the 
downside of preventing some participants from making multiple 
connections and having them be perceived as being from the "same" 
person. And I don't especially care about using the focus as the 
nickname assigning agency - I think it is a mechanism that should be 
supported but rarely used. (But that is just my opinion. I'm happy for 
others to feel differently.)

Separating the nickname from the URI used for routability doesn't turn 
the nickname into a display name in the way that we have come to know 
and love display names in sip. The key difference is that the nickname 
usage is controlled and authorized, so that participants have a set of 
useful conclusions they can draw when they see particular nicknames.

IMO there is probably still a bit of fine tuning to do here, but we are 
on a productive track that can result in something that works for chat, 
works for other conferences, is flexible, is reasonably easy to 
implement, and that can have a reasonable UI.

To be constructive, I'll suggest the following, picking from things that 
have already been discussed in this thread:

- The MSRP nickname request be allowed with either just <name> or with
   <name>@<domain>.

- The name-only form is a request to assign the name within
   a domain unique to the focus, for the duration of participation, and
   then associate it with the participant. This can fail if the name
   is already in use by a participant with a different identity.

- The <name>@<domain> form requests that the focus verify with a
   server for the domain that the requester is allowed to use
   the nickname, and then associate it with the participant.
   This can fail if the focus doesn't support it, if it doesn't
   know how to do verification with that domain, or if verification
   fails.

- Eventually there will be some other, more general, mechanism for
   doing temporary nickname assignment and nickname association,
   independent of MSRP. That is still TBD.

- Nicknames don't appear in CPIM From/To headers. Instead, the
   sip contact address of the participant appears. If the user is
   anonymous, then a surrogate URI provided by the focus appears.

- The association between nicknames and contact addresses is learned
   by each participant via an enhancement to the conference event
   package. The nicknames delivered this way always are of the
   <name>@<domain> form.

- The chat UI is responsible for obtaining nicknames corresponding
   to received messages and rendering them in a user-friendly way.
   If this is burdensome, we could consider having the focus
   include the nickname as a display name in the CPIM From header.
   (I'm not wild about it, but it is a possible optimization.)

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Aug 2007 18:55:00 -0400

I am okay with all of this.  I assume that:
>    then ..... This can fail if the name
Is a policy issue at the server; the server could have a policy that said it
allowed it.  The UI has to cope.

Brian 

> Sent: Monday, August 13, 2007 10:06 AM
> To: Aki Niemi
> Cc: ext Brian Rosen; 'Miguel Garcia'; 'SIMPLE mailing list'

---

From: Aki Niemi <[email-masked]>
Date: Wed, 15 Aug 2007 15:36:19 +0300

I think you are unnecessarily mixing what is put in the From field of an
INVITE with having a nickname in a certain chat room. If you really want
identities to stick, and also be of "external" origin, then obviously
the SIP URI that you put in the From gives you exactly these properties.
You should not confuse that identity with the nickname.

In the model I am assuming, the nickname is an *additional* handle that
users can pick for themselves in certain chat rooms. In fact, I'd really
like to scope these nicknames to the chat server, simply because that's
the model IRC has and then basically you get rid of this ambiguity of
having  the 'Aki' in sipwg chat be different than the 'Aki' in the
apparea chat. This would also mean that the namespace on the chat server
is shared by both the rooms and the nicks, but I think that's completely
fine.

I also strongly feel that if you don't agree with the above model for
nicknames, then ultimately we are better off ignoring them and just
using SIP URIs as identities in MSRP chats rather than inventing our own
way of doing nicknames using the display-name (and possibly GRUU) that
is incompatible with current systems. Perhaps we could just use SIP to
invite to an IRC session or perhaps a Jabber session to interwork with
the "legacy" systems.

But let me repeat it one more time: this is *not* some trivial user
interface trick; nicknames are used as on-the-wire identifiers of chat
room participants in current systems. I've yet seen anyone dispute this
fact.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2007 15:01:52 -0400

> allowed it.  The UI has to cope.

Yes. By saying "may fail" I was explicitly not saying "must fail". 
However if there have been two requests for the same nickname, and they 
aren't from sessions of the same user, then if they both succeed then 
each must be assigned a different domain name part of the nickname, so 
that the full nickname is unambiguous. This can be arranged by the focus 
managing multiple domains for nicknames. Whether any implementation 
would actually want to do this is tbd.

But the UI must cope, with two situations:
- multiple nicknames that differ only in the domain part
- having a requested nickname be rejected

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2007 18:32:51 -0400

> You should not confuse that identity with the nickname.

I never mentioned the From field of an INVITE in what I wrote.

I did mention "identity" once which isn't quite the same thing. I do 
believe that nicknames serve as a representation of identity. In general 
I decide who I am chatting with by the nickname I see. If that isn't who 
I think it is I may say something inappropriate. So it is important. 
Similarly, it is proposed that messages be delivered to destinations 
identified by nickname. Again its important that the binding to a 
nickname be understood.

> users can pick for themselves in certain chat rooms.

Maybe I misunderstand and have your opinions mixed up with others, but I 
thought part of your concept is that the actual address of the user can 
be kept confidential, so that other participants will only know that 
user by the nickname. In that case it becomes the *only* handle, rather 
than just an *additional* handle.

In either case, in some sense it is not what is in the protocol that is 
important, but rather what is in the UI. If the nickname is what is 
displayed in the UI, and what the user uses to decide how to target a 
response, then the *real* identity is irrelevant.

> In fact, I'd really
> like to scope these nicknames to the chat server,

Do you mean the *server*, or the *room* (focus)? The distinction is a 
big one. If we make it the *server* then it is like the domain that 
brian and I have been talking about, except that you require users of a 
focus to always use nicknames from a single domain.

> simply because that's

Its still not fine if its FCFS for nicknames based on current 
participants in conferences on the server. Because then we have that 
*today* Aki is you in sipwg and apparea, but when I connect tomorrow the 
Aki I see may be somebody else.

(Yes, I agree that some chat rooms may be run that way, and it should be 
possible to run one that way if you want, but it better not be the only 
way.)

> is incompatible with current systems.

I'm not sure what you mean by incompatible with current systems.
Today we have a variety of chat clients, and a variety of chat 
protocols. Many of the clients support multiple protocols. IMO it is 
important that it be possible to preserve the user experience through a 
given chat client once it has incorporated an adapter to the new 
protocol. What we do in the protocol is less important if we can see how 
the chat client can deal with it. Meanwhile we can have a protocol that 
is adaptable to the new stuff we want to be able to support, such as 
full multimedia conferences, etc.

	Paul

> Perhaps we could just use SIP to

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 16 Aug 2007 00:54:28 +0200

Aki,

> room participants in current systems. I've yet seen anyone dispute
> this fact.

Perhaps, but then probably there's other identifiers in the message (say 
chat session id) that is sent on-the-wire which implicitly scopes the 
nickname

It appears to me that what is being called a "nickname" consists of two 
parts: an identifier and a scope/context. The identifier is typically used 
for display in UIs, the combination of identifier and scope is used for 
addressing/routing (and therefore required to be unique, at least for the 
duration of the chat session). AFAIK most chat systems don't have the 
additional concept of a "displayname" like SIP has, i.e. a string which is 
only used for display but not for addressing (at least not by the protocol, 
it can be used as "addressing" between the user and the UI)

"scope" or "context" here can be the chat room, the chat server, or its 
domain. There is a hierarchy here, and I sense there is consensus on how to 
represent it: sip:[email-masked]. What remains under debate is 
how the "identifier" is added to this base (and then the meta-discussion 
whether this should be mandated, or provided as guidelines or examples).

Uniqueness of the _identifier_ part (i.e. that which gets presented to 
users) across a set of chatrooms, in the same or in different domains, is a 
constraint that could be enforced. It would require some distributed 
protocol, probably best left out of scope / FFS for now. Note that such a 
"uniqueness scope" is not necessarily representable as a (part of a) single 
URI - nor is it required to be. This is _orthogonal_ to the design choices 
for the syntax of the URI.

I would suggest to focus the discussion on the syntax of URIs to be used for 
addressing of users within chat sessions first.

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2007 18:58:17 -0400

> You should not confuse that identity with the nickname.

I thought that for awhile. In particular I did, and still do, see some 
value in a special kind of anonymizer - one that allows me to sign up 
for one, or several, aliases that I can use when I want to hide my true 
identity. If I had that, then I could pick an alias and use it when 
participating in one or several conferences where I want to be 
recognized consistently as the same person without revealing who I 
actually am, and without allowing correlation to my participation 
elsewhere using my actual identity or other aliases.

That could replace some of the use of nicknames. But I don't think it 
will replace it all. That is where I have been educated in this discussion.

In particular, there are cases where the conference organizer will 
insist on actually knowing who the participants are. However it is still 
willing to hide that information from the other participants. That is 
where the nicknames we are discussing become important, because they 
still provide the anonymity properties and other properties I mentioned 
above with respect to other participants of the conference, even if not 
to the administrators of the conference.

	Thanks,
	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 16 Aug 2007 08:13:13 +0200

> I would suggest to focus the discussion on the syntax of URIs to be
> used for addressing of users within chat sessions first.
>

As has been suggested before, I personally think that the URI should be a 
temporary GRUU. By its usage it needs to be globally reachable, and by 
giving the chat server control over the URIs, it is able to mint temporary 
GRUUs that are unique to the user+session in the [email-masked] 
context.

Users could then go ahead and REGISTER their assigned temporary GRUU at 
their registrar, to indicate they are reachable in that virtual room.

I see no need to include the nickname's displayname in the URI. Users could 
omit it to be anonymous (and server could have a policy to not allow that), 
and conference events can be used to learn these displaynames along with the 
temporary GRUU of each user

Regards,
Jeroen

PS Is it possible / there a need to have multiple ongoing sessions per chat 
room?

---

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Aug 2007 12:15:25 +0300

> than just an *additional* handle.

I say additional because it wouldn't be the identity (i.e., your
asserted SIP ID) with which you join the chat room (i.e., the conference
focus). Whether this real ID is shown in the conference event
notifications in addition to the nickname is a somewhat orthogonal
issue, IMO.

> response, then the *real* identity is irrelevant.

I think I agree. But if the nickname is not used on-the-wire to target
the response, then things break.

I'd be really curious to know how it is intended that UI to cope with
colliding nicknames like "Miguel", "Miguel ", and " Miguel", for which
the URIs are all GRUUs. What would the roster of this room look like?

> focus to always use nicknames from a single domain.

I mean the server, like the domain chats.example.com.

> possible to run one that way if you want, but it better not be the only

We're not restricting this in any way. Even in the current draft, it is
possible to either challenge the NICKNAME method, or tie it in with a
specific SIP URI.

As an example, the process by which these nicknames would be made to
stick could be as follows:

1) User gets a nickname by FCFS basis,

2) User sends a private message to the operator/moderator/owner, and
asks to make the nickname stick

3) Moderator does [add any procedure maybe involving email,
return-routability checks, web forms, personal visits, CAPTCHAs,
whatever], creates credentials and sends them to the user via a private
message

4) Now every time the user joins, he is asked to provide said
credentials to get the same nickname

Existing IRC services like FreeNode have something like this; Jabber
could probably accommodate it as well.

> protocols. Many of the clients support multiple protocols. 

Can you name them?

The only two standard group chat protocols I know of are IRC and Jabber.
Can you please elaborate on what the others are? If they are
proprietary, at least it would be helpful to get some idea how close to
IRC or Jabber they are.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Aug 2007 12:40:35 +0300

> chat session id) that is sent on-the-wire which implicitly scopes the

I was proposing:

<sip:[email-masked];nickname="SOmeNickHErE"

> parts: an identifier and a scope/context. The identifier is typically
> used for display in UIs, the combination of identifier and scope is used
> for addressing/routing (and therefore required to be unique, at least
> for the duration of the chat session).

Right.

> AFAIK most chat systems don't
> have the additional concept of a "displayname" like SIP has, i.e. a
> string which is only used for display but not for addressing (at least
> not by the protocol, it can be used as "addressing" between the user and
> the UI)

Yes. I'd also like to point out that the usefulness of the display-name
in SIP is debatable. I certainly would not blindly take the display-name
and show it to a user on an incoming call.

The only name I would show the user is one from the user's own phone
book (could call this a petname). And in the absence of a matching entry
in the phonebook, I'd display the SIP URI. In case of a non-asserted SIP
URI, I'd just tell the user that "Some unknown person, claiming to be
sip:... is calling".

> domain. There is a hierarchy here, and I sense there is consensus on how
> to represent it: sip:[email-masked]. What remains under
> debate is how the "identifier" is added to this base (and then the
> meta-discussion whether this should be mandated, or provided as
> guidelines or examples).

I think we're not quite there yet with the model to be able to discuss
the syntax. Although I don't think deciding on the syntax is rocket
science in this case. :)

> users) across a set of chatrooms, in the same or in different domains,
> is a constraint that could be enforced. It would require some
> distributed protocol, probably best left out of scope / FFS for now.
> Note that such a "uniqueness scope" is not necessarily representable as
> a (part of a) single URI - nor is it required to be. This is
> _orthogonal_ to the design choices for the syntax of the URI.

Clearly, the userparts of SIP URIs can *always* collide; however, within
a single domain they cannot.

I am arguing that if you intend to have the nickname identity exhibit
this global scope (i.e., scope not strictly restricted to either a chat
room or a chat server) then we are better off just using the SIP URIs
that participants have in the From field of an INVITE.

Cheers,
Aki

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Aug 2007 10:08:11 -0400

> notifications in addition to the nickname is a somewhat orthogonal
Why do you need an additional identity to use for addressing other than for
anonymity?  If you want anonymity, then you want an anonymous URI, which a
GRUU from the focus provides.

> the response, then things break.
What breaks other than the issue below?
> the URIs are all GRUUs. What would the roster of this room look like?
Something like
<user entity=[email-masked]>
...
<nickname>Miguel</nickname>
</user>
<user entity=[email-masked]>
...
<nickname>Miguel</nickname>
</user>
<user entity=[email-masked]>
...
<nickname>Miguel</nickname>
</user>

Where the first two are "regular" users and the third is anonymous.

The URIs can be used to address any messages.  The nicknames can be used in
the UI for display purposes, presumably with some differentiation viz.
Miguel(1), Miguel(2),...

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 17 Aug 2007 16:45:03 +0200

Brian,

> <user entity=[email-masked]>

Question: does the 'entity' attribute contain an AoR, or a URI that resolves 
to a user participating in a specific conference session at a specific 
server?
(http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-05#section-4.5.2 
says "The element <user> describes a single participant in the conference", 
it's not clear to me whether that means if the conference context should be 
reflected in the value). Note also that there's no "nickname" element 
defined, only "display-text"

Should the URI be usable outside the context of the conference? Should users 
be able to derive the user's AoR from it?

The XCON framework talks about a mixed protocol conferencing system, so it 
could be that [email-masked] is connected via ISUP. In that case, I 
suppose communication with that user should go via the conference server? Is 
it allowed to "optimize" in case both users use SIP? (would go against the 
centralised model of XCON, right?)

In summary, I think the roster would look something like this (as seen at 
one of the participants):
<user entity=[email-masked];gr=1234>
<display-text>Miguel</display-text>
<associated-aors state="full">
<SIP>
 <uri>[email-masked]</uri>
</SIP>
</associated-aors>
</user>
<user entity=[email-masked];gr=1235>
<display-text>Miguel</display-text>
<associated-aors state="full">
<SIP>
 <uri>[email-masked]</uri>
</SIP>
</associated-aors>
</user>
<user entity=[email-masked];gr=12346>
</user>

The last user had '<provide-anonymity>true</provide-anonymity>', which the 
conference server stripped (along with the associated-aors, for example)

Regards,
Jeroen

---

From: Aki Niemi <[email-masked]>
Date: Fri, 17 Aug 2007 17:58:03 +0300

> the UI for display purposes, presumably with some differentiation viz.

I see. So your implementation decided that stripping whitespace was OK
to determine whether the nicknames were "equal". I see your UI also
decided on one possible scheme to tell them apart.

Let's simulate a running discussion:

[17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to send
a private message?
[17:35:40] Miguel(2)-> Hi all!
[17:36:01] Miguel(3)-> Ping...

Now I decide to reply:

[17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy
and right-click.

Who is Miguel(1)? One client used an alternative scheme with Miguel_1,
Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) at all.

Of course, Miguel(1) has no idea what his nickname looks like in anyone
else's UI. In fact, even the same client implementation may show the
Miguels in different order, depending on when they joined. That means
that Miguel(1) is Miguel(2) in Brian(2)'s screen, but Miguel_2 in
Paul(3)'s screen, which Aki_1(1) thinks is just a little odd.

BTW, Aki_1(1) used to be just Aki_1 (he picked that nickname since there
already was an Aki in the room), until someone else picked Aki_1 as
well, at which point he became Aki_1(1). Or something.

Of course, a sane client would probably just drop the nickname (which at
this point is a useless piece of information) from the UI and use the
URI instead:

[17:35:05] [email-masked];gr="fe433e334a"-> Hi all!
[17:35:10] [email-masked];gr="66d7e67ac7"-> Howdy!

And so on. I guess I will then reply with:

[17:36:50] [email-masked];gr="76276dc78a"-> 66d7e67ac7: let's
get out of here. I created an IRC channel for us.

This is how things break. This is all pretty obvious if you've used IRC.

Cheers,
Aki

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 17 Aug 2007 17:09:14 +0200

Aki,

Obviously, a sanely implemented client would make sure that any local 
conventions for dealing with duplicate nicknames are never sent across the 
wire. So in your example, what in your client gets displayed as "Aki -> 
Miguel(1)" would appear e.g. as "Aki [reply] -> Nope..." at other 
participants (depending on the conventions that their client implementation 
is using

The scenario above could occur when clients would have the bad habit of 
including local displaynames in messages they sent (I know some chat clients 
do this). For MSRP chat, the draft could state that they SHOULD NOT do this.

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Aug 2007 11:27:58 -0400

Sorry - I haven't been keeping up with comments (busy doing my day job).

In the below, I do think this is an issue of UI design, and some may be 
better than others.

This is a good example of why nicknames should be tied to domains, with 
only one valid per domain. Then at least one UI that can be 
comprehensible is that nicknames are displayed *with* the domain except 
for one default domain, where they can be suppressed. For instance the 
default domain could be the domain the user's own nickname is with, or 
it could be the default domain of the chat room. (The defaulting rule is 
itself part of the UI design.)

So in this case perhaps ietf.org is a nickname domain, and [email-masked], 
[email-masked], [email-masked] and [email-masked] are all owned by us. 
When participating in chat rooms related to ietf business (whether 
hosted by ietf, softarmor, columbia, or whatever) we might see these 
nicknames as just "aki", "miguel", "paulk" etc. If there was another 
participant with the nickname [email-masked] then he would indeed be 
displayed as "[email-masked]", so there would be no confusion.

We shouldn't be specifying UI design here. But its useful to convince 
ourselves that reasonable UIs are feasible. So far I am convinced they are.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Aug 2007 11:28:29 -0400

> decided on one possible scheme to tell them apart.
Yes.  I think trying to display spaces as differentiation leads to
confusion, but your client could do anything it wanted to.

> Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) at
In my example, I used two "regular" URIs and one anonymous one.  You
happened to choose one for which we could show you a URI if we wanted to.
In general, since this chat allows nickname collisions, what you know as
Miguel(1), someone else might know as Miguel_1, or Miguel with a red
background.  So what?  Your example works.  You can send a message to the
Miguel who asked the question.

In particular you have zero extra information if the chat server enforced a
no conflicts rule, and assigned unique nicks. 
> Paul(3)'s screen, which Aki_1(1) thinks is just a little odd.
Why?  There are more than one Miguels.  You have a way to keep them
straight.  If you say "Miguel", you don't know which one. You can send a
message to any of them, unambiguously.

To get in trouble, you need to have an exchange where you are type what you
see
Aki(1): No, I meant to say Miguel(2) is wrong.

Then you might have a problem.  I don't see that as really difficult.
If you get too confused, ask the Miguels to choose different nicknames.

> well, at which point he became Aki_1(1). Or something.
Yeah, so?  There is no more (or less) confusion, and you can address
messages to the right one.

> [17:35:10] [email-masked];gr="66d7e67ac7"-> Howdy!
Well, you can write a client that did that.  I wouldn't.

> This is how things break. This is all pretty obvious if you've used IRC.
I've used IRC a lot.  I find it really confusing.  I like AOL and other
systems where my nickname sticks and when you see br65535, you ALWAYS know
it's me.

My client may even use
br65535(aol) and br65535(gmail) in the obvious circumstance.

Brian