[bfcpbis] comments on draft-pascual-bfcpbis-bfcp-websocket-00

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 13 March 2014 19:50 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C32961A09D8 for <bfcpbis@ietfa.amsl.com>; Thu, 13 Mar 2014 12:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8tQhR_1imgRe for <bfcpbis@ietfa.amsl.com>; Thu, 13 Mar 2014 12:50:27 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3276C1A0990 for <bfcpbis@ietf.org>; Thu, 13 Mar 2014 12:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1071; q=dns/txt; s=iport; t=1394740221; x=1395949821; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=CabpoSsdkFvKrmK8/RR1aMX0TrAGs0fA6QQinM5cWW4=; b=SPcO1QiFShdNKaDRF8BnjH3P3kqDOhsjI3NF0LWQD5V1CDe3GaBQ/N/v Hmp+HLZ8tl+bVBkQJSfJcUHdU/QN7yvzfLbw1arcV9qOGeWs47Pld7dXq skS1w1VBvFhxN60jiDy2v+ZLZjpbJGezYmI+4pABFIbwlycc/CzKnAh6s U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAEkLIlOtJXG9/2dsb2JhbABPCoMGgRLDARZ0giyBCwGBACcEiAyjB7EbF44BhRsEmEWSLYMtgis
X-IronPort-AV: E=Sophos;i="4.97,648,1389744000"; d="scan'208";a="310124892"
Received: from rcdn-core2-2.cisco.com ([]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2014 19:50:20 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com []) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2DJoK65003438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <bfcpbis@ietf.org>; Thu, 13 Mar 2014 19:50:20 GMT
Received: from xmb-aln-x08.cisco.com ([]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 14:50:20 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: comments on draft-pascual-bfcpbis-bfcp-websocket-00
Thread-Index: AQHPPvV2A075maMM9Ui7mdUSH5LcEQ==
Date: Thu, 13 Mar 2014 19:50:19 +0000
Message-ID: <CF475A0A.22BC9%eckelcu@cisco.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <682C589082DA5D4CAC31DE670E140532@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/nQjN2tXKzVnpqhCBuY4fzSlRe7Q
Subject: [bfcpbis] comments on draft-pascual-bfcpbis-bfcp-websocket-00
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 13 Mar 2014 19:50:29 -0000

[as an individual]

I read the draft and have a few comments/questions I wanted to share.

Section 1, Intro
As mentioned during the BFCPBIS session last week, it would be helpful to
clarify form the start that this draft is concerned with transporting
BFCP/TCP only, not BFCP/UDP.
Also, where it reads, "a new reliable and message boundary transport for
BFCP², I think you meant to write ³Š boundary preserving transport Š².

Section 2.1 Definitions
Definitions are provided for BFCP WebSocket Client/Server. BFCP itself
defines a BFCP client and BFCP server. My assumption is that these are
independent, meaning a BFCP WebSocket Client could be a BFCP client and/or
a BFCP server. It would be helpful to clarify this in the draft.

Section 4.1
The sample GET and 101 response contain the following to identify the
WebSocket payload:

     Sec-WebSocket-Protocol: bfcp

With rfc4582bis we added the definition of a BFCP version. Have you
considered if you need to do anything to address this within WebSockets?