Subject: [Simple] Discussion on draft-ietf-simple-chat-06

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 06 May 2010 09:13:34 +0200

Hi:

I want to discuss some aspects of the multipart chat that I believe we 
haven't covered with enough detail in the document.

Issue 1: Private messages to non participants
=============================================
The current draft says that a SIP session establishes an MSRP session for 
the purpose of joining a chat room. I want to stress the point that one 
SIP session implies one MSRP session and one chat room. Once the user has 
joined a chat room, he can also send private messages to participants of 
that room.

On receiving a private message (i.e., the CPIM To header is address to a 
URI different than the chat room URI), the MSRP switch should verify that 
the recipient is a participant of the same chat room where the sender is 
also participating. It is not the intention of private messages to be 
sent to other recipients outside the chat room. I think this point is not 
clearly specified in the draft, so I think we need to have normative text 
saying that on receiving a private message the MSRP switch MUST verify 
that the recipient is a participant of the chat room. The MSRP switch can 
easily perform this verification by inspecting the MSRP session 
(remember, one MSRP session equals one chat room). If the recipient of 
the private message is not a participant of the chat room, the MSRP 
switch should return a 404 response back to the sender.

The related text in the draft is located in the last paragraph of Section 
6.3, and says:

    If the To
    header field of the Message/CPIM wrapper in the request does not
    contain the chat room URI, it must check if it contains a
    participants URI associated with a participant.  If the URI in the To
    header can not be resolved (e.g. caused by a mistyped URI or that the
    recipient has abandoned he chat room), the response error code is
    404.  The new 404 status code indicates a failure to resolve the
    recipient URI in the To header field.

Issue 2: Participant connected to several chat rooms
====================================================
Connected to the above... I think the draft should pay a bit more 
attention to a participant who is connected to two or more chat rooms 
hosted at the same MSRP server. Here is some assumptions that the draft 
should clearly state:

a) One SIP session implies one MSRP session and one chat room. If a user 
wants to simultaneously join a second chat room hosted by the same 
server, he should establish a new SIP session, a new MSRP session to the 
new chat room. It is possible that both MSRP sessions share the same TCP 
connection, as per regular MSRP procedures.

Question, is the above OK? An alternative is to re-INVITE adding a second 
MSRP session to the SDP, in which case, we loose the one SIP session 
equals one MSRP session? Do we foresee problems?

In any case, no matter what the solution is, the draft has to say 
something for connection of a participant to multiple chat rooms.

Issue 3: The CPIM To header
============================
We said in Issue 1 that the MSRP session is used as an kind of identifier 
of the chat room. The draft says that the CPIM To header is used to 
distinguish a regular message to the chat room (addressed to the chat 
room URI in the CPIM To header) from private messages (addressed to the 
SIP URI or equivalent URI of the recipient user). Question: do we need 
the CPIM To header for sending regular messages to the chat room? We said 
that the MSRP session is used as an identifier of the chat room.

My take is that we should keep on populating the CPIM To header with the 
chat room URI, even it is not used, but just for completeness. However, I 
suspect there are middle boxes out there that obfuscate the chat room 
URI, even in the CPIM To header, before the message arrives at the MSRP 
switch. This makes the MSRP switch believe that the message is private 
(since it is not addressed to the chat room URI), but addressed to a 
recipient that is not participating in the chat room, therefore, 
rejecting the message.

I would suggest that we still keep the CPIM To header for chat room URIs 
but we provide guidelines for middle boxes for not modifying this header.

Now, please, comment any Issue of this e-mail

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 May 2010 09:36:37 -0500

I agree with your recommendations on issues 1 and 3. I want to explore the "one SIP session, one chat room" assumption a little more (below).

On May 6, 2010, at 2:13 AM, Miguel A. Garcia wrote:

[...]

> Connected to the above... I think the draft should pay a bit more attention to a participant who is connected to two or more chat rooms hosted at the same MSRP server. Here is some assumptions that the draft should clearly state:
> 
> a) One SIP session implies one MSRP session and one chat room. If a user wants to simultaneously join a second chat room hosted by the same server, he should establish a new SIP session, a new MSRP session to the new chat room. It is possible that both MSRP sessions share the same TCP connection, as per regular MSRP procedures.
> 
> Question, is the above OK? An alternative is to re-INVITE adding a second MSRP session to the SDP, in which case, we loose the one SIP session equals one MSRP session? Do we foresee problems?
> 
> In any case, no matter what the solution is, the draft has to say something for connection of a participant to multiple chat rooms.
> 

