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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Thu, 13 February 2014 20:40 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 AA3AB1A0432 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 12:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, 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 FxTseu0ux2lr for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 12:40:45 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 72DBB1A00CD for <dispatch@ietf.org>; Thu, 13 Feb 2014 12:40:45 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id q59so8115333wes.9 for <dispatch@ietf.org>; Thu, 13 Feb 2014 12:40:43 -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:cc:subject :references:in-reply-to:content-type; bh=Wuv07pe0UFDAmwlCqBs2QFAnCjwFnOB8HBFaoskJl7s=; b=SNoSN0ye/AJ3ymvFF2HRMjRo0WDGragX4RNxc+likIxdhiOXOzpCxZ4JcBrkupUoO7 RWCWPzVYfaaHLHVwV4UNdgIHmX9zP1KdDvIZQiD/gHlTkGAjrKucddrn8Muh4nZjz3Jq 1rOgkOZv1x1HgYGp6WaAwTsHRKprmySbbl2GzGy4bmv6+px4CHsPyF2NxriM0rXg5+cN cmAP5ppbF+mmEKWYQcsiGRoSaGsGEiyRTlURQBH/srgxupBrooNHWMuVpQaXuOrpShrM 8ptRKNs/oAfMwdglHxZhK9J3mXIIi7F7ItL2Ueoqzi0BQLI079ylOG0pLs6V3W09KsKH ErPQ==
X-Received: by 10.194.109.134 with SMTP id hs6mr2945773wjb.65.1392324043765; Thu, 13 Feb 2014 12:40:43 -0800 (PST)
Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id f1sm16775643wik.1.2014.02.13.12.40.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 12:40:42 -0800 (PST)
Message-ID: <52FD2DC9.6090105@gmail.com>
Date: Thu, 13 Feb 2014 21:40:41 +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: Mary Barnes <mary.ietf.barnes@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>
In-Reply-To: <CAHBDyN7hySvbiJYnvRXDQ2ZS_FYFDMaODXBDRarE6DhRwC=fHQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080507080503070903060405"
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/JNmcCHpb7Is76_SHH-3WKGgNT5o
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 20:40:48 -0000

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 
> <mailto: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
>         <mailto: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 <mailto:dispatch@ietf.org>
>         https://www.ietf.org/mailman/listinfo/dispatch
>
>
>     _______________________________________________
>     dispatch mailing list
>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>