[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Chat sessions
Sure, sure... as we saw in another thread, we could extend the nickname support easily to RTP. We still need to define the means to transport the nickname in Instant Messages, and this is what this draft is trying to do.
/Miguel
> -----Original Message-----
> From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: 26 February, 2004 16:14
> To: Garcia Miguel.An (Nokia-NRC/Helsinki);
> pkyzivat@cisco.com; Khartabil
> Hisham (Nokia-TP-MSW/Helsinki)
> Cc: simple@ietf.org; Niemi Aki (Nokia-M/Espoo)
> Subject: RE: [Simple] Chat sessions
>
>
> Miguel
>
> I'm suggesting that there is need beyond IM for nicknames,
> and that perhaps
> instead of inventing something just for IM, we do something more
> generally applicable. I'm also suggesting that even IM
> systems may want
> to have a full display name, depending on their user interface.
>
> Deciding that display name in message/cpim is a nickname is specific
> to IM.
>
> Brian
>
> > -----Original Message-----
> > From: Miguel.An.Garcia@nokia.com [mailto:Miguel.An.Garcia@nokia.com]
> > Sent: Thursday, February 26, 2004 1:50 AM
> > To: Brian.Rosen@marconi.com; pkyzivat@cisco.com;
> > hisham.khartabil@nokia.com
> > Cc: simple@ietf.org; aki.niemi@nokia.com
> > Subject: RE: [Simple] Chat sessions
> >
> >
> > Brian:
> >
> > The only structure that the draft suggest is just a Display
> > Name + a URI, something that is already existing in e-mail,
> > SIP, and message/cpim. The new item is a convention that the
> > Display in message/cpim is considered a nickname, the URI is
> > not valid for routing purposes, but just for address space
> allocation.
> >
> > I don't think this is a big deal.
> >
> > /Miguel
> >
> > > -----Original Message-----
> > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: 25 February, 2004 16:07
> > > To: Garcia Miguel.An (Nokia-NRC/Helsinki);
> > > pkyzivat@cisco.com; Khartabil
> > > Hisham (Nokia-TP-MSW/Helsinki)
> > > Cc: simple@ietf.org; Niemi Aki (Nokia-M/Espoo)
> > > Subject: RE: [Simple] Chat sessions
> > >
> > >
> > > Generally, putting structure in text strings is a poor idea.
> > > However,
> > > we have done that in an implementation here.
> > >
> > > If you send From: "Brian (whoozitz) Rosen"
> > > <brian.rosen@marconi.com>, then
> > > "Brian Rosen" is a formal display name and "whoozitz" is a
> > nickname.
> > > The UI can use the two forms of identity as appropriate.
> > >
> > > I think that we should separate the concept of unique
> > > identity from human
> > > readable names or nicknames. The protocol mechanisms need
> > the former,
> > > the humans need the latter. The URI is unique, and that is
> > > all we need
> > > to make the protocol work. Depending on a UI choice, you may need
> > > display names, nicknames, or URIs.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Miguel.An.Garcia@nokia.com
> > [mailto:Miguel.An.Garcia@nokia.com]
> > > > Sent: Wednesday, February 25, 2004 2:13 AM
> > > > To: pkyzivat@cisco.com; hisham.khartabil@nokia.com
> > > > Cc: simple@ietf.org; aki.niemi@nokia.com
> > > > Subject: RE: [Simple] Chat sessions
> > > >
> > > >
> > > > Hi Paul:
> > > >
> > > > In the draft we said that a nickname is the combination of
> > > > the display name and the URI (invalid, allocated by the
> > > > server) in the CPIM headers. The reason to add the URI into
> > > > equation was to mitigate the clash of same display names of
> > > > nickanmes in federated conferences.
> > > >
> > > > This apprach allows to have two beerLover nicknames in the
> > > > same conference, both sharing the same display name, but a
> > > > different URIs (CPIM headers), e.g., beerLover@conf1.com,
> > > > beerLover@anotherconf.com
> > > >
> > > > Still the URIs are scoped within the conference server,
> > > > administrative domain, or confederation. And yes, managing of
> > > > those nicknames in a multi-server environment is outside the
> > > > scope of the document.
> > > >
> > > > /Miguel
> > > >
> > > > > -----Original Message-----
> > > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > > > Sent: 24 February, 2004 18:19
> > > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> > > > > Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); simple@ietf.org;
> > > > Niemi Aki
> > > > > (Nokia-M/Espoo)
> > > > > Subject: Re: [Simple] Chat sessions
> > > > >
> > > > >
> > > > > Hisham,
> > > > >
> > > > > I don't think I agree with you. In the usage you describe, it
> > > > > probably
> > > > > would be ok for there to be multiple users calling themselves
> > > > > "beerLover". But I believe what is being proposed here is
> > > a unique
> > > > > identity within some scope. (The scope seems lack
> > > > definition so far.)
> > > > >
> > > > > My primary concern is to define the scope of names clearly.
> > > > > My secondary
> > > > > concern is to potentially separate the scope of these names
> > > > from the
> > > > > scope of the conference, or the conference server, itself. If
> > > > > so, there
> > > > > might be users with names from different scopes in the same
> > > > > conference.
> > > > > And in that case they start to look like URIs.
> > > > >
> > > > > A case that now occurs to me is when two conferences are
> > > > > federated, by
> > > > > making one focus a participant in another conference. In that
> > > > > case, if
> > > > > nicknames are scoped by conference or conference server, and
> > > > > the scope
> > > > > is implicit rather than being passed around with each name,
> > > > > then it will
> > > > > not be possible to show nicknames for the users of a
> > > > > federated conference.
> > > > >
> > > > > Paul
> > > > >
> > > > > hisham.khartabil@nokia.com wrote:
> > > > > > I think we are mixing nickname with user ID (or usename).
> > > > > In a conference talking about beer, I would have a nickname
> > > > > of BeerLover. In a conference talking about MSRP, I would
> > > > > have a nickname MSRPLover. My user ID for both is
> > > > > hisham@nokia.com. If I want to be anonymous, my user ID would
> > > > > be different.
> > > > > >
> > > > > > I don't think this is the same as assigning aliases to user
> > > > > IDs. I believe this is what Paul is getting at. If you are
> > > > > talking about a nickname within an aokia-M/Espoo)
> > > > > >
> > > > > >>Subject: Re: [Simple] Chat sessions
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>Miguel.An.Garcia@nokia.com wrote:
> > > > > >>
> > > > > >>>Thanks for your comments. See my comments inline.
> > > > > >>>
> > > > > >>>
> > > > > >>>>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > > > >>>>
> > > > > >>>>Its good to think about things like this. But I think the
> > > > > >>>
> > > > > >>goal should
> > > > > >>
> > > > > >>>>not be to introduce special features for chat
> > conferences. It
> > > > > >>>>should be
> > > > > >>>>to learn what features users of chat conferences
> > expect, and
> > > > > >>>>ensure that
> > > > > >>>>comparable features are available via our conference
> > > > > framework, and
> > > > > >>>>available with any media when that makes sense.
> So I think
> > > > > >>>>some of these
> > > > > >>>>ideas need to flow back into the conference framework.
> > > > > >>>
> > > > > >>>If we want to move things to the conference framework,
> > > > > >>
> > > > > >> > then we need to develop a complete solution, based on
> > > > > >> > requirements that... I dind't see so far. For instance,
> > > > > >> > I believe all the requirements related to nicknames are
> > > > > >> > addressing the session based conferences so far.
> > > > > >> > We may want to extend those requriements, but there
> > > > > aren't any now.
> > > > > >>
> > > > > >>I agree there aren't. I am suggesting that *where it makes
> > > > > >>sense* these
> > > > > >>should be advanced as requirements against conferences in
> > > > general,
> > > > > >>rather than being focused as requirements only for chat
> > > > conferences.
> > > > > >>
> > > > > >>
> > > > > >>>Particularly, I don't know how useful is to use
> nicknames in
> > > > > >>
> > > > > >> > an audio/video conference. The feature is useful in a
> > > > conference
> > > > > >> > of instance messages, but not so much in the other...
> > > > > >> > Still, we may want to extend the conference package
> > > so that the
> > > > > >> > user element can contain a <nickname> sub-element.
> > > > > >> > This would allow a user to display the nickname of the
> > > > conferees,
> > > > > >> > no matter what the media is.
> > > > > >>
> > > > > >>Exactly. This becomes interesting in multimedia
> > conferences to.
> > > > > >>For instance it becomes a tag to use in identifying
> > > > current speaker.
> > > > > >>
> > > > > >>It also may provide a better way to deal with anonymous
> > > > > >>participants in
> > > > > >>all sorts of conferences, by giving them nicknames as
> > > handles to
> > > > > >>reference them by.
> > > > > >>
> > > > > >>Then, instead of saying: "Will the anonymous
> participant with
> > > > > >>the deep
> > > > > >>voice please repeat his question?", you can say:
> "Darth, will
> > > > > >>you please
> > > > > >>repeat your question?".
> > > > > >>
> > > > > >>
> > > > > >>>>However it is relatively trivial to be more accomodating,
> > > > > >>>
> > > > > >>adding and
> > > > > >>
> > > > > >>>>removing cpim wrappers according to the desires of the
> > > > > >>>>individual endpoints.
> > > > > >>>
> > > > > >>>Basically, there are two ideas here: endpoints SHOULD use
> > > > > >>
> > > > > >> > message/cpim when addressing a conference.
> > > > > >> > The focus MUST use message/cpim. The idea is
> that the focus
> > > > > >> > should indicate the nickname of the sender of
> the message,
> > > > > >> > which is conveyed in the From header of the
> > > > message/cpim message.
> > > > > >> > Endpoints SHOULD use messgae/cpim to relief the
> focus from
> > > > > >> > wrapping messages when the focus distributes a copy.
> > > > > >>
> > > > > >>Sounds good to me.
> > > > > >>
> > > > > >>
> > > > > >>>>Nickname management is problematic. It seems as though
> > > > > >>>
> > > > > >>nicknames will
> > > > > >>
> > > > > >>>>need to be authenticated and authorized. But it
> > isn't at all
> > > > > >>>>clear that
> > > > > >>>>the focus is the right entity to do so. (The scope
> > is wrong.)
> > > > > >>>
> > > > > >>>I don't think a nickname has to be authorized. Users are
> > > > > authorized,
> > > > > >>
> > > > > >> > and once a user is authorized, she can choose any
> > > > > >>available nickname.
> > > > > >> > Is this what you meant?
> > > > > >>
> > > > > >>>Regarding the scope of the nicknames, I believe a nickname
> > > > > should be
> > > > > >>
> > > > > >> > unique within a conference server or an
> > > administrative domain.
> > > > > >> > At least I don't see a valid requirement in
> > getting nicknames
> > > > > >> > valid across difrerent servers or different
> > > > > administrative domains.
> > > > > >>
> > > > > >>I guess this depends on how large and long lived these
> > > scopes are.
> > > > > >>It clearly isn't good if the scope is a single conference.
> > > > > >>
> > > > > >>It isn't good if it is a conference server either,
> if that is
> > > > > >>just one
> > > > > >>of a large pool of independent servers that are chosen at
> > > > random as
> > > > > >>hosts for conferences.
> > > > > >>
> > > > > >>When the same group of users join in a number of
> > > > conferences over a
> > > > > >>period of time, within that scope a nickname should
> be bound
> > > > > >>to a user
> > > > > >>for as long as that user wants it to remain bound.
> > > > > >>
> > > > > >>
> > > > > >>>>I think this would be better served by using
> real, routable
> > > > > >>>>im: or sip:
> > > > > >>>>uris. As needed, service providers can exist to host
> > > > > nicknames and
> > > > > >>>>forward requests addressed to them to other addresses.
> > > > > >>>
> > > > > >>>The point is that a nickname should not let you track the
> > > > > real user.
> > > > > >>
> > > > > >> > Only the conference server is able to map the real SIP
> > > > > URI to the
> > > > > >>nickname,
> > > > > >> > but not users. For instance, if user B receives an
> > > > > instant message
> > > > > >> > (through the conference server) from user A, B should
> > > > > only see the
> > > > > >> > nickname, unless A wants to disclose his real URI.
> > > > > >>
> > > > > >>>Making nicknames a real URI loose the semantics of the
> > > > "nickname".
> > > > > >>
> > > > > >> > We don't want that behaviour, we want a nickname
> to remain
> > > > > >>a nickname,
> > > > > >> > something meaningless.
> > > > > >>
> > > > > >>That depends on how things are administered. There could be
> > > > > >>"nickname"
> > > > > >>servers, that are nothing but specialized proxies. I would
> > > > > >>contract with
> > > > > >>one of these servers for whatever nicknames I want. These
> > > > would be
> > > > > >>unique usernames within the domain managed by that server.
> > > > > >>Each would be
> > > > > >>configured to forward to an address of my choice. I would
> > > > be given
> > > > > >>control to turn forwarding on and off selectively,
> so perhaps
> > > > > >>it would
> > > > > >>only work when I was actively using a particular
> nickname in
> > > > > >>a conference.
> > > > > >>
> > > > > >>Then I could use the nickname as my address when joining a
> > > > > >>conference. I
> > > > > >>could permit the conference server to disclose this
> address,
> > > > > >>and yet my
> > > > > >>true identity would remain hidden.
> > > > > >>
> > > > > >>The advantage of this is that it decouples the
> > > administration of
> > > > > >>nickname namespaces from the administration of
> > > conference servers.
> > > > > >>
> > > > > >>But I am not necessarily opposed to coupling nickname
> > > > > namespaces with
> > > > > >>conference administration *if* the scoping can be made
> > > reasonable.
> > > > > >>
> > > > > >> Paul
> > > > > >>
> > > > > >>
> > > > > >>_______________________________________________
> > > > > >>Simple mailing list
> > > > > >>Simple@ietf.org
> > > > > >>https://www1.ietf.org/mailman/listinfo/simple
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Simple mailing list
> > > > Simple@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/simple
> > > >
> > >
> >
>
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple