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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Thu, 13 February 2014 15:39 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
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 61BB81A02B4 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 07:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 yctVbzWbuu5s for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 07:38:59 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCA1A02E5 for <dispatch@ietf.org>; Thu, 13 Feb 2014 07:38:55 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hn9so8812448wib.0 for <dispatch@ietf.org>; Thu, 13 Feb 2014 07:38:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QkJDDDkXvrNWtFiLD+JhYbeacajHM0ArcJekjrKhPMk=; b=qg7gknVsfT4OvwsC9T4Sr8c+cF5IKivML0Y/85XLp+tTz90gxxtb+MHrWtiLfYHfj6 Ykejh1jr51FduZSp/IKgrrS/c4E6gbyJUzY/q0BmIjfLF86stX6npTTfj2ODC+rRKJc8 JshTDhrfC0qsQcG1RDUkztabnJaEeWYo35LWARjFkxQZlVXd63A55XNqb8Kmb1GUCneD VoBYoogl1g1YYctag/fljrFHjKQj6wg7lPDFz2WcHshR+rDS4boJQuxgguJWSmeTw1A/ PpAxHDtxDhRR6ZQsOCa7uGSGyrCi6XOn5z8MX4ynQR7yVsPnkNNuLh55GyzMHggbY0j6 9vQQ==
X-Received: by 10.180.11.233 with SMTP id t9mr4314003wib.1.1392305934364; Thu, 13 Feb 2014 07:38:54 -0800 (PST)
Received: from [192.168.1.66] (66.Red-79-154-146.dynamicIP.rima-tde.net. [79.154.146.66]) by mx.google.com with ESMTPSA id cm5sm6171004wid.5.2014.02.13.07.38.52 for <dispatch@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 07:38:53 -0800 (PST)
Message-ID: <52FCE70C.1030608@gmail.com>
Date: Thu, 13 Feb 2014 16:38:52 +0100
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <CAHBDyN4tSRO_nYy7_-V4xfmDbF0ZeLJ24_fEOQ1p9Z2BvJyinQ@mail.gmail.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com>
In-Reply-To: <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 15:39:02 -0000

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