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

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 3 Sep 2007 12:51:52 +1000

I've read this thread and seem to agree mostly with Aki, but I think Brian
and Paul have some valid points.

I think the system should be designed as follows:

- Agencies: No external nicknames (I think it defeats the purpose of having
a nickname if external ones are allowed). Effectively I'm saying that every
domain runs its own nickname agency and to join one of its chatrooms, you
need to create a local nickname.

- Scope: nicknames are reserved per domain. I want to participate in one or
more chatrooms serviced by the same domain discussing slightly different
topics. People certainly do that in IRC today and we don't want that feature
to disappear. Also, I don't want to go reserve my nickname 10 different
times in 10 different chatroom in the same domain.

- Permanency: a nickname is temporary in nature until the user exits the
domain (logs off). A user can reserve a permanent nickname by doing an out
of band transaction with the domain administrators. Perhaps the domain wants
you to pay $$$ for doing that.

- Uniqueness: I think nicknames should be unique. There seems to be people
who want clashing nicknames. Fair enough, different people have different
agendas. So, I think its a fair compramise if we allow collisions, but
device a mechanism for servers force nickname uniqueness and rejects
conflicting nichnames (error responses etc).

- Routability: I don't see myself joining a chatroom and wanting to display
my AoR, but some people might want to in order to enable other users to
contact them directly for private messages outside the chatroom service,
invite them to a voice call or whatever media. In this case, an AoR display
in warranted. For me, I will request anonymity, for Brain, he will not and
will diplay his AoR to the rest of the participants. A compramise is to have
an AoR  as well as a routable nickname. A user is reachable on both. AoR is
used to reach a user directly, the nickname is used to reach the user via
the chatroom. Perhaps diplaying both for users not requesting anonymity and
just the routable nickname for those who do request anonymity.

One problem, however, is present in the last point: since some servers will
allow collisions in nicknames, a nickname can no longer be routable (if 2 or
more users sharing the same nickname are all anonymous) and therefore
requires a uniqueness attribute.

Regards,
Hisham

On 18/08/07, Brian Rosen <[email-masked]> wrote:
>
> The "generalized" mechanism will (eventually) have a way to authenticate a
> nickname at a domain against an AoR.
>
> Brian
>
> > -----Original Message-----
> > From: Jeroen van Bemmel [mailto:[email-masked]]
> > Sent: Friday, August 17, 2007 12:12 PM
> > To: Paul Kyzivat; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname
> URI
> >
> > > What you want can be achieved by a policy that restricts nicknames to
> > > those in a domain chosen by the conference, having relatively long
> > > term assignments of nicknames in that domain, and not allowing
> > > duplicates within that domain.
> >
> > This would also require authentication of users against that domain
> >
> > Is this needed in the conference data model? Could it work without being
> > standardized?
> >
> > Regards,
> > Jeroen
>
>
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 10:48:12 -0400

_____  

From: Hisham Khartabil [mailto:[email-masked]] 
Sent: Sunday, September 02, 2007 10:52 PM
To: Brian Rosen
Cc: Jeroen van Bemmel; Paul Kyzivat; [email-masked];
[email-masked]; [email-masked]
Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI

<brian>I think you are clear on this: you want to completely disallow a
domain from accepting a nickname registered in another domain.  So, for
example, you would prohibit allowing a domain to use an AOL screen name as a
nick name; they have to declare the nickname within the local domain.  You
feel strongly that the mechanism should not be made such that some domains
could allow this feature (by, for example, including the domain in the
nickname, and using some other mechanism for constructing a URI for the
nickname).  

- Scope: nicknames are reserved per domain. I want to participate in one or
more chatrooms serviced by the same domain discussing slightly different
topics. People certainly do that in IRC today and we don't want that feature
to disappear. Also, I don't want to go reserve my nickname 10 different
times in 10 different chatroom in the same domain. 
<brian>what is a domain then?  Is chat34.example.com a domain?  Did you mean
to imply that example.com is the domain?  So, for example, hotmail.com is a
different domain from msn.com, right?

You would prefer to register your nickname in 100 different chat servers you
might use, rather than asking them to use one your registered somewhere
else, right?   Again, you want to prohibit this kind of behavior, or perhaps
more positive, you don't want the mechanism complicated in any way to allow
such a capability.

So you would not want to have, at any time, a standardized way to request a
permanent nickname.  You might want to explain a little about how you use a
permanent as opposed to a temporary nickname.  Let's say, for example, that
there was a chat where I was not in that particular chat, but someone else
wanted to use my nickname.  Would you allow that?

I'm a little unclear if you would find any value in a registered nickname. 

Here we have common ground.  You want to allow a service to allow
collisions, and you want a way for a service to not allow collisions.  I
agree.  It's policy at the service, and clients have to cope with either
policy.

I think we're agreeing on principal, but disagreeing on mechanism.  We agree
that you should be able to be addressed by AoR if you are okay with that,
and we agree you should be addressable by some other URI if you don't want
to be addressable by your AoR.  We agree that your nickname is associated
with the URI (be it an AoR or something else).  Is there a particular reason
why you need to have the nickname itself in the alternate AoR?  Would some
other anonymous URI, associated by all with your nickname in the roster, be
an acceptable URI or does it have to be nick@domain?

