Re: [bfcpbis] WGLC on draft-ietf-bfcpbis-bfcp-websocket-06

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 15 March 2016 20:38 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0F12D55D for <bfcpbis@ietfa.amsl.com>; Tue, 15 Mar 2016 13:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 JmCC8eODzY66 for <bfcpbis@ietfa.amsl.com>; Tue, 15 Mar 2016 13:38:45 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A165212D529 for <bfcpbis@ietf.org>; Tue, 15 Mar 2016 13:38:43 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-02v.sys.comcast.net with comcast id WLe31s00329Cfhx01Leivs; Tue, 15 Mar 2016 20:38:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id WLei1s00N3KdFy101Lei52; Tue, 15 Mar 2016 20:38:42 +0000
To: bfcpbis@ietf.org
References: <D30A9F19.68CEF%eckelcu@cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56E872D1.3020204@alum.mit.edu>
Date: Tue, 15 Mar 2016 16:38:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <D30A9F19.68CEF%eckelcu@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458074322; bh=RXnugRFePkjC7GFAiHjxjj/vj9MaNG7wX2+c9b2wU6k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=F+bH0tWcgekbDjjQ5FKxFA+JRvaumkcUr4q0Sl4X8Mfae//ibJiqVz2RF3TPxAwm1 MUDYnPHndgYWbrkHFaY+tHLyv6jE9MHhZX5cw+G12csd26rteSOVsJyZJWzLR+pCGu TzUKPtR2dDpkIovQuMwbpYTG64WxRbIh1DLWSvwGYP4RHPp6Xb8/csMYUg+dYxVstA 4sK26xCVHiFww3Fk/V/56F/+V+f30pLszTgl0L9tfuMfuUup8hHliXMjtvHTSINtEz jLOjnf8x+Z7vVH8xpbxCJk4xVF+SbzG8HXn9eR6pzeUG3PaOtZDj8HAYeQldT1Vw3f nouXLk4scyjdg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/GrT8BEXiKZu_vv5n1YMqXmLk0pE>
Subject: Re: [bfcpbis] WGLC on draft-ietf-bfcpbis-bfcp-websocket-06
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 20:38:47 -0000

Generally in good shape. A couple of comments:

* Section 4.1:

I see you are using "bfcp" for the subprotocol name.
IMO it would be better to use "BFCP" for consistency with what is used 
in the m-line proto field.

(I've been querying for information about case-sensitivity of the 
sub-protocol field. I have not gotten a definitive answer, but the 
prudent path is to assume it is case-sensitive.)

* Section 7.1 says:

    An endpoint (i.e., both the offerer and the answerer) MUST create an
    SDP media description ("m=" line) for each BFCP-over-WebSocket media
    stream and MUST assign a TCP/WSS/BFCP value to the "proto" field of
    the "m=" line.  Furthermore, the SDP answerer (Server) MUST add an
    "a=ws-uri" or "a=wss-uri" attribute in the "m=" line of each BFCP-
    over-WebSocket media stream depending on whether it is WS or WSS.

This says to use TCP/WSS/BFCP even when using "a=ws-uri". I presume that 
is wrong.

Also, see my comment on draft-ietf-bfcpbis-sdp-ws-uri-01 
(http://mailarchive.ietf.org/arch/msg/bfcpbis/_y_FxCOw5pI_YeRQXGvMLpKGZY0) 
regarding the case where the offer is generated by the server. They 
apply here equally. The text needs some reworking to address that case.

	Thanks,
	Paul


On 3/13/16 12:55 PM, Charles Eckel (eckelcu) wrote:
> This is to announce a 2 week WGLC on the draft:
> https://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-06
>
> Please review and provide any comments by Monday, March 28, 2016.
> Comments should be sent to the authors and the BFCPBIS WG list.
> If you review the draft but do not have any comments, please send a note
> to that effect as well.
>
> Thanks,
> Charles
>
>
>
>
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
>