[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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