Is there some advantage to having the nick itself in the URI? 

Yes

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Sep 2007 11:32:27 -0400

Brian Rosen wrote:
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Hisham Khartabil [mailto:[email-masked]]
> *Sent:* Sunday, September 02, 2007 10:52 PM
> *To:* Brian Rosen
> *Cc:* Jeroen van Bemmel; Paul Kyzivat; [email-masked]; 
> *Subject:* Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI
> 
>  
> 
> I've read this thread and seem to agree mostly with Aki, but I think 
> Brian and Paul have some valid points.
> 
>  
> 
> - Agencies: No external nicknames (I think it defeats the purpose of 
> having a nickname if external ones are allowed). Effectively I'm saying 
> that every domain runs its own nickname agency and to join one of its 
> chatrooms, you need to create a local nickname.
> 
> example, you would prohibit allowing a domain to use an AOL screen name 
> as a nick name; they have to declare the nickname within the local 
> domain.  You feel strongly that the mechanism should not be made such 
> that some domains could allow this feature (by, for example, including 
> the domain in the nickname, and using some other mechanism for 
> constructing a URI for the nickname). 

> - Scope: nicknames are reserved per domain. I want to participate in one 
> or more chatrooms serviced by the same domain discussing slightly 
> different topics. People certainly do that in IRC today and we don't 
> want that feature to disappear. Also, I don't want to go reserve my 
> nickname 10 different times in 10 different chatroom in the same domain.
> <brian>what is a domain then?  Is chat34.example.com a domain?  Did you 
> mean to imply that example.com is the domain?  So, for example, 
> hotmail.com is a different domain from msn.com, right?
> 
> You would prefer to register your nickname in 100 different chat servers 
> you might use, rather than asking them to use one your registered 
> somewhere else, right?   Again, you want to prohibit this kind of 
> behavior, or perhaps more positive, you don’t want the mechanism 
> complicated in any way to allow such a capability.

I'm with Brian here - I'm sympathetic to arguments that we don't want 
this to get too complicated so that it slows down availability of 
*something*. But I think this is a desirable capability, so we should 
keep in mind that it is something we want eventually, and so avoid doing 
something that precludes it.

> domain (logs off). A user can reserve a permanent nickname by doing an 
> out of band transaction with the domain administrators. Perhaps the 
> domain wants you to pay $$$ for doing that.
> 
> So you would not want to have, at any time, a standardized way to 
> request a permanent nickname.  You might want to explain a little about 
> how you use a permanent as opposed to a temporary nickname.  Let’s say, 
> for example, that there was a chat where I was not in that particular 
> chat, but someone else wanted to use my nickname.  Would you allow that?
> 
> I’m a little unclear if you would find any value in a registered nickname.
> 
> - Uniqueness: I think nicknames should be unique. There seems to be 
> people who want clashing nicknames. Fair enough, different people have 
> different agendas. So, I think its a fair compramise if we allow 
> collisions, but device a mechanism for servers force nickname uniqueness 
> and rejects conflicting nichnames (error responses etc).
> 
> agree.  It’s policy at the service, and clients have to cope with either 
> policy.

IMO, a nickname (when qualified with its domain) should be expected to 
uniquely identify a single "individual". There could be multiple 
sessions within a given conference using the same nickname with the 
expectation that they are sessions belonging to the same individual. 
Having multiple sessions of this sort should be fine. There should 
however be authentication of the user of a particular nickname so 
provide some assurance it is the same person.  (Or at least a group of 
people that are actively collaborating to pretend to be a single person.)

OTOH, two nicknames with different domains might have the same "user 
part". IMO it should be assumed that these could identify unrelated 
individuals. In principle I see no reason not to allow conflicts of this 
sort within a conference. But I can go along with a policy that doesn't 
allow it, if that is what it takes to get consensus.

> - Routability: I don't see myself joining a chatroom and wanting to 
> display my AoR, but some people might want to in order to enable other 
> users to contact them directly for private messages outside the chatroom 
> service, invite them to a voice call or whatever media. In this case, an 
> AoR display in warranted. For me, I will request anonymity, for Brain, 
> he will not and will diplay his AoR to the rest of the participants. A 
> compramise is to have an AoR  as well as a routable nickname. A user is 
> reachable on both. AoR is used to reach a user directly, the nickname is 
> used to reach the user via the chatroom. Perhaps diplaying both for 
> users not requesting anonymity and just the routable nickname for those 
> who do request anonymity.
> 
> I think we’re agreeing on principal, but disagreeing on mechanism.  We 
> agree that you should be able to be addressed by AoR if you are okay 
> with that, and we agree you should be addressable by some other URI if 
> you don’t want to be addressable by your AoR.  We agree that your 
> nickname is associated with the URI (be it an AoR or something else).  
> Is there a particular reason why you need to have the nickname itself in 
> the alternate AoR?  Would some other anonymous URI, associated by all 
> with your nickname in the roster, be an acceptable URI or does it have 
> to be nick@domain?
> 
> One problem, however, is present in the last point: since some servers 
> will allow collisions in nicknames, a nickname can no longer be routable 
> (if 2 or more users sharing the same nickname are all anonymous) and 
> therefore requires a uniqueness attribute.

