Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt

From: Adam Roach <[email-masked]>
Date: Sat, 18 Mar 2006 18:36:44 -0600

Miguel Garcia wrote:

> We have just submitted a new version of the MSRP CHAT draft. This has 
> changed substantially from earlier versions, so I wouldn't dare to 
> summarize the changes.

-----

By and large, this is far more palatable than previous versions. I'm 
still a little apprehensive about the fact that we will ultimately end 
up with more than one way to send messages to a subset of participants 
(either using the "To" CPIM field *or* using the conference control 
protocol), but I have convinced myself that these mechanisms can 
probably coexist with minimal pain. Time permitting, I'll put together 
some suggested text for your document that talks (in general terms) 
about how these mechanisms can interact with each other in a sane fashion.

-----

I *do* have some of the same reservations as Paul does about nicknames.

As has been brought up repeatedly: nicknames are most emphatically not 
an IM-only issue. The representation of conference participants is an 
extremely generalizable problem, and I can't as easily see how to 
harmonize two different mechanisms.

In other words, the nickname reservation protocol that you're defining 
with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My 
suggestion, for what it's worth, is that you (1) split the nickname 
reservation mechanism out into a separate draft, and (2) use either SIP 
or the XCON Conference Control Protocol instead of MSRP.

-----

As a minor additional issue: one of the fundamental precepts of the 
conferencing framework (even pre-XCON) was that non-conference-aware 
participants should be able to participate in conferences, albeit with 
less control of the conference itself. To that end, it would probably be 
beneficial to indicate how participants who don't have CPIM clients will 
work.

I think there are sensible ways of addressing this (e.g. if such a user 
sends a message, then the MSRP mixer adds a CPIM envelope that includes 
the user's identity, as learned during session establishment) -- they 
should probably be called out so that implementors of MSRP mixers will 
have some guidance around how they should behave..

/a

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

---

From: Hisham Khartabil <[email-masked]>
Date: Sun, 19 Mar 2006 23:28:55 +0100

Speaking of nicknames. I don't understand why we need the MSRP 
extension NICKNAME to reserve a nickname for a chatroom. One would 
think that the nickname was reserved when the user joined the chatroom 
using  the SIP From header field.

Thanks,
Hisham

On Mar 19, 2006, at 1:36 AM, Adam Roach wrote:

> reservation mechanism out into a separate draft, and (2) use either 
> SIP or the XCON Conference Control Protocol instead of MSRP.
>
> -----
>
> less control of the conference itself. To that end, it would probably 
> be beneficial to indicate how participants who don't have CPIM clients 
> will work.
>
> I think there are sensible ways of addressing this (e.g. if such a 
> user sends a message, then the MSRP mixer adds a CPIM envelope that 
> includes the user's identity, as learned during session establishment) 
> -- they should probably be called out so that implementors of MSRP 
> mixers will have some guidance around how they should behave..
>
> /a
>

---

From: Hisham Khartabil <[email-masked]>
Date: Sun, 19 Mar 2006 23:37:54 +0100

And one other thing about nicknames :)

This might be a matter of taste. Would a URI parameter be more 
appropriate. I.e. Instead of this

sip:[email-masked]

you have this

sip:[email-masked];nickname="nordicguy"

Thanks,
Hisham

On Mar 19, 2006, at 11:28 PM, Hisham Khartabil wrote:

>>> We have just submitted a new version of the MSRP CHAT draft. This 
>>> has changed substantially from earlier versions, so I wouldn't dare 
>>> to summarize the changes.
>>
>> -----
>>
>> still a little apprehensive about the fact that we will ultimately 
>> end up with more than one way to send messages to a subset of 
>> participants (either using the "To" CPIM field *or* using the 
>> conference control protocol), but I have convinced myself that these 
>> mechanisms can probably coexist with minimal pain. Time permitting, 
>> I'll put together some suggested text for your document that talks 
>> (in general terms) about how these mechanisms can interact with each 
>> other in a sane fashion.
>>
>> -----
>>
>> As has been brought up repeatedly: nicknames are most emphatically 
>> not an IM-only issue. The representation of conference participants 
>> is an extremely generalizable problem, and I can't as easily see how 
>> to harmonize two different mechanisms.
>>
>> In other words, the nickname reservation protocol that you're 
>> defining with the NICKNAME mechanism in MSRP shouldn't be limited to 
>> MSRP. My suggestion, for what it's worth, is that you (1) split the 
>> nickname reservation mechanism out into a separate draft, and (2) use 
>> either SIP or the XCON Conference Control Protocol instead of MSRP.
>>
>> -----
>>
>> participants should be able to participate in conferences, albeit 
>> with less control of the conference itself. To that end, it would 
>> probably be beneficial to indicate how participants who don't have 
>> CPIM clients will work.
>>
>> includes the user's identity, as learned during session 
>> establishment) -- they should probably be called out so that 
>> implementors of MSRP mixers will have some guidance around how they 
>> should behave..
>>
>> /a
>>

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Mar 2006 00:51:30 +0200

