Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Peter Dunkley <peter.dunkley@crocodilertc.net> Thu, 13 February 2014 21:24 UTC
Return-Path: <peter.dunkley@crocodilertc.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA111A0504 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 13:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR0K3MsAeKRR for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 13:24:56 -0800 (PST)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id F3DF21A0429 for <dispatch@ietf.org>; Thu, 13 Feb 2014 13:24:55 -0800 (PST)
Received: by mail-ve0-f180.google.com with SMTP id db12so8750783veb.25 for <dispatch@ietf.org>; Thu, 13 Feb 2014 13:24:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EGJLUxQAVoLXJWCwEN3U4bNeNWAGNaMqmRmeopsNVCo=; b=Xbjz/ulGA3HO+4t9RfjQ0pEAibkcSI4gXwgfsRIvAsws4qmF15kZb9SqDfXvWZm5T7 bL29hoU5GigYaa7COC/fc6PdKxroqcHUzSPQSt5Oz9FL316V6n0I2gZS7Q1f9//c0acm yIqh3QD4a4cK0r8A3GvwMQrxSUxiO22n2vl3Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EGJLUxQAVoLXJWCwEN3U4bNeNWAGNaMqmRmeopsNVCo=; b=IJo2YRRyG9a5WvDQUBN1JW435eqkg5BGbulqm3r7cJ/FnQU1ZD68wkryhOh4hDOzYM pyldjGiG6jeYQeW85ye7X/Qcn3H6WkIhC8D9IFtaRWcYd/Bjw2u/R9X/uD70pFsofWvP mcPJMLoHEK3H1fosN3LDTv+BbvRUWup4CyfkYBzFAs4i23hhyuU0t9iSD0wixkv54g+i 8jJeugFhz1pl7DDk3/TU+6sU86FTTIUFvVeBqZRRrKgKpe1YoIuf9WNCiqhWnt/Ksi5K TypzP6edoBb9qg6GCDE9XExjrmu6su6ZtM0S8WLqe5XUrgFOr0YxO1dWNwpZE/1qpVA2 Ky7w==
X-Gm-Message-State: ALoCoQmXjHBjCGEEXSsN5IWsDAc3piw+mgn0KPAV1IQbgVVV0NJM4M5InpzX/gIyzIgQk2MaJ1sh
MIME-Version: 1.0
X-Received: by 10.220.92.135 with SMTP id r7mr2326554vcm.11.1392326694526; Thu, 13 Feb 2014 13:24:54 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:24:54 -0800 (PST)
In-Reply-To: <52FD36A3.1020606@gmail.com>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <CAHBDyN4tSRO_nYy7_-V4xfmDbF0ZeLJ24_fEOQ1p9Z2BvJyinQ@mail.gmail.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <CAHBDyN7hySvbiJYnvRXDQ2ZS_FYFDMaODXBDRarE6DhRwC=fHQ@mail.gmail.com> <CA+ag07bPBHzODTWGKFrKE00nO_wiMgRv2GEwUpGCiH25-Xf2Cw@mail.gmail.com> <CAEqTk6Reb=29kxeOUyPxAnhkRGqORHRoUchz5=hE4UNMggDnag@mail.gmail.com> <52FD36A3.1020606@gmail.com>
Date: Thu, 13 Feb 2014 21:24:54 +0000
Message-ID: <CAEqTk6R1bEG2=fr70zLXLC2MxC11b7ekHqZP4S8L_0s+v83DDw@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b66f5fb09fb4a04f25052a8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/DJfdCHWRXU3PJGYrk-gqee-zAj0
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 21:24:59 -0000
Hello, Because WebSockets is an asynchronous protocol two MSRP peers (that are clients) cannot use MSRP over WebSockets. It could be possible for a WebSocket server to be an MSRP peer (for example, in the scenario where the server is B2B'ing MSRP like an SBC will do in IMS for CEMA). Christer Holmberg has expressed an interest in this scenario and may provide language relating to it for the draft - but for now this is out of the scope of the draft which explicitly deals just with with the MSRP through relay scenario. If Christer does provide some additional language then the draft will cover this without relay scenario, but if not nothing in the draft should prevent someone from addressing it in the future with an additional document (should there be interest). >From my point-of-view I am only interested in the with relay scenario at this time. Regards, Peter On 13 February 2014 21:18, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > 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 < > sergio.garcia.murillo@gmail.com> 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" <mary.ietf.barnes@gmail.com> >> 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 < >>> sergio.garcia.murillo@gmail.com> 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 <mary.ietf.barnes@gmail.com> >>>>> 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 >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > > > -- Peter Dunkley Technical Director Crocodile RCS Ltd
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Mary Barnes
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Peter Dunkley
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Ben Campbell
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Peter Dunkley
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Gonzalo Salgueiro (gsalguei)
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Victor Pascual
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Gonzalo Salgueiro (gsalguei)
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Christer Holmberg
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Gonzalo Salgueiro (gsalguei)
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Cullen Jennings (fluffy)
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Gonzalo Salgueiro (gsalguei)
- Re: [dispatch] X over websockets Paul Kyzivat
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Peter Dunkley
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Sergio Garcia Murillo
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Mary Barnes
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Sergio Garcia Murillo
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Sergio Garcia Murillo
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Peter Dunkley
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Peter Dunkley
- [dispatch] X over websockets Paul Kyzivat
- Re: [dispatch] X over websockets Sergio Garcia Murillo
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Sergio Garcia Murillo
- Re: [dispatch] X over websockets Paul Kyzivat
- Re: [dispatch] X over websockets Peter Dunkley
- Re: [dispatch] X over websockets Sergio Garcia Murillo
- Re: [dispatch] X over websockets Peter Dunkley
- Re: [dispatch] X over websockets Sergio Garcia Murillo
- Re: [dispatch] X over websockets Peter Dunkley
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Sergio Garcia Murillo
- Re: [dispatch] X over websockets Mary Barnes
- Re: [dispatch] X over websockets Mary Barnes
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Cullen Jennings
- Re: [dispatch] X over websockets Cullen Jennings
- Re: [dispatch] I-D Action: draft-pd-dispatch-msrp… Peter Dunkley
- Re: [dispatch] X over websockets Sergio Garcia Murillo