Subject: RE: [Simple] Ephemeral vs persistent nicknames for chat

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 2 Jan 2008 17:42:09 +0100

The combining of ephemeral and persistent nicknames in the same
conference unfortunately seems to complicate rather than simplify
things.

I have added some clarifying comments below if interest persists.

> From: Paul Kyzivat [mailto:[email-masked]]
> 
> Geir Arne Sandbakken wrote:
> > [snip snip]
> >
> > I find both mechanisms useful, and hoped to support both not
selecting
> > 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?

Yes. All participants would have ephemeral nicknames, but could have
persistent ones as well if supported by the client and the server.

> If so, are they syntactically distinguishable from one another?

Yes.  They have nothing in common.  Two different values associated with
the same AOR.

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

They would not collide, but a client supporting both would have to
juggle both.

> > A traditional client could only support the conference scoped
ephemeral
> > 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.

Your ephemeral nickname would have to be unique in the conference.  The
persistent nickname would have to be unique inside a domain (or other
scope).

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

The rich client would have to support ephemeral nicknames, and it would
interoperate.  The legacy clients would not see the persistent nicknames
though. 

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

This is exactly what I meant by persistent nicknames.  Still I'm not
sure my definition really qualifies as a nickname.

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

Seemed like a good idea at the time :-) 

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

I hoped that the nickname could be simpler than the AOR associated to
the participant.  That's one of the reasons I proposed always supporting
ephemeral nicknames - being unique inside a conference, but very simple.
This would make it possible to write only the ephemeral nickname to send
a private message.

Thanks,
Geir Arne

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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 7 Jan 2008 15:37:02 +1100

I don't even know why we talk about persistant nickname in the context
of SIMPLE. Adhoc conference and ad hoc nicknames is what we want, imo.

I suggest ephemeral nicknames are unique per domain (not per
conference focus) and are allocated on first come first serve basis.

Thanks,
Hisham