Hi Hisham,

ext Hisham Khartabil wrote:
> Speaking of nicknames. I don't understand why we need the MSRP extension
> NICKNAME to reserve a nickname for a chatroom. One would think that the
> nickname was reserved when the user joined the chatroom using  the SIP
> From header field.

No, you would use the From header field to authenticate yourself when
joining. So From is your "real" name.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Mar 2006 00:56:36 +0200

Hi Hisham,

> sip:[email-masked];nickname="nordicguy"

This is another option, yes.

Cheers,
Aki

---

From: Hisham Khartabil <[email-masked]>
Date: Sun, 19 Mar 2006 23:58:39 +0100

So let me understand. You join the chat room, then as a second step 
reserve your nickname? I don't think this is what we want.

How about a Preferred-Identity header field or an a=nickname SDP 
attribute that carries the nickname URI. Or even in the request-URI.

I think the nickname should be set up while "joining" and not after you 
join that chatroom.

Hisham

On Mar 19, 2006, at 11:51 PM, Aki Niemi wrote:

>> extension

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Mar 2006 01:04:10 +0200

> reserve your nickname? I don't think this is what we want.

That's what all other chats do currently.

> attribute that carries the nickname URI. Or even in the request-URI.

Yeah, we thought about doing somthing like this in O/A, but the
difficulty is in that the server needs to reject if there's a conflict,
and perhaps suggest an alternate nickname.

Then we thought about some session precondition for nicknames, but that
made our heads explode Dean-style. The next day we defined the NICKNAME
method.

> I think the nickname should be set up while "joining" and not after you

In practice, this is done while joining. But you also need to be able to
change your nickname while in the chat already.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Mar 2006 01:56:07 +0200

Inline.

> about how these mechanisms can interact with each other in a sane fashion.

That text will be much appreciated.

> harmonize two different mechanisms.

What we are essentially doing is creating a new namespace as strictly a
sub-namespace under the conference or chat room name. I think this is
the only reasonable way forward, because nicknames in any other, global
namespace really is a big problem, since that is really more a general
use anonymizing service we end up defining.

> or the XCON Conference Control Protocol instead of MSRP.

I think these two are actually reasonable suggestions, as long as the
same disclaimer we have in the draft still holds (namely, scope it for a
particular room only, first-come-first-served policy, defining "sticky"
nicknames out-of-scope, etc.).

As a forward-warning, the current draft talks about sidebars as being
one of the core features of chat rooms of today, but it doesn't define a
mechanism for reserving such sidebars within a chat room. This is
planned for the next version. ;)

Essentially, sidebars within a chat room are similar to nicknames in
that it's simply another sub-namespace to the chat room name. To reserve
a sidebar, we could define a similar mechanism to what's already defined
for nicknames. The only difference (in addition to method name :) would
be that sidebars would presumably need to be both opened and closed.

This proposal didn't make it to the draft, and I was supposed to send
text to the list for a proposal, but haven't until now. Of course, I was
thinking of a pair of OPEN-SIDEBAR, CLOSE-SIDEBAR methods in MSRP, but
surely this could be done with SIP and/or XCON as well. Joining, asking
others to join and leaving sidebars would use SIP INVITE, REFER, and BYE.

> beneficial to indicate how participants who don't have CPIM clients will

Good point.

> have some guidance around how they should behave..

