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

Peter Dunkley <peter.dunkley@crocodilertc.net> Thu, 13 February 2014 21:08 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 B30351A04EC for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 13:08:33 -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 eh_cYhb7u7Sy for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 13:08:31 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F1B941A0376 for <dispatch@ietf.org>; Thu, 13 Feb 2014 13:08:30 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id jw12so1811503veb.32 for <dispatch@ietf.org>; Thu, 13 Feb 2014 13:08:29 -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 :content-type; bh=0uorWBqv2tyYJxIuRvkZyRMR4EIGIxmoKWJ+LNG6/f4=; b=GWeMmTbdgA1VuiokJEZ/keEAyMEIvK5IFly3r7MjGNT3BXyIb3Clwf4PTIkZPPqUb3 a1d+pIPzqwylR6jwNo6kDg2FESXehvM3bKgCLYXbdsIC6aIZOXPht3U2yYaMHNO+duMQ VvVNlC/VMVOvpCDHjnSWgkzL4DVfRrN2tmFkY=
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:content-type; bh=0uorWBqv2tyYJxIuRvkZyRMR4EIGIxmoKWJ+LNG6/f4=; b=B3JV+KhRxhR113DIJ0q0dz8YuPAs3nIfCiaB+2qNjpy0Wvk0cmyyRryutubgQSrtDK zuu5xZoUTXUNRv6+4RuxqaL9uzFBrI2X8OyvV3NaFerc6q6BKxrE1mlWjHB34ESsoqH7 QjrMk8jBI1Odx8/tTOJp/FjiGc7uhBZiPEeHkJBjPiUiYGwxw7c/O13UXOffYiy9HDN4 qER31HO/tdIG+iUW7YLj3prSQofUIaeUhc6wfhkUUHRs4pzxH4ERlTgwAhgvJix5CTvv 3rJh46Ugkn06w1R7HPMXdcj6g26H4dEfhQjBviypjMIBT399+N+aO2wFXc278sr4Nu5/ TEZA==
X-Gm-Message-State: ALoCoQljw8xivLmEnW7ikx6mrg+iBcnsFhUDOLXjiskJ9/jptoGKrRIUxsNIrIbgAXByQSwTPyXH
MIME-Version: 1.0
X-Received: by 10.58.85.133 with SMTP id h5mr2306299vez.4.1392325709338; Thu, 13 Feb 2014 13:08:29 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:08:29 -0800 (PST)
In-Reply-To: <52FD2DC9.6090105@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> <52FD2DC9.6090105@gmail.com>
Date: Thu, 13 Feb 2014 21:08:29 +0000
Message-ID: <CAEqTk6RZdOhNzXN92dk6c=0SPXOCMNAYDVXXbGo9UOMUBFsgmA@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b86f0ba51304d04f25017fc
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/kCVMpV8m4SYHEaOHSFTrVbFX2-8
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:08:33 -0000

Hello,

The problem with attempting to specify something like "TCP/WS/xxx" or
"TCP/WSS/xxx" is that it will make the drafts easy to understand but might
not actually help from an implementation point-of-view.

Sure it'll help the implementer with respect to the specific RFC, but in
the case of MSRP over WebSockets it won't help with the implementer create
something that interoperates with legacy peers through the MSRP relay.
 This is a problem that BFCP might not suffer from, but this kind of
interoperability is desirable and as a result even if this had been
defined/recommended before the work on MSRP over WebSockets started
"TCP/TLS/MSRP" would probably still be used in that draft (unless someone
could find another way to ensure that legacy peers would accept the new SDP
content without issue).

Regards,

Peter



On 13 February 2014 20:40, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>  Hi Mary,
>
> My point is exactly the opposite. We should not choose one or the other,
> it is an issue that affects both drafts, and any upcoming X over websocket
> draft, so I don't think it is a good idea to isolate the discussion in a
> single draft and ignore what is happening outside. If not we will end up
> with lots of different solutions for the same issue and developers (like
> me) will get crazy when trying to implement it.
>
> Best regards
> Sergio
> El 13/02/2014 16:49, Mary Barnes 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