Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

[Sergio Garcia Murillo <[e-mail]>]

Hi Peter,

I think that you misunderstood me. I was not asking you to change the 
MSRP over websocket draft to set the transport to TCP/WSS/MSRP and do it 
like the BFCP over websocket draft, but to find a way that we could both 
use the same solution with the principles that you are mentioning, that is:

-Do not break backward compatibility
-Allow easy implementation for servers which wants to support both 
TCP/TLS and WS/WSS "flavors"

In my case, I will implement both BFCP and MSRP over TCP and Websockets 
in my MCU, so my interest is genuine.. :)

I have a doubt regarding the draft. If I understood it correctly, you 
are only considering P2P in he examples and using a msrp relay in the 
middle to be able to connect a WS to a non WS, but I am not sure how 
would you handle the case when you don't use a relay. Is that possible 
at all?

Best regards
Sergio
El 13/02/2014 17:26, Peter Dunkley escribió:
> Hello,
>
> The method chosen for advertising WebSockets in the SDP for MSRP was 
> picked because it was would enable interoperability with existing MSRP 
> implementations through an MSRP relay without requiring changes to 
> those implementations.  In this scenario advertising WebSockets in the 
> SDP would mean that the existing implementation - which does not need 
> to support WebSockets (the MSRP relay deals with this) - would need to 
> be able to cope with seeing TCP/WSS/MSRP in the SDP.  In all 
> probability existing implementations will not cope with seeing 
> "TCP/WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP" - this would be a 
> big problem.
>
> I have no issue with consistency between the drafts using WebSockets 
> where possible, but in this case doing what is done in the BFCP draft 
> (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical 
> (and in fact may be quite undesirable).
>
> Regards,
>
> Peter
>
>
>
> On 13 February 2014 16:07, Sergio Garcia Murillo 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     What I mean is that I expect quite a lot of "over websocekts"
>     drafts and we should try to use the same solution for advertising
>     it in the SDP, and not have each one have their own way of
>     handling it.
>
>     Best regards
>     Sergio
>
>     El 13/02/2014 16:49, "Mary Barnes" <[e-mail]
>     <mailto:[e-mail]>> escribió:
>
>         Sergio,
>
>         The draft you mention is being discussed in the BFCPBIS WG and
>         any comments that others might have on that document should go
>         to that list.
>
>         It's not clear to me whether your suggestion is that changes
>         are needed to this MSRP document or whether you are just
>         proposing to make the BFCPBIS consistent with this MSRP document?
>
>         Mary.
>
>
>         On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             Hi,
>
>             We also have recently published a different draft for BFCP
>             over websockets:
>             http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00
>
>             I beleive that we should harmonize who the WS transport is
>             signaled and how to signal the WS version if also the
>             "normal" TCP version is supported.
>
>             In your case you seem to be using the same transport line
>             TCP/MSRP and use the path to signal the ws part, in our
>             case, we choose to signal it in the transport TCP/WS/BFCP
>             and include a new attribute ws-uri to signal the full url
>             (I could not reuse the path attribute as it is restricted
>             to msrp urls only).
>
>             Best regards
>             Sergio
>             El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió:
>
>                 Hi Mary -
>
>                 Thanks for taking the time to review the document.  We
>                 have published an -05 that (hopefully) addresses all
>                 your feedback.
>
>                 Inline, trimming to only the points requiring responses...
>
>
>                 On Jan 10, 2014, at 5:58 PM, Mary Barnes
>                 <[e-mail]
>                 <mailto:[e-mail]>> wrote:
>
>                     I have agreed to shepherd this document.  I've
>                     reviewed the document in anticipation of doing the
>                     PROTO write-up and have the following comments and
>                     questions.  Ben Campbell has agreed to do the
>                     required expert review and that should be posted
>                     within the next week or so.    This is also a good
>                     time for anyone in the WG that hasn't previously
>                     reviewed this document to review and provide any
>                     final comments.  Note, that this document was
>                     agreed to be AD sponsored around the IETF-86
>                     timeframe.
>
>                     Regards,
>                     Mary.
>
>                     Review Summary: Almost ready. Comments & questions
>                     below.
>
>                 <snip/>
>
>                     5) Section 10.1. Since securing the connection is
>                     just RECOMMENDED, what are the implications and
>                     risks if the MSRP traffic isn't transported over a
>                     secure connection?
>
>                 Other review comments indicated that it was
>                 problematic to downgrade the 4976 MUST requirement for
>                 TLS between a client and a server. Thus, the document
>                 has been updated so that MSRP traffic transported over
>                 WebSockets MUST be protected by using a secure
>                 WebSocket connection (i.e., using TLS).  I believe
>                 this renders this point moot.
>
>                 <snip/>
>
>                     8) It's typical for documents that are updating
>                     existing RFCs to have a section that summarizes
>                     the updates to the existing RFCs that are made by
>                     this document.
>
>                 This was the intent of Sections 5.2 and 5.3.  Is this
>                 sufficient? Or did you have something else in mind?
>
>                 Regards,
>
>                 Gonzalo
>
>                 _______________________________________________
>                 dispatch mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/dispatch
>
>
>             _______________________________________________
>             dispatch mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>     _______________________________________________
>     dispatch mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd