Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 2 Jan 2013 09:34:55 +0100

Hi,

Thanks for putting this together, I do support this work.

A few comments from an initial (and shallow) read:

- Section 5.3.1: why mandate authentication? Is there a specific reason for this or could it be left out as an implementation detail?
- Section 6: maybe it should be mentioned that in the absence of a WS pint mechanism the defined MSRP way (that is, an empty SEND) should be used?

Given the limitations of WS with regards to receiving incoming connections, I think this document should mention how ACM (http://tools.ietf.org/html/rfc6135) should be used in WS scenarios.

Keep up the good work!

Regards,

On Dec 17, 2012, at 11:29 PM, Victor Pascual Avila wrote:

> Dear DISPATCH,
> 
> comments on the draft below[1] would be appreciated. The proposed mechanism has been implemented and there's open-source code available for both client[2] and server[3] side implementations.
> 
> [1] http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00
> [2] http://code.google.com/p/crocodile-msrp/wiki/Overview
> [3] http://www.kamailio.org/wiki/features/new-in-devel#websocket
> 
> Thanks,
> Peter, Gavin and Victor
> 
> On 12/17/12 5:15 PM, "[email-masked]" <[email-masked]>
> wrote:
> 
> >
> >A new version of I-D, draft-pd-dispatch-msrp-websocket-00.txt
> >has been successfully submitted by Peter Dunkley and posted to the
> >IETF repository.
> >
> >Filename:       draft-pd-dispatch-msrp-websocket
> >Revision:       00
> >Title:          The WebSocket Protocol as a Transport for the Message Session
> >Relay Protocol (MSRP)
> >Creation date:  2012-12-17
> >WG ID:          Individual Submission
> >Number of pages: 19
> >URL:
> >http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-00.tx
> >t
> >Status:
> >http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
> >Htmlized:
> >http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00
> >
> >
> >Abstract:
> >   The WebSocket protocol enables two-way real-time communication
> >   between clients and servers.  This document specifies a new WebSocket
> >   sub-protocol as a reliable transport mechanism between MSRP (Message
> >   Session Relay Protocol) clients and relays to enable usage of MSRP in
> >   new scenarios.  This document normatively updates RFC 4975 and RFC
> >   4976.
> >
> >
> >
> >
> >
> >The IETF Secretariat
> >
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 Jan 2013 16:10:13 +0100

Hi all,

I support this work and, in fact, plan to implement it.

The only point I don't like (until a deeper review) is 5.2.2, it seems
a hack IMHO.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: José Luis Millán <[email-masked]>
Date: Fri, 4 Jan 2013 19:45:25 +0100

Dear all,

I also support this work and plan to implement it.

Thank you for this work.

2013/1/4 Iñaki Baz Castillo <[email-masked]>

-- 
José Luis Millán

---

From: Peter Dunkley <[email-masked]>
Date: Mon, 07 Jan 2013 17:12:38 +0000

Hi Inaki,

I agree that section 5.2.2 is a hack.  The problem is trying to make
sure that there aren't interworking problems with existing clients
(which may not have robust SDP parsing) without needing to do SDP
mangling in the SIP server.

Any suggestions on how to improve this section would be more than
welcome!

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Peter Dunkley <[email-masked]>
Date: Mon, 07 Jan 2013 17:28:09 +0000

Hi Saul,

I have put comments in-line below.

Thanks,

Peter

> - Section 5.3.1: why mandate authentication? Is there a specific reason for this or could it be left out as an implementation detail?

Section 5.3.1 mandates authentication because RFC 4976 does.  I did not
want to loosen the authentication/security of MSRP relays here but did
want to make sure that an appropriate WebSocket compatible mechanism
(authenticating the handshake) was in place.

At the end of the day, any WebSocket client stack that wants to be able
to use a sequence of relays (for example, intra-net and extra-net) will
need to support the MSRP relay authentication as per RFC 4976 because
the later relays in the sequence will be accessed using TLS from the
earlier relays and may issue challenges.

> - Section 6: maybe it should be mentioned that in the absence of a WS pint mechanism the defined MSRP way (that is, an empty SEND) should be used?

I will add this to the next issue of the draft.

> Given the limitations of WS with regards to receiving incoming connections, I think this document should mention how ACM (http://tools.ietf.org/html/rfc6135) should be used in WS scenarios.

I am not sure this will help:
- a WS client cannot receive an incoming connection at all, so when you
have two WS clients you must have an MSRP relay acting as an WS server
(which the WS clients always initiate the connection to)
- a non-WS client will expect to use TCP or TLS not WS, so to allow it
to interwork with WS clients you must have an MSRP relay acting as an WS
server (which the WS clients always initiate the connection to) to
convert between the transports

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 7 Jan 2013 22:16:57 +0100

Hi Peter,

On Jan 7, 2013, at 6:28 PM, Peter Dunkley wrote:

> Section 5.3.1 mandates authentication because RFC 4976 does.  I did not want to loosen the authentication/security of MSRP relays here but did want to make sure that an appropriate WebSocket compatible mechanism (authenticating the handshake) was in place.
> 
> At the end of the day, any WebSocket client stack that wants to be able to use a sequence of relays (for example, intra-net and extra-net) will need to support the MSRP relay authentication as per RFC 4976 because the later relays in the sequence will be accessed using TLS from the earlier relays and may issue challenges.

Right, I forgot that open relays are explicitly forbidden y 4976.

> - a WS client cannot receive an incoming connection at all, so when you have two WS clients you must have an MSRP relay acting as an WS server (which the WS clients always initiate the connection to)
> - a non-WS client will expect to use TCP or TLS not WS, so to allow it to interwork with WS clients you must have an MSRP relay acting as an WS server (which the WS clients always initiate the connection to) to convert between the transports
> 

Actually, we can use it to our advantage. Using an outbound relay didn't make any sense until ACM came out. With ACM, if a user is using a relay it can set a=setup:actpass, because it's very likely that the relay is able to handle the incoming connection without any problem. That said, and given that a=setup:passive is not allowed in an offer, I guess there is nothing to be said about ACM in the end, it just works :-) Sorry for the noise there.

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Gavin Llewellyn <[email-masked]>
Date: Tue, 08 Jan 2013 14:02:12 +0000

Inaki,

IMHO, the SDP is correct - the SDP negotiation is trying to set up the 
leg beyond the WebSocket MSRP relay, and this is expected to be a TCP or 
TLS connection.  The WebSocket leg of the relay chain is already 
established when the SDP is constructed, and isn't relevant to the far 
end (though it can be spotted from the URIs in the path attribute if 
necessary).

I think we'd have more work to do if we wanted to negotiate some other 
MSRP transport beyond the relay, but since the WebSocket transport is 
only used (and only useful) at the edges of the link I don't think the 
SDP needs to change.

Regards,
Gavin

Gavin Llewellyn
Principal Design Engineer
Crocodile RCS Ltd

On 07/01/2013 17:12, Peter Dunkley wrote:
> Any suggestions on how to improve this section would be more than welcome!
>
> Peter
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Jan 2013 15:28:04 +0100

2013/1/7 Peter Dunkley <[email-masked]>

> Hi Inaki,
>
> I agree that section 5.2.2 is a hack.  The problem is trying to make sure
> that there aren't interworking problems with existing clients (which may
> not have robust SDP parsing) without needing to do SDP mangling in the SIP
> server.
>

Hi Peter, I understand your concerns, but IMHO a new specification should
not mention that. Obviously when a new specification appears old clients
should be updated if they want to interoperate with the new spec or with
devices using the new spec.

Anyhow RFC 4975 already defines the ;trasport parameter as:

  transport = "tcp" / 1*ALPHANUM

So existing clients MUST NOT assume just "tcp", even less in URI's
they must not directly contact to (which is the case since a non WS
MSRP client won't never directly contact a WS MSRP client, but a TCP
MSRP relay.

IMHO the nex spec cannot allow violating its own grammar. WS clients
should use "ws" transport in the MSRP URI. Have you seen MSRP clients
failing when the SDP includes a MSRP URI with "ws" transport?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Gavin Llewellyn <[email-masked]>
Date: Tue, 08 Jan 2013 15:23:05 +0000

Inaki,

OK, I understand what you mean now.  It is not our intention to hide the 
"ws" parameter in the URIs; the section was instead referring to the 
protocol component of the m-line.  I suggest that 5.2.2 be clarified as 
follows:

    This document does not define a new SDP transport protocol for MSRP
    over WebSockets.  As all MSRP over WebSocket messages MUST be routed
    via an MSRP WebSocket Server, it is acceptable for an MSRP WebSocket
    Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the
    SDP m-line - that being the protocol used by non-WebSocket clients
    and between MSRP relays (RFC 4975 Section 8.1).

    The "ws" transport parameter will appear in the endpoint URI in the
    SDP "path" attribute (RFC 4975 Section 8.2); compliant MSRP
    implementations should already allow unrecognised transports,
    provided that they do not have to establish a direct connection to
    the resource described by the URI.

Does this make more sense?

Regards,
Gavin

Gavin Llewellyn

On 08/01/2013 14:28, Iñaki Baz Castillo wrote:
> 2013/1/7 Peter Dunkley <[email-masked] 
> <mailto:[email-masked]>>
>
>     Hi Inaki,
>
>     I agree that section 5.2.2 is a hack.  The problem is trying to
>     make sure that there aren't interworking problems with existing
>     clients (which may not have robust SDP parsing) without needing to
>     do SDP mangling in the SIP server.
>
> Hi Peter, I understand your concerns, but IMHO a new specification 
> should not mention that. Obviously when a new specification appears 
> old clients should be updated if they want to interoperate with the 
> new spec or with devices using the new spec.
>
> So existing clients MUST NOT assume just "tcp", even less in URI's they must not directly contact to (which is the case since a non WS MSRP client won't never directly contact a WS MSRP client, but a TCP MSRP relay.
> IMHO the nex spec cannot allow violating its own grammar. WS clients should use "ws" transport in the MSRP URI. Have you seen MSRP clients failing when the SDP includes a MSRP URI with "ws" transport?
> -- 
> Iñaki Baz Castillo
> <[email-masked] <mailto:[email-masked]>>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Jan 2013 16:52:01 +0100

2013/1/8 Gavin Llewellyn <[email-masked]>:
> protocol component of the m-line.

Hi Gavin, could you please alter the example in section 11 of RFC 4976
(MSRP Relay) assuming that Alice (initiator) is a WS MSRP client (so
she needs to provide a MSRP line) and Bob a TCP MSRP client (which
needs to provice a TCP MSRP line)?

It could clarify this a bit more.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Gavin Llewellyn <[email-masked]>
Date: Tue, 08 Jan 2013 16:31:50 +0000

We will include some sample SDP in section 8 of the next draft.

Regards,
Gavin

Gavin Llewellyn

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Jan 2013 19:32:26 +0100

> We will include some sample SDP in section 8 of the next draft.

Great. Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Jan 2013 10:29:00 +0100

Hi Gavin, Peter,

I've read revision 01 of the draft. Just some comments related to the
subject below:

2013/1/8 Gavin Llewellyn <[email-masked]>:
> This document does not define a new SDP transport protocol for MSRP over
> WebSockets.  As all MSRP over WebSocket messages MUST be routed via an MSRP
> WebSocket Server, it is acceptable for an MSRP WebSocket Client to specify
> the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line - that being
> the protocol used by non-WebSocket clients and between MSRP relays (RFC 4975
> Section 8.1).

RFC 4975 states in section 8.1:

   An offered or accepted media-line for MSRP over TCP MUST include a
   protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS.

Well, this is not flexible enough so I understand your concerns and
you probably have detected that some existing MSRP devices fail to
negotiate a MSRP session in case the SDP media-line does not contain
"TCP/MSRP" or "TCP/TLS/MSRP".

In fact the media-line is basically cosmetic for MSRP:

      MSRP devices do not use the c-line address field, or the m-line
      port and format list fields to determine where to connect.
      Rather, they use the attributes defined in this specification.
      The connection information is copied to the c-line and m-line for
      purposes of backwards compatibility with conventional SDP usages.
      While MSRP could theoretically carry any media-type, "message" is
      appropriate.

So I'm OK with the current approach (don't define "WS/MSRP" nor
"WSS/MSRP" nor "TLC/WS/MSRP" nor "TCP/TLS/WS/MSRP" nor
"TCP/WSS/MSRP"...).

> The "ws" transport parameter will appear in the endpoint URI in the SDP
> "path" attribute (RFC 4975 Section 8.2); compliant MSRP implementations
> should already allow unrecognised transports, provided that they do not have
> to establish a direct connection to the resource described by the URI.
>

I'm ok with current section 5.2.2 "SDP Transport Protocol" in
draft-pd-dispatch-msrp-websocket-01.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 9 Jan 2013 10:50:55 +0100

> "WSS/MSRP" nor "TLC/WS/MSRP" nor "TCP/TLS/WS/MSRP" nor

+1.

--
Saúl Ibarra Corretgé
AG Projects