Subject: RE: [Simple] Chat sessions

From: [email-masked]
Date: Sat, 21 Feb 2004 22:21:46 +0200

Thanks for your comments. See my comments inline.

> From: ext Paul Kyzivat [mailto:[email-masked]]
>
> 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.

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.

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

As you said, we didn't introduce the requirement for cpim. So this shouldn't be an issue.

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

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

Ok, I guess the effect is the same.

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

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

/Miguel

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 11:55:37 -0500

[email-masked] wrote:
> 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?".

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

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

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 11:55:37 -0500

Sounds good to me.

nickname,

	Paul