Subject: [Simple] Re: Chat Nicknames

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Apr 2005 20:48:56 -0600

Ok - that makes sense to me. Do we need to change anything in the MSRP
drafts to reflect any of this?

On 3/10/05 8:36 AM, "Miguel Garcia" <[email-masked]> wrote:

> Inline.
> 
> 
> Cullen Jennings wrote:
> 
>> I might be missing the boat here but let me ask a question that separates
>> stuff. 
>> 
>> Is there a requirement to be able to change you nickname on every message or
>> would it be acceptable to set up a new session if you want to change you
>> nickname?
> 
> I guess when you say "setup up a new session" really means a re-INVITE,
> not an additional session. I believe it is possible, but perhaps a
> lighter mechanism should be desirable.
> 
> This is perhaps the reason why the chat draft went for an approach where
> the nickname is composed of a Display-Name, which is freely changable on
> a message by message basis, and a URN (could queally be a URI), that is
> something more permanent, negotiated (or assigned by) the MSRP
> switch/conference focus.
> 
> This allows a user to change the display-name part of the nickname,
> still having some sort of unique identifier within the conference.
> 
>> 
>> It seems that the name could be set when you set up the session. If this is
>> the case, then the display name of the From is very clear you can put any
>> alias you want in it. The chat controller can tell you that name is not
>> acceptable thought, in practice, there is no fundamental reason you can't
>> have people with the same nickname and just have the conf server append
>> something to make them unique.
> 
> The name could be set when you set up the session, but it could also
> change during such session, and even remain "allocated" for your usage
> after the session.
> 
> I think we agree that there are two components of the name, one is set
> by the user, the other by the conference server. In the chat draft we
> propose the former to be a display-name, the latter a URN, but I am fine
> with any other proposal that keeps this property.
> 
>> 
>> RTP/RTCP had different requirements for this because you could join a
>> multicast session with effectively no signaling with all the participants so
>> there was a need to continuously and adaptively flow the name information as
>> the conference changed. Since this this centralized conferencing, you can
>> get the names from the centralized thing.
> 
> Agree.
> 
>> 
>> Say two people joined with nick name of anon. The chat mixer may identify
>> them as anon1 and anon2 in the session and you can send a private message to
>> one of them by sending to location for anon2 (which would be an anonymous
>> perhaps on the same box as the mixing was happening on).
> 
> Agree too. If we use the approach of the chat draft, the two From header
> (in Message/CPIM) would be:
> 
> From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon1
> From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon2
> 
> 
>> 
>> Cullen
>>  
>> 
> 
> /Miguel

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Apr 2005 13:15:23 -0400

Hmm,

This discussion raises a question in my mind. Consider the following:

	Alice --\                   /-- Carol
	         \                 /
	          > F1 ------ F2 <
	         /                 \
	Bob ----/                   \-- Dave

In the F1 conference F2 is a surrogate participant for Carol and Dave,
and in the F2 conference F1 is a surrogate participant for Alice and 
Bob. (At least I think that is how it would work.) One would hope that 
individual names for the participants could still make it end to end, 
rather than having having all messages from Carol and Dave appear to 
Alice and Bob as having come "from" F2. I believe audio mixers are 
capable of achieving this.

Any effort to have the foci (or corresponding mixers/relays) help Alice 
address a message to Dave (if the address alice has for dave isn't 
directly usable for routing messages to him) is going to have problems 
in this topology. It presumes that the focus you send to understands all 
the mapping of nicknames to names, but that is not the case here.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 12 Apr 2005 09:00:52 +0300

I think there aren't immediate actions to the MSRP drafts.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 12 Apr 2005 09:09:05 +0300

Paul:

The use case you raise is really interesting. One way to solve this 
poblem would be based on the following. Assume the URN in nicknames have 
some hierarchy that points to a particular focus. For example F1 and F2 
name spaces could be urn:ietf:params:msrp:names:com:example:f1 and 
urn:ietf:params:msrp:names:org:example:f2 respectively

Nicknames allocated to Alice and Bob could be:

urn:ietf:params:msrp:names:com:example:f1:alice
urn:ietf:params:msrp:names:com:example:f1:bob

and to Carol and Dave

urn:ietf:params:msrp:names:org:example:f2:carol
urn:ietf:params:msrp:names:org:example:f2:dave

The next thing that is required is that F1 and F2 exchange their root 
namespace at the time they establish the MSRP session. On doing so F1 
will learn the prefix that F2 will allocate to nicknames of its 
participants, and F2 will do the same with respect F1.

Things will get complicated when more foci are cascaded, like 
F1--F2--F3.  This will require further delivery of URN prefixes.

Any other idea?

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Apr 2005 09:26:21 -0400

Miguel,

What you suggest is troublesome because it requires a particular form of 
URN and URN usage.

I'm not very knowledgable about RTP, but I believe RTP mixers exchange 
their full lists of participant identifiers via RTCP. Doing that - 
exchanging the full list of participants - is an alternative to just 
disclosing a root in the nickname namespace.

But that is still not very appealing to me. In fact, the whole notion of 
replicating roster info in the media stream seems questionable to me, 
when there are specific mechanisms being defined for managing rosters 
that are not media specific.

I still think that a better solution is simply to use the same 
identities the focus uses to identify participants at the signaling 
level. If participants want anonymity then they should use an anonymizer 
for participating in the conference as a whole - but an anonymizer that 
permits limited forms of callback to the anonymous id.

	Paul

Miguel Garcia wrote:
>> Any effort to have the foci (or corresponding mixers/relays) help 
>> Alice address a message to Dave (if the address alice has for dave 
>> isn't directly usable for routing messages to him) is going to have 
>> problems in this topology. It presumes that the focus you send to 
>> understands all the mapping of nicknames to names, but that is not the 
>> case here.
>>
>>     Paul
>>
>> Cullen Jennings wrote:
>>