Yes, and presumably, the chat server would need to decapsulate the
messages from CPIM and send it in plain text, *possibly* copying the
meta-data from the CPIM header into this plain text message as well.

Cheers,
Aki

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 20 Mar 2006 09:48:04 +0200

> nickname was reserved when the user joined the chatroom using  the SIP 

The SIP From header is not suitable, because it does not guarantee that 
the nickname is not already in use by someone else.

Additionally, I think we should keep using the From header in SIP as we 
are currently doing, which in most cases (with the exception of 
anonymous URIs), it indicates the routable SIP URI of the sender. A 
nickname shouldn't be routable, so in my opinion it does not fit there.

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 20 Mar 2006 09:48:42 +0200

> sip:[email-masked];nickname="nordicguy"

I have no problem with this approach.

/Miguel

---

From: "Jussi K. Virtanen" <[email-masked]>
Date: Mon, 20 Mar 2006 10:02:59 +0200

Hi,

On 2006-03-19, Adam Roach <[email-masked]> wrote:
> As a minor additional issue: one of the fundamental
> precepts of the conferencing framework (even pre-XCON) was
> that non-conference-aware participants should be able to
> participate in conferences, albeit with less control of
> the conference itself. To that end, it would probably be
> beneficial to indicate how participants who don't have
> CPIM clients will work.

Shouldn't an MSRP endpoint implement CPIM always? The draft
draft-ietf-simple-message-sessions-14 says as follows:

   All MSRP endpoints MUST support the message/cpim
   type, and SHOULD support the S/MIME[7] features of
   that format.

Thus, even a conference-unaware participant should be able
to comply with a request to use "message/cpim" as a wrapper.

Best Regards,

--
Jussi K. Virtanen

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2006 11:03:49 -0500

I want to know how nicknames relate to the roster of the conference. 
When joining the conference it will be common that the new participant 
may be willing to have the nickname disclosed in the roster, but not the 
actual participant URI. This affects requirements for the nickname 
assignment mechanism.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Mar 2006 10:05:51 -0600

>to comply with a request to use "message/cpim" as a wrapper.
Good catch. Thanks for reminding me about this. Based on this, I think 
we need no additional text in the draft to address non-conference-aware 
clients.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2006 11:10:26 -0500

> nicknames out-of-scope, etc.).

I think it is ok if the mechanism doesn't require more than FCFS policy 
for assignment of names. But neither should it be restricted to such a 
policy. IMO sticky nicknames are quite important. It would be upsetting 
if each time I came to the simple chat room I had to wonder whether 
"fluffy" was still Cullen.

	Paul

---

From: smile <[email-masked]>
Date: Mon, 20 Mar 2006 11:36:17 +0800

inline
----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Aki Niemi" <[email-masked]>
Cc: "Miguel Garcia" <[email-masked]>; "ext Adam Roach" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 21, 2006 12:10 AM
Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt

> "fluffy" was still Cullen.
So, I suggest nickname should be register in chat room, then your nickname 
will not be stolen. If user come into chat room has not registered, server can 
assign default nickname to him.

Xiao

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2006 15:34:08 -0500

> assign default nickname to him.

I was asking that this behavior be *permitted* but not *required*. This 
is behavior I would desire from conference servers I deal with, but if 
some servers choose to support only FCFS then that is ok with me. (I 
will just try to avoid patronizing them.)

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Mar 2006 22:43:16 +0200

ext Paul Kyzivat wrote:
>> So, I suggest nickname should be register in chat room, then your
>> nickname will not be stolen. If user come into chat room has not
>> registered, server can assign default nickname to him.
> 

Right. The current draft has this:

   Another option would be to use a nicknaming service, that allows
   allocating nickname URIs to users.  Using such a URI in a conference
   in effect anonymizes the user, but still allows the user to be
   reached outside the chat room using the same identity.  However,
   defining such nicknaming service machinery is out of the scope of
   this specification.
...
   In other words, a nickname is simply a username that is scoped for a
   particular chat room.  Such nicknames are allocated on a first-come
   first-served policy, meaning they can also be "stolen".  It is out of
   the scope of this specification to define nickname retention schemes,
   or nickaming services as discussed above.

Is that sufficient?

Cheers,
Aki