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

Peter Dunkley <peter.dunkley@crocodilertc.net> Thu, 13 February 2014 16:26 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 D70381A0301 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 08:26:06 -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 nQoVXx120h0t for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 08:26:04 -0800 (PST)
Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id F396F1A01EF for <dispatch@ietf.org>; Thu, 13 Feb 2014 08:26:03 -0800 (PST)
Received: by mail-vb0-f52.google.com with SMTP id p14so8108436vbm.25 for <dispatch@ietf.org>; Thu, 13 Feb 2014 08:26:02 -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=HQDeAokWeHMEKH2IghqUMbIF2p1XpMQFWq+kyFXR/58=; b=evoJg7THYgJTKmzA5ln7WeLtNA8Bdb0Xw9iEeD3EzzKBwU/SLgZtLlqNNDjKbIQJM1 PCoiSDlSDZM6nodh28miRbsj5ltx2vHjRYG5XHmURi7wh9aOLnuYZe1dJlneDIE0Xzox +spHqXDFXPbJK2x5oEvLY2gSDCh8XumTOqxAA=
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=HQDeAokWeHMEKH2IghqUMbIF2p1XpMQFWq+kyFXR/58=; b=bDVGpiL2UrZkK/VltHAlZA3OeAEW/Q75+nVyf6NZIxnqkSJDccuNJUhagbsJ/ypycv QM4IeFwEdz07Hdx/4tSHNJmknk/p44kQC1HGSkR7q/Q0LVWDfnoh3JU3u/Ydt9jw32Ks X9jnrPOW3CqCi6JOGdAAo03ZrH02NpwA7gd8w3KDH7hHPSYDafZY3UEQh0JCMAPn/Lkz yJ9d4PERbNRsVJyskWO7ozI8/QKbIOif1/j4Yr1/qkkGcHvSSXf7h71Z1jXaeym+xB4K a7G7dSn8uIsPTPgOXdZt0zuwLUCipVbL3TvceWJlOzgIDJSJvqxAfRq3cHotKq9i1wQQ vMog==
X-Gm-Message-State: ALoCoQl0A+lgLp4cUqmYVjpjgkLbALIkztSma9SpnTOV/taZ7OFZAJ8DJjHNvgTs9vxD+jTWGCCD
MIME-Version: 1.0
X-Received: by 10.52.121.113 with SMTP id lj17mr1238742vdb.21.1392308762398; Thu, 13 Feb 2014 08:26:02 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 08:26:02 -0800 (PST)
In-Reply-To: <CA+ag07bPBHzODTWGKFrKE00nO_wiMgRv2GEwUpGCiH25-Xf2Cw@mail.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>
Date: Thu, 13 Feb 2014 16:26:02 +0000
Message-ID: <CAEqTk6Reb=29kxeOUyPxAnhkRGqORHRoUchz5=hE4UNMggDnag@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122f1ca33673004f24c256f
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 16:26:07 -0000

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