I agree that 1 SIP dialog = 1 MSRP session = 1 chat room is likely to be the most common case, but what breaks if a user agent makes different assumptions about the relationship between SIP dialogs and chat rooms? Is there an interop issue if one user agent uses a new dialog for a separate session, and another uses a re-invite?

Obviously, the user agent has to support the "new dialog" model, since it might be in simultaneous chat rooms hosted by different focii. Maybe there could be load-sharing difficulties if the UA assumes that all chat sessions for a particular focus are terminated on the same physical device?

I do lean towards saying that 1 MSRP session = 1 chat room. I guess one could even skip that if you pay attention to the CPIM To header, but I don't think you would gain much by combining multiple chat rooms into 1 CPIM session that you would not also gain by having separate sessions on the same TCP connection. And, it would make your issue 1 harder to resolve.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 May 2010 12:32:13 -0500

> I do lean towards saying that 1 MSRP session = 1 chat room. I guess one could even skip that if you pay attention to the CPIM To header, but I don't think you would gain much by combining multiple…

Oh, wait, we're really talking about identifying a chat room with a SIP URI, right? In which case, never mind, I agree with you on all points. Sorry, just got back from vacation and my brain is not all the way in gear yet.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 07 May 2010 09:27:20 +0200

Hi Ben:

Yeap, the chat room is identified by a SIP URI, so, obviously this 
requires a new SIP dialog, and rules out the re-INVITE.

So, I propose that we take all these three considerations to the draft in 
a new version.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Fri, 7 May 2010 15:34:24 +0200

Miguel,

I very much agree on all your proposed changes. 

Some text on issue 1 will help to avoid implementing unwanted behavior
in the switches.  

Issue 2 has probably come across as implicit, but making things explicit
will definitely help with interoperability.  

I have thought back and forth on issue 3, but haven't found any elegant
solution to make middle boxes treat the CPIM header as an opaque object.
My take on this so far is that creating special behavior depending on
message destination creates more problems - than replacing the To header
in the middle box.

Thanks,
Geir Arne

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: 6. mai 2010 09:14
> To: Aki Niemi; Geir Arne Sandbakken; Simple WG
> Subject: Discussion on draft-ietf-simple-chat-06
> 
> Hi:
> 
> chat room URI, even it is not used, but just for completeness.
However,
> I

---

From: Ben Campbell <[email-masked]>
Date: Fri, 7 May 2010 09:02:42 -0500

<as individual>

> message destination creates more problems - than replacing the To header

I don't think you need anything normative, and specifying middle box behavior is probably out of scope. Just a mention that if middle boxes mess with the header, things will break would probably be good enough.

---

From: Nancy Greene <[email-masked]>
Date: Fri, 7 May 2010 10:09:15 -0400

It seems to me it would be better to completely remove the requirement for clients to include the chat room URI in the CPIM To header. There is no need for it to be there.

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: May-07-10 10:03 AM
To: Geir Arne Sandbakken
Cc: Aki Niemi; Simple WG
Subject: Re: [Simple] Discussion on draft-ietf-simple-chat-06

<as individual>

On May 7, 2010, at 8:34 AM, "Geir Arne Sandbakken" <[email-masked]> wrote:

> Issue 2 has probably come across as implicit, but making things 
> explicit will definitely help with interoperability.
> 
> I have thought back and forth on issue 3, but haven't found any 
> elegant solution to make middle boxes treat the CPIM header as an opaque object.
> message destination creates more problems - than replacing the To 
> header in the middle box.
> 

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 10 May 2010 09:13:24 +0200

> I don't think you need anything normative, and specifying middle box behavior is probably out of scope. Just a mention that if middle boxes mess with the header, things will break would probably be…

Agreed.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Nancy Greene <[email-masked]>
Date: Mon, 10 May 2010 14:21:00 -0400

I would still prefer to avoid the whole potential middle box issue. Why mix signalling and transport? 

If we still want to keep the CPIM To, how about having the client put in the CPIM To the URI that it used to create the chat instead of the unique chat URI returned from the focus? The value of this one is not dependent on the signalling.

Otherwise, we could just say that clients only include the CPIM To when the MSRP SEND is a private message.

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel A. Garcia
Sent: May-10-10 3:13 AM
To: Ben Campbell
Cc: Geir Arne Sandbakken; Aki Niemi; Simple WG
Subject: Re: [Simple] Discussion on draft-ietf-simple-chat-06

Agreed.

/Miguel

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 11 May 2010 08:50:17 +0200

