Subject: [Simple] Nickname negotiation

From: Qian Sun <[email-masked]>
Date: Tue, 10 Jul 2007 15:29:20 +0800

Hi,
There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"?

In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby.

On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME".

A possible approach might be including the chat command in the CPIM body, like this:
   Content-Type: message/cpim
   To: <sip:[email-masked];transport=tcp>
   Content-Type: text/plain
   Content-Disposition: chat-command
   NICKNAME "Alice in Wonderland" <sip:[email-masked]>

To "emote" function:
   Content-Disposition: chat-emote
   KISS Bob

Opinion?

Cheers,
Qian

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 16 Jul 2007 12:58:42 +0300

Hi Qian:

Interesting topic... So, you are suggesting to generalize the semantics 
and method name of NICKNAME and instead having something more generic, 
such as CHAT-COMMAND. This will be equivalent to the "//" in commercial 
chat rooms. Then there should be a subcommand that demultiplex and 
indicates the specific action.

Here we need to get the balance between be specific and generality. 
Also, we need to first discuss whether MSRP is the protocol that we want 
to use to command a chat room. The idea clashes with the work that is 
currently taking place in XCON, which is defining a generic protocol for 
manipulating conference servers.

We also decided some time ago to have reduced scope in the MSRP chat 
draft, where we only address a couple of topic, namely nickname handling 
and private messaging. We deferred to XCON with generic and more 
sophisticated procedures.

So moving into a direction of a generic MSRP method for controlling chat 
rooms will not allow users of SIP MESSAGE to use either. We will not be 
able to reuse the procedures for non-text conferences (e.g., audio, video).

I think the topic is worth discussing, but we need to consider all the 
aspects.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Qian Sun <[email-masked]>
Date: Tue, 17 Jul 2007 16:12:18 +0800

Hello Miguel,

Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is enough for nickname negotiation. For example:

    MSRP 6959ssdf SEND
    Content-Type: message/cpim
    To: <sip:[email-masked];transport=tcp>
    Content-Type: text/plain
    Content-Disposition: chat-command
    NICKNAME "Alice in Wonderland"
    -------6959ssdf$

The above way is also suitable for SIP MESSAGE or HTTP.

Existing chat services provide users with all kinds of chat commands, we can not standardize so many commands. A more extensible approach should be considered.

In the above example, the chat commands are sent by using the same channel as chat text. It is also possible that the chat commands are sent by using a separate channel, e.g. control channel defining in XCON. Only a control element <chat-command> is needed to define.

Could we specify a generic mechanism about chat commands for text-supported chat service in a separate spec (probably in XCON)? The frequently used chat commands could be enumerated in this spec.

Cheers,
Qian

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 5:59 PM
To: Qian Sun
Cc: 'SIMPLE mailing list'
Subject: Re: [Simple] Nickname negotiation

Hi Qian:

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 17 Jul 2007 14:05:59 +0300

Hi Quian:

There is a bit of history for the existence of the NICKNAME method. 
Sometime ago, when we didn't have the SDP extensions to determine 
whether the chat room server supported and allowed nicknames, we needed 
a mechanism to differentiate setting a nickname from sending a regular 
message. We decided to define a new method, because if the chat room 
server didn't support it, it would reply with an MSRP 501 response. If 
we had only the SEND request as you suggest, and the server didn't 
support nicknames, it would answer with a 200 response and the user 
wouldn't know what has happened.

Now we could argue that this his history, and due to the SDP a=chatroom 
attribute, the UE discovers the server support for nicknames and private 
messaging and the use case would only be an error case. I agree, but I 
feel more comfortable separating SEND requests that carry instant 
messages from commands to be understood by the chat server. To make some 
analogy, MSRP defines also AUTH and REPORT requests, which 
differentiates them from SEND requests. Both AUTH and REPORT could have 
been adapted to be send in SEND requests, but the semantics of the SEND 
method would be dismissed. So I think we need to follow the MSRP model 
and use a different method name when the semantics are different from 
those of SEND: "render the message to the user".

