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

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Aug 2007 16:15:13 -0400

Are we constrained to current system behavior?  Is the fact that there are
systems that use the nickname as an on-the-wire address a constraint?
We've proposed you use AoRs or anonymous GRUUs for addressing.  Is that a
problem, or just different?

I am aware of conference systems that permit nicknames for UI purposes where
the nickname is NOT used for addressing, it's just for UI, but to make it
work, the nick traverses the wire.  Do we wish to outlaw that kind of
system?

Is it a really big issue to PERMIT name collisions (as long as there is no
addressing ambiguity)?  A particular server can have a more restrictive
policy of course.  Is that really a problem?

The problem with your position is that the Aki in one chat server can be
different from the Aki in another.  I don't see the difference between
conflicts in the world, a particular service or a particular chat room.  I
presume when you say "server" you really mean "service".  If you don't then
I really don't understand what you are looking for.   I am unique in all of
AOL, not just the particular server that is providing a chatroom for me.
The only requirement, taking your position, is uniqueness to chat room,
since the addressing via nickname is always within the chatroom.  Uniqueness
to a service is a UI convention you happen to like because IRQ does that.
You know there are services more restrictive than that, yet you want
uniqueness to service.

I want uniqueness to a domain, which is different from a service only in
that the domain is not necessarily the domain of the service.  This allows
me to register in a domain of my choice and use that nickname in multiple
services, assuming these services accept my nickname service.  I don't see
the big difference, and it seems to provide useful capability.  I won't mind
having a server that restricts, by policy to only accept names issued by
it's own domain.  That mimics AOL behavior, for example.

Brian

> -----Original Message-----
> From: Aki Niemi [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2007 8:36 AM
> To: ext Paul Kyzivat
> Cc: ext Brian Rosen; 'Miguel Garcia'; 'SIMPLE mailing list'
> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI
> 
> 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
> 
> ext Paul Kyzivat wrote:
> > 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
> >

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

---

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

I agree with Brian. One point added below.

	Paul

> it's own domain.  That mimics AOL behavior, for example.

I will *tolerate* a server with that restriction under certain 
circumstances, but I will *mind* - I won't like it at all. I'll be 
wanting all those services to become more flexible. Whether they will go 
along is TBD.