Subject: [Simple] 'chatroom' SDP Attribute in simple-chat

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

I'm not convinced that this is the correct way to learn about the 
chatroom/conference capabilities. I would think this is out of scope of 
this draft. Learning conference room capabilities is definitely not in 
scope here.

Hisham

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

---

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

> this draft. Learning conference room capabilities is definitely not in

How would you suggest these chat room capabilities (namely, support for
nicknames and private-messages) are communicated? And why is it not in
scope of this draft when this draft after all defines those features?

Cheers,
Aki

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 20 Mar 2006 13:11:06 +0200

The reason for learning this capabilities in SDP is purely pragmatical. 
You wouldn't like to send private messages through the chat server, 
thinking that the chat server implements that draft, and then find out 
that your messages have been distributed to the whole roaster because 
the chat server didn't implement the draft.

In earlier versions of this draft we implemented a DISTSEND method, so 
that if the chat server does not implement the draft, it will reply back 
with a 4xx response, but the whole point is that the private message 
wouldn't be distributed.

We got quite many comments in the mailing list that private messages 
shouldn't require the implementation of a new method, so we came with 
the conclusion that, due to the MSRP design, where capabilities are 
negotiated in SDP, the only alternative was to design capabilities and 
negotiated in SDP (which is exactly what SDP is suppose to do).

So, if you find a reasonable alternative solution, I am happy to 
consider it, but the requirement is obvious, so we need to design a 
solution for it.

/Miguel

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

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 20 Mar 2006 17:58:16 +0100

Capabilities of a conference server are not limited to private messages 
and chat specific features. There are other capabilities about other 
media that the user might be interested in learning about. Choosing to 
do this in SDP or not is not my concern right now. My concern is that 
any mechanism that we come up with for the user to learn the conference 
server capabilities needs to also take into consideration other media 
and not just IM.

Hisham

On Mar 20, 2006, at 12:11 PM, Miguel Garcia wrote:

> The reason for learning this capabilities in SDP is purely 
> pragmatical. You wouldn't like to send private messages through the 
> chat server, thinking that the chat server implements that draft, and 
> then find out that your messages have been distributed to the whole 
> roaster because the chat server didn't implement the draft.
>
> that if the chat server does not implement the draft, it will reply 
> back with a 4xx response, but the whole point is that the private 
> message wouldn't be distributed.
>
>> chatroom/conference capabilities. I would think this is out of scope 
>> of this draft. Learning conference room capabilities is definitely 
>> not in scope here.
>> Hisham