Subject: RE: [Simple] Chat sessions

From: [email-masked]
Date: Mon, 23 Feb 2004 12:27:51 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul Kyzivat
> Sent: 20.February.2004 21:59
> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo)
> Subject: Re: [Simple] Chat sessions
> 
> 
> 
> 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.
> 
> More specific comments:
> 
> -----------
> 
>     .... Each message needs
>     to carry in it an identifier of the sender of the message.
> 
>     This is accomplished using the 'message/cpim' MIME type, 
> as defined
>     in [7]. The conference focus MUST insist on using the 
> 'message/cpim'
>     as the top-level wrapper type in the SDP, as defined in [12].
> 
> I think this is a little harsh. But as long as cpim support is 
> *required* of msrp implementations I guess it is ok. All that 
> is needed 
> to enforce it is for the focus to refuse any other format for 
> containers.
> 
> However it is relatively trivial to be more accomodating, adding and 
> removing cpim wrappers according to the desires of the 
> individual endpoints.
> 
> ---------
> 
>     If the message is a addressed to the whole conference, the To
>     header of the CPIM message contains the conference URI.
> 
> That works. But it would be convenient by default if messages 
> containing 
> no To are addressed to the conference as a whole.
> 
> 
> ----------
> 
> 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.)

A nickname is just that. I can assign myself any nickname in a chat room, as long as my identity is asserted (using whatever authentication mechanism).

/Hisham

> 
> 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.
> 
> Then, a conference server would only need to authenticate 
> endpoints when 
> they are connected to the focus, and verify that the From field of an 
> incoming cpim message matches the known identity of the source.
> 
> The roster is then available via the conference event 
> package, or via CPCP.
> 
> (However there would be serious problems with federated foci.)
> 
> 	Paul
> 
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 13:03:57 -0500

[email-masked] wrote:
> A nickname is just that. I can assign myself any nickname in a chat room,
 > as long as my identity is asserted (using whatever authentication 
mechanism).

See my earlier reply to Miguel.

A "chat room" may be a suitable scope for nickname assignment.
But then we have to decide exactly what a chat room is - is it a single 
conference instance that just happens to be very long lived? Or is it a 
a series of conferences that share some state.

And then, do nicknames only apply to chat rooms? Or does every 
conference act as a scope for nicknames.

It will make a difference to how tools are built and conferences are 
administered if you have to set up a chat room to have nicknames that 
extend over a long period of time. I think I would like to have lots of 
ad hoc conferences where nicknames are consistently used.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 13:03:57 -0500

mechanism).

	Paul