Now, the other topic, which you started in a previous e-mail. Should we 
generalize NICKNAME and call it CHAT-COMMAND or something else, which 
can be generally used for sending commands to a chat room? As I said 
before, this requires a careful analysis and some agreement on how much 
do we want to use MSRP for controlling chat rooms versus how much do we 
want to use the conference protocol under development in XCON. With the 
agreements we made in the past, we in SIMPLE are going to have the 
minimum mechanisms to enable chat rooms. A full fledged solution will 
come from XCON. You can challenge these agreements, of course. I am just 
giving a bit of background of how we came to this point.

Do we have any other opinions in the group?

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Jul 2007 09:20:36 -0400

I think I agree with Miguel. But maybe I don't understand Qian.

Is the example Qian gave intended to be recognized and acted upon by 
software in the receiving node? Or is it intended to be treated as the 
simple text message that it appears to be, and displayed by conference 
participants like any other message?

I don't like attaching special significance in software to "ordinary" 
messages.

	Paul

Miguel Garcia wrote:
>> Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is 
>> enough for nickname negotiation. For example:
>>
>>     MSRP 6959ssdf SEND
>> Existing chat services provide users with all kinds of chat commands, 
>> we can not standardize so many commands. A more extensible approach 
>> should be considered.
>>
>> In the above example, the chat commands are sent by using the same 
>> channel as chat text. It is also possible that the chat commands are 
>> sent by using a separate channel, e.g. control channel defining in 
>> XCON. Only a control element <chat-command> is needed to define.
>>
>> Could we specify a generic mechanism about chat commands for 
>> text-supported chat service in a separate spec (probably in XCON)? The 
>> frequently used chat commands could be enumerated in this spec.
>>
>> Cheers,
>> Qian
>>
>> From: Miguel Garcia [mailto:[email-masked]] Sent: Monday, July 
>> 16, 2007 5:59 PM
>> To: Qian Sun
>> Interesting topic... So, you are suggesting to generalize the 
>> semantics and method name of NICKNAME and instead having something 
>> more generic, such as CHAT-COMMAND. This will be equivalent to the 
>> "//" in commercial chat rooms. Then there should be a subcommand that 
>> demultiplex and indicates the specific action.
>>
>> Also, we need to first discuss whether MSRP is the protocol that we 
>> want to use to command a chat room. The idea clashes with the work 
>> that is currently taking place in XCON, which is defining a generic 
>> protocol for manipulating conference servers.
>>
>> draft, where we only address a couple of topic, namely nickname 
>> handling and private messaging. We deferred to XCON with generic and 
>> more sophisticated procedures.
>>
>> So moving into a direction of a generic MSRP method for controlling 
>> chat rooms will not allow users of SIP MESSAGE to use either. We will 
>> not be able to reuse the procedures for non-text conferences (e.g., 
>> audio, video).
>>
>>> There was a long discussion about nickname. Here just a suggest for 
>>> nickname negotiation, could we use a litle more genenal approach 
>>> instead of MSRP method "NICKNAME"?
>>>
>>> In many chat systems, it is very simple to set or modify nickname, 
>>> just send a text-based command like "//nickname spiderman". In 
>>> addition to nickname there are also many other chat commands, e.g. 
>>> "emote", or change rooms in the chat lobby.
>>>
>>> On the other hand, some users may connect to a MSRP chatroom via SIP 
>>> MESSAGE or HTTP. They can not use the MSRP method "NICKNAME".
>>>
>>> <sip:[email-masked]>
>>>
>>> To "emote" function:

---

From: Qian Sun <[email-masked]>
Date: Wed, 18 Jul 2007 10:19:29 +0800

Hi, Miguel and Paul

Thanks for your clarification!  

If we want the user know the chat room server don't support nicknames, we still have solution by using only SEND request. Fox example:
    MSRP 6959ssdf SEND
    Content-Type: text/plain
    Content-Disposition: chat-command-response
    Content-ID: <CID: [email-masked]>
    Command "NICKNAME" is not supported!
    -------6959ssdf$

The chat server may deliver the chat command response by using a SEND message. The Content-ID in the chat command response is identical with that in the corresponding chat command.

And the chat client or server can differentiates chat commands and command response from "ordinary" messages by Content-Disposition.