I think the question here is whether we specify a protocol around a 
particular implementation of a middle box or whether we specify the 
protocol according to what we believe the protocol should do. Let me 
question what would happen if in the future we find another 
implementation of another middle box that does also something strange to 
MSRP, perhaps in a way that is incompatible with this first middle box? 
We all know the pros and cons of middle boxes, one of the cons is that 
they need to support all the extensions of all the protocols that are 
allowed to go through.

It is true that for non-private messages (e.g., those addressed to the 
whole chat room), the CPIM To header is not relevant, because the MSRP 
session is mapped to the chat room, therefore you can say we can ignore it.

But on the other hand, letting the CPIM To header be there with its 
correct value will make the protocol more robust, easier to debug 
(because it is self contained), and future proof.

Honestly, I think we should keep the CPIM To header as it is in the 
current version of the draft.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 May 2010 12:47:18 -0500

<as-individual>

I agree with Miguel in spirit on this point. We can't build protocol around speculation about what an SBC might or might not do. 

Also, leaving out the To header from a CPIM envelope violates a normative requirement from RFC 4975 section 13, which says "All message/cpim body parts sent by an MSRP endpoint MUST include the From and To header fields." If we think that requirement was in error, we can go back and address it in general--but the chat draft is not the place for that.

But, some things to think about: 

Have we described how the switch should behave if it gets a message without a CPIM To header? What about no CPIM envelope at all? Should the switch reject these as errors, or make some guesses based on the MSRP session and associated SIP dialog? (I'm not saying we haven't specified these--I have not yet gone back to the draft to check.)

On May 11, 2010, at 1:50 AM, Miguel A. Garcia wrote:

> I think the question here is whether we specify a protocol around a particular implementation of a middle box or whether we specify the protocol according to what we believe the protocol should do. Let me question what would happen if in the future we find another implementation of another middle box that does also something strange to MSRP, perhaps in a way that is incompatible with this first middle box? We all know the pros and cons of middle boxes, one of the cons is that they need to support all the extensions of all the protocols that are allowed to go through.
> 
> It is true that for non-private messages (e.g., those addressed to the whole chat room), the CPIM To header is not relevant, because the MSRP session is mapped to the chat room, therefore you can say we can ignore it.
> 
> But on the other hand, letting the CPIM To header be there with its correct value will make the protocol more robust, easier to debug (because it is self contained), and future proof.
> 
> Honestly, I think we should keep the CPIM To header as it is in the current version of the draft.
> 
> /Miguel
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 May 2010 09:39:30 +0200

Ben,

Good point in checking Section 13 of RFC 4975. I think this closes the 
discussion on the CPIM To header.

With respect to the error cases that you mention (absence of CPIM body or 
CPIM To header), probably they are not specified (I need to double check 
it). If we confirm that nothing is specified, we should have some text in 
the draft.

I think a MSRP message without the CPIM body should not be distributed to 
the chat room. I suggest that the MSRP message returns a 404 error 
response. I think the same action can be applies to a CPIM message that 
does not contain a CPIM To header.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 May 2010 11:01:38 -0400

Miguel A. Garcia wrote:

> I think a MSRP message without the CPIM body should not be distributed 
> to the chat room. I suggest that the MSRP message returns a 404 error 
> response.

I would think a 415 response would be more appropriate here, since only 
a CPIM message format is acceptable. (At least the msrp session should 
have been negotiated so that this is the case.)

> I think the same action can be applies to a CPIM message that 

I don't know what the best response is in this case. 404 seems ok.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 May 2010 10:31:02 -0500

(as individual)

On May 12, 2010, at 10:01 AM, Paul Kyzivat wrote:

> 
> 
> Miguel A. Garcia wrote:
> 
>> I think a MSRP message without the CPIM body should not be distributed to the chat room. I suggest that the MSRP message returns a 404 error response.
> 
> I would think a 415 response would be more appropriate here, since only a CPIM message format is acceptable. (At least the msrp session should have been negotiated so that this is the case.)
> 
>> I think the same action can be applies to a CPIM message that does not contain a CPIM To header.
> 

There is no 404 currently defined for MSRP. I'm not sure it's worth defining it for just this. How about 403? (i.e. "not allowed")

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 May 2010 17:39:05 +0200

Right, 415 seems ok for lack of CPIM bodies.

404 for lack of CIMP To header.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 May 2010 10:42:51 -0500

[...]

> There is no 404 currently defined for MSRP. I'm not sure it's worth defining it for just this. How about 403? (i.e. "not allowed")

Oops, never mind--I forgot this draft defines 404 already.