Subject: [Simple] Ephemeral vs persistent nicknames for chat

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 18 Dec 2007 15:48:28 +0100

Experts,

Reading about nicknames from the simple mailing list archive, drafts,
RFCs and other sources I came across US presidential nicknames. I found
that two had the nickname Bill.  If only one of them is present in a
room, it is easy to announce "Phone call for Bill".  If both of the
presidents are in the same room more information is needed to resolve
the announcement.  The announcer could select between Bill(1) or
Bill(2), but that might not help much.  Another alternative is to let
the presidents help the announcer themselves.  Taft was first into the
room so he chose to have just "Bill".  Clinton was second so he selected
to have "aliveBill" instead.  Who would you vote for to resolve the
announcement: the presidents or the UI?  The phone call gave good news
so "aliveBill" changed his ephemeral nickname to "happyBill".

Persistent (not presidential) nicknames like screen names in AOL have
different characteristics.  They seem to fit quite nicely inside the
existing conference package and the XCON data model.  The main
difference being that the routable address is translated by the focus
instead of the service issuing the nickname URI. I can see many usages
of such a general mechanism to reach a nickname using any media. The
most popular being in-game voice chats where you talk to people that is
represented only by persistent nicknames.

To clarify, the <entity> attribute in the <user> element in the
conference package contains either the proper AOR or a nickname one like
"[email-masked]" translated by the focus.  The <display-text> associated
to the <user> element has no requirements to be unique, so the UI of the
conference aware application would need to render it properly to
differentiate between similar texts. Like "Nicky(1)" and "Nicky(2)" if
two were present from different domains. Still the <entity> attribute
would need to be rendered to resolve the destination for a private
message.

Apologies if my question is already covered by earlier discussions; but
can we have both mechanisms? We could add a chat room unique ephemeral
attribute named <nickname> to the <user> element, and let the XCON aware
client render: Nicky(beerlover) and Nicky(treehugger). The traditional
client doing an MSRP protocol plug-in could only care about ephemeral
nicknames rendering only "beerlover" and "treehugger"; which can change
at any time but still is unique inside a conference object.  

Geir Arne

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Dec 2007 10:44:23 -0500

Geir Arne,

I think it will be good to have someone with a fresh viewpoint enter the 
conversation!

> so "aliveBill" changed his ephemeral nickname to "happyBill".

I think something might be done with a distinction between ephemeral and 
persistent nicknames. But to do so there needs to be some clear 
understanding of their semantics and which is being used in any given 
context.

Normally "ephemeral" pertains to time. Is an ephemeral nickname one that 
is only valid for a brief time? Or is it also "spacially" bound?

IMO there is a problem if I participate in multiple chat conferences 
that involve some of the same people and the nickname:person 
associations differ among those conferences. (If "aliveBill" is the 
nickname for Bill Clinton in the Ex-Presidents conference, then it will 
be very confusing if "aliveBill" is the nickname for Bill Bradley in the 
Past-Presidential-Candidates conference and Bill Clinton is known as 
"happyBill" in that one.

At the very least, I think it is important to have it clear which 
nicknames are ephemeral and which are not. One possibility is to have 
this be an attribute of the conference - either all nicknames are 
ephemeral, or they are all persistent. But I expect that isn't 
sufficiently flexible. Frequent participants are likely to want 
persistent nicknames, while an ephemeral participant may not be willing 
to endure the hassle of obtaining a persistent nickname and will be 
satisfied with an ephemeral one.

> represented only by persistent nicknames.

The above seems to assume that the scope/namespace of a persistent 
nickname is a single conference, or perhaps a single conference server 
and all the foci it hosts. That needs to be clarified. (IMO a namespace 
of a single conference is insufficient. And probably a namespace of a 
single conference server is also insufficient. A namespace of a bulk 
conference provider, such as AOL, seems to be sufficient, though even 
that is somewhat limiting.)

Are ephemeral and persistent nicknames drawn from the same namespace? Or 
are ephemeral nicknames drawn from a conference scope while persistent 
nicknames are drawn from a larger scope? Neither choice is ideal. If 
they are drawn from a common namespace then there really is no 
distinction. But the alternative means that if I join a conference using 
the ephemeral nickname of "happyBill" then I will be blocking the 
subsequent admission of Bill Clinton who has been assigned the 
persistent nickname of "happyBill".

I do participate in some online services that have the kind of 
persistent nicknames, identity hiding, and forwarding capabilities you 
are talking about. In general the scope is more than one conference. The 
nickname assignment and forwarding can be thought of as a related but 
independent service from the conferencing service. It is really a form 
of anonymizer. A set of conferences use it, but it can be used without 
the conferences too.

> would need to be rendered to resolve the destination for a private

The above seems to be fine to me, except that there is an authorization 
issue to be solved in general. When there is a request to use a 
nickname, there needs to be some verification that the requesting party 
is in fact authorized to use that nickname, and is not just an imposter. 
So far we have been talking about simply putting the burden on the focus 
to do that, and not saying how. Instead we simply say that it should 
reject use of the nickname if it doesn't know how to authenticate its 
use. So a particular focus may only permit use of nicknames from a 
domain that it has an association with. Eventually there could be some 
formal protocol for that aspect, so that any nickname could be used with 
any focus.

	Thanks,
	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Dec 2007 12:48:45 -0500

> > would need to be rendered to resolve the destination for a private
You need an "AoR" (at least a URI) no matter what.  It might be fabricated
by the focus to allow anonymity, but you have a URI.

You may have a nickname.  That's an alternate identity, not dissimilar to,
but distinct from a display name.  It's only use is in a UI, but it's an
important use.

We get wrapped around the axle when we confuse an URI that is used for
addressing to a nickname that is used for display purposes.  They are
distinct.  It's okay if the focus decides to make the URI it fabricates
nick@focus, but it's not constrained to do that.

All the combinations make sense.  You may have a URI with a display name,
and a separate nickname.  The URI may be anonymous or not.  The URI may be
provided by the focus with or without a nickname.  The nickname may be
"provided by" (meaning accepted as proposed) the focus with or without a
display name or an anonymous URI.  

Well, a display name on an anonymous URI probably doesn't make sense :)

Brian

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Thu, 20 Dec 2007 12:05:15 +0100

Thanks Paul,

The ephemeral nickname is scoped inside the conference and as long as
the participant is part of it.  The participant can change it at any
time, and just by looking at the roster of the conference it is easy to
select something unique.  It's the type on nickname that sometimes
changes during a conference as the mood or role of the user changes.

The persistent nickname is scoped globally (if authorization is
possible) or at least inside the domain(s) of which the focus can
operate.  This is the nickname that you know represent someone in a
persistent manner.  In AOL you can select six such screen names. The
participant offers it to the focus using a nickname service to replace
the real AOR and its display text to be distributed in the conference
package to the other participants.  It can be just an associated AOR
inside the XCON common data model including display-text, or modeled as
something specific for persistent nicknames.  

I find both mechanisms useful, and hoped to support both not selecting
either in the conference. 

A traditional client could only support the conference scoped ephemeral
nickname.  If this is how the chat application currently relates to
nicknames; replacing the current supported protocol with MSRP should
just work.  This is also how the user would expect the chat room to
work.  Collisions between nicknames among chat rooms are expected by the
user of the traditional client. The "Operator" in one room may not be
that same person as the "Operator" in another. The client could connect
to the focus requesting privacy.  The conference package requires the
focus to generate a unique username inside the focus' domain which will
be the routable address (skipping the .invalid part of the spec.).  The
initial ephemeral nickname could be the same as the generated username,
but the participant can replace it using the proposed SetNickname method
in MSRP. 

If you require a persistent nickname that doesn't collide with nicknames
in other conferences, you can upgrade to an XCON client supporting rich
conferencing. It can set both the persistent and the ephemeral nicknames
using CCMP.  The persistent nickname would be an associated AOR to the
user element in the XCON data model.  Instead of distributing an
anonymous AOR, the focus will use the received persistent nickname AOR
having a nickname based <display-text>.  The client would need to juggle
the persistent nickname AOR, the persistent nickname <display-text> and
the ephemeral nickname supported by legacy clients.  If you persistent
nickname AOR is "[email-masked]" having the <display-text> of "Nicky" and
the ephemeral nickname would be "treehugger", the client could render
the following complete nickname: "Nicky (treehugger)".  You avoid
collision as another "Nicky" [email-masked]" would need to select
another ephemeral nickname like "Nicky (beerlover)".  

Is this XCON client something you want, or is it just goofy? :-)