In that case I think we assume they are multiple instances serving the 
same individual, and just fork to them all, just like an AOR.

	Paul

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 5 Sep 2007 09:36:32 +1000

Please keep in mind that my scope is MSRP chat in SIMPLE (the niemi draft)
and not the general mechanism to be addressed in the future. More comments
inline...

On 05/09/07, Brian Rosen <[email-masked]> wrote:
>
>
>
>
>   ------------------------------
>
> having a nickname if external ones are allowed). Effectively I'm saying that
> every domain runs its own nickname agency and to join one of its chatrooms,
> you need to create a local nickname.
>

I don't want to disallow. I want to be silent on the issue of external
nicknames in this draft. Just define a mechanism for local nicknames in this
draft.

> or more chatrooms serviced by the same domain discussing slightly different

right.

> you might use, rather than asking them to use one your registered somewhere
> else, right?
>

Yes, but only for this draft's scope. Again, the general mechanism should
allow for your requirement.

   Again, you want to prohibit this kind of behavior, or perhaps more
> positive, you don't want the mechanism complicated in any way to allow such
> a capability.
>
Again, I don't want to prohibit. I want to be silent on the issue.

> So you would not want to have, at any time, a standardized way to request
> a permanent nickname.
>
Yes, but only for this draft's scope. Again, the general mechanism should
allow for your requirement.

     You might want to explain a little about how you use a permanent as
> opposed to a temporary nickname.  Let's say, for example, that there was a
> chat where I was not in that particular chat, but someone else wanted to use
> my nickname.  Would you allow that?
>

I would not allow that since my client paid me to "permanently" reserve this
nickname. This is policy.

> I'm a little unclear if you would find any value in a registered nickname.

I'm not yet convinced that there is value. But I can be.

> display my AoR, but some people might want to in order to enable other users
> to contact them directly for private messages outside the chatroom service,
> I think we're agreeing on principal, but disagreeing on mechanism.  We
> agree that you should be able to be addressed by AoR if you are okay with
> that, and we agree you should be addressable by some other URI if you don't
> want to be addressable by your AoR.  We agree that your nickname is
> associated with the URI (be it an AoR or something else).  Is there a
> particular reason why you need to have the nickname itself in the alternate
> AoR?  Would some other anonymous URI, associated by all with your nickname
> in the roster, be an acceptable URI or does it have to be nick@domain?
>
>
>

Yes. It might get Aki to agree :)

> will allow collisions in nicknames, a nickname can no longer be routable (if
> 2 or more users sharing the same nickname are all anonymous) and therefore

So does having a uniquess attribute still clasify them as conflicting?

Regards,
Hisham

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 5 Sep 2007 09:38:37 +1000

On 05/09/07, Paul Kyzivat <[email-masked]> wrote:
> > behavior, or perhaps more positive, you don't want the mechanism
> > how you use a permanent as opposed to a temporary nickname.  Let's say,
> > you don't want to be addressable by your AoR.  We agree that your

Are you sure you want that? We are talking about private messages here.

Hisham

       Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Sep 2007 08:20:56 -0400

I believe the current proposal from Paul, which I am happy with is:

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

>From your position, it would seem we are asking for the "@domain" to be
permitted in the nick request and conference roster, and that the contact
URI is used in MSRP From/To.  Do you have an objection to that?

I'd be okay with saying MSRP chat doesn't define how "the focus verify with
a server for the domain that the requester is allowed to use the nickname".
That can be something the generalized mechanism supports.

Brian

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 7 Sep 2007 16:38:56 +1000

> URI is used in MSRP From/To.  Do you have an objection to that?

Why can't the nickname "the version with @domain" be represented in the
From/To?

  I'd be okay with saying MSRP chat doesn't define how "the focus verify
> with a server for the domain that the requester is allowed to use the
> nickname".  That can be something the generalized mechanism supports.
>

We can agree on that.

Hisham

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 9 Sep 2007 18:02:00 -0400

In the proposal we have, the URI doesn't have the nickname in it (because
collisions might be acceptable and if you allowed them, you would have
non-unique URIs).  Rather than inventing new syntax just to be able to have
the nickname be in the From/To, we simply propose that the MSRP server put a
unique URI in the Roster.

Users never see the URIs. 

Furthermore, there are complications with constructing URIs with nicknames
in them.  The example used is when the domain is [email-masked]
(and not chat34.example.com).  If that is the domain of the chat, then you
can't just put the nickname before the @ and the domain after the @, you
need some kind of construction rule.  When you get into construction rules,
you have trouble with weird nicknames, or you limit the syntax on a
nickname, or something breaks.  So we proposed to just not have a
construction rule.  You get the URI out of the roster.

Brian