For the users who connect to chat room via SIP MESSAGE, the above way also works:
A user sends a SIP MESSAGE including chat command, the chat server return 200 OK. Then the chat server sends a SIP MESSAGE including the corresponding chat command response.

Cheers,
Qian

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 7:06 PM
To: Qian Sun
Cc: 'SIMPLE mailing list'; Niemi Aki
Subject: Re: [Simple] Nickname negotiation

Hi Quian:

/Miguel

Qian Sun wrote:
>     Content-ID: <CID: [email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Jul 2007 22:29:30 -0400

Qian,

I missed the content-disposition in your original example. Now that I 
see it, it resolves one of my concerns about your proposal.

That would still leave a couple of issues:
- where is the specification of the "command-chat" content-disposition?
   Unless there is an agreement of what it makes sense to send with this
   disposition it isn't interoperable.
- how do you know the peer you are sending to understands this
   disposition?

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 18 Jul 2007 09:42:19 +0300

Hi:

With respect your example, I guess we should still wrap everything in 
message/cpim, because the chat room server will always look into the To 
header of the message/cpim wrapper to determine whether the message is a 
private message (even for the server itself) or to be distributed to the 
world).

But even though, I don't like this multiplexing. What is the benefit? 
Implementing a new method is not so complicated, besides, we have 
already specified other 2 in MSRP. I think this is exactly what methods 
are for: to be specific on the semantics.

I also disagree with your statements about MESSAGE. I think a chat room 
should have minimum support (if any) for MESSAGE. MESSAGE is the IETF 
solution for page mode messaging, not for session mode. MESSAGE has so 
many problems that I doubt any chat room will provide support for it (I 
may be wrong as well :-)

/Miguel

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 Jul 2007 09:07:03 -0500

To reinforce what Miguel says - we've had this kind of discussion in  
the process of developing other protocols
that are method extensible. The conclusion of those discussions has  
always been that the fundamental meaning
of the method shouldn't be changed by the side-effect of adding new  
headers. We build extension points in instead.
In the case of MSRP, the easiest extension point is to add a method.

RjS

On Jul 18, 2007, at 1:42 AM, Miguel Garcia wrote:

> Hi:
>
> With respect your example, I guess we should still wrap everything  
> in message/cpim, because the chat room server will always look into  
> the To header of the message/cpim wrapper to determine whether the  
> message is a private message (even for the server itself) or to be  
> distributed to the world).
>
> But even though, I don't like this multiplexing. What is the  
> benefit? Implementing a new method is not so complicated, besides,  
> we have already specified other 2 in MSRP. I think this is exactly  
> what methods are for: to be specific on the semantics.
>
> I also disagree with your statements about MESSAGE. I think a chat  
> room should have minimum support (if any) for MESSAGE. MESSAGE is  
> the IETF solution for page mode messaging, not for session mode.  
> MESSAGE has so many problems that I doubt any chat room will  
> provide support for it (I may be wrong as well :-)
>
> /Miguel
>
>
> Qian Sun wrote:
>> Hi, Miguel and Paul
>> Thanks for your clarification!  If we want the user know the chat  
>> room server don't support nicknames, we still have solution by  
>> using only SEND request. Fox example:
>>     MSRP 6959ssdf SEND
>>     Content-Type: text/plain
>> The chat server may deliver the chat command response by using a  
>> SEND message. The Content-ID in the chat command response is  
>> identical with that in the corresponding chat command.
>> And the chat client or server can differentiates chat commands and  
>> command response from "ordinary" messages by Content-Disposition.
>> A user sends a SIP MESSAGE including chat command, the chat server  
>> return 200 OK. Then the chat server sends a SIP MESSAGE including  
>> the corresponding chat command response.
>> Cheers,
>> Qian
>> From: Miguel Garcia [mailto:[email-masked]] Sent: Tuesday,  
>> July 17, 2007 7:06 PM
>> To: Qian Sun
>> There is a bit of history for the existence of the NICKNAME  
>> method. Sometime ago, when we didn't have the SDP extensions to  
>> determine whether the chat room server supported and allowed  
>> nicknames, we needed a mechanism to differentiate setting a  
>> nickname from sending a regular message. We decided to define a  
>> new method, because if the chat room server didn't support it, it  
>> would reply with an MSRP 501 response. If we had only the SEND  
>> request as you suggest, and the server didn't support nicknames,  
>> it would answer with a 200 response and the user wouldn't know  
>> what has happened.
>> Now we could argue that this his history, and due to the SDP  
>> a=chatroom attribute, the UE discovers the server support for  
>> nicknames and private messaging and the use case would only be an  
>> error case. I agree, but I feel more comfortable separating SEND  
>> requests that carry instant messages from commands to be  
>> understood by the chat server. To make some analogy, MSRP defines  
>> also AUTH and REPORT requests, which differentiates them from SEND  
>> requests. Both AUTH and REPORT could have been adapted to be send  
>> in SEND requests, but the semantics of the SEND method would be  
>> dismissed. So I think we need to follow the MSRP model and use a  
>> different method name when the semantics are different from those  
>> of SEND: "render the message to the user".
>> Now, the other topic, which you started in a previous e-mail.  
>> Should we generalize NICKNAME and call it CHAT-COMMAND or  
>> something else, which can be generally used for sending commands  
>> to a chat room? As I said before, this requires a careful analysis  
>> and some agreement on how much do we want to use MSRP for  
>> controlling chat rooms versus how much do we want to use the  
>> conference protocol under development in XCON. With the agreements  
>> we made in the past, we in SIMPLE are going to have the minimum  
>> mechanisms to enable chat rooms. A full fledged solution will come  
>> from XCON. You can challenge these agreements, of course. I am  
>> just giving a bit of background of how we came to this point.
>>> Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND  
>>> is enough for nickname negotiation. For example:
>>>
>>>     MSRP 6959ssdf SEND
>>> Existing chat services provide users with all kinds of chat  
>>> commands, we can not standardize so many commands. A more  
>>> extensible approach should be considered.
>>>
>>> In the above example, the chat commands are sent by using the  
>>> same channel as chat text. It is also possible that the chat  
>>> commands are sent by using a separate channel, e.g. control  
>>> channel defining in XCON. Only a control element <chat-command>  
>>> is needed to define.
>>>
>>> Could we specify a generic mechanism about chat commands for text- 
>>> supported chat service in a separate spec (probably in XCON)? The  
>>> From: Miguel Garcia [mailto:[email-masked]] Sent: Monday,  
>>> July 16, 2007 5:59 PM
>>> To: Qian Sun
>>> semantics and method name of NICKNAME and instead having  
>>> something more generic, such as CHAT-COMMAND. This will be  
>>> equivalent to the "//" in commercial chat rooms. Then there  
>>> should be a subcommand that demultiplex and indicates the  
>>> specific action.
>>>
>>> Here we need to get the balance between be specific and  
>>> generality. Also, we need to first discuss whether MSRP is the  
>>> protocol that we want to use to command a chat room. The idea  
>>> clashes with the work that is currently taking place in XCON,  
>>> which is defining a generic protocol for manipulating conference  
>>> servers.
>>>
>>> We also decided some time ago to have reduced scope in the MSRP  
>>> chat draft, where we only address a couple of topic, namely  
>>> nickname handling and private messaging. We deferred to XCON with  
>>> generic and more sophisticated procedures.
>>>
>>> So moving into a direction of a generic MSRP method for  
>>> controlling chat rooms will not allow users of SIP MESSAGE to use  
>>> either. We will not be able to reuse the procedures for non-text  
>>> conferences (e.g., audio, video).
>>>
>>> I think the topic is worth discussing, but we need to consider  
>>> all the aspects.
>>>
>>> /Miguel
>>>
>>>
>>>
>>> Qian Sun wrote:
>>>> Hi,
>>>> There was a long discussion about nickname. Here just a suggest  
>>>> for nickname negotiation, could we use a litle more genenal  
>>>> approach instead of MSRP method "NICKNAME"?
>>>>
>>>> In many chat systems, it is very simple to set or modify  
>>>> nickname, just send a text-based command like "//nickname  
>>>> spiderman". In addition to nickname there are also many other  
>>>> chat commands, e.g. "emote", or change rooms in the chat lobby.
>>>>
>>>> On the other hand, some users may connect to a MSRP chatroom via  
>>>> SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME".
>>>>