Thanks,
Geir Arne

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> 
> Geir Arne,
>

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Thu, 20 Dec 2007 12:59:34 +0100

Brian,

I think a part of the wrapping problem is trying to address someone
having a unique address.  It seems like we can choose from having the
nickname itself or the "nickname + AOR" be unique in a conference.  

If we require the nickname (not represented as an URI) to be unique
addressing is trivial.  Any persistency of the nickname content could be
part of the focus policy.  The scope would be a single domain for a
conference.

If we accept having equal nicknames in the same conference associated
with different domains, the participant would have to get the URI
rendered to differentiate.  Now the routing address has popped up into
the UI, and we no longer have simple nicknames.  

Geir Arne

> From: Brian Rosen [mailto:[email-masked]]
>
> > > conference package contains either the proper AOR or a nickname
one
> like
> > > to the <user> element has no requirements to be unique, so the UI
of
> the

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Dec 2007 22:58:59 -0500

> either in the conference. 

I'm still unclear about what assumptions you are making.

Can both ephemeral and persistent nicknames be in use in the same 
conference?

If so, are they syntactically distinguishable from one another?

If they can both be used, and are indistinguishable, then are all 
persistent nicknames that *could* be used in a conference treated as 
reserved names - ineligible for use as ephemeral nicknames? (Either they 
are, or else a user with an ephemeral nickname could block the owner of 
a persistent nickname from joining a conference.)

> nickname. 

Do you mean a traditional client could only support use of conference 
scoped ephemeral nicknames *for itself*? Its important that this not 
prevent others in the conference from using persistent nicknames.

The only real impact of this is would be the possibility of having your 
requested nickname rejected even though you don't see it in use in the 
conference.

> If this is how the chat application currently relates to
> conferencing.

I guess it is perhaps reasonable that you must support XCON to get 
persistent nicknames.

But this must interoperate with simple users of the same conference that 
don't support XCON.

Its also my opinion that the scoping of persistent nicknames should not 
necessarily correlate with conference server operators.  That is why I 
think nicknames (at least persistent ones) should contain a scope.

Specifically, you and I might both be participating in a conference 
hosted by an ietf server. My nickname might be scoped to aol.com and 
yours might be scoped to msn.com. (However this is probably still 
debatable - it blurs the line between what is a nickname and what is an 
AOR.)

> It can set both the persistent and the ephemeral nicknames

I'm not quite following you. I don't understand the same participant 
having both an ephemeral and a persistent nickname. I find that very 
confusing and illogical.

Isn't it sufficient that [email-masked] is different from 
[email-masked]? If both are present then the client would render the 
domain portion to resolve the ambiguity.

> Is this XCON client something you want, or is it just goofy? :-)

Well, maybe not exactly *this* one.

	Thanks,
	Paul