Re: [bfcpbis] WGLC on draft-ietf-bfcpbis-sdp-ws-uri-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 15 March 2016 20:34 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 75FD912D74E for <bfcpbis@ietfa.amsl.com>; Tue, 15 Mar 2016 13:34:55 -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 wxXjKjNkqGLc for <bfcpbis@ietfa.amsl.com>; Tue, 15 Mar 2016 13:34:53 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B640612D74B for <bfcpbis@ietf.org>; Tue, 15 Mar 2016 13:34:53 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-12v.sys.comcast.net with comcast id WLZa1s0022Qkjl901LasNN; Tue, 15 Mar 2016 20:34:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id WLas1s0093KdFy101LasM9; Tue, 15 Mar 2016 20:34:52 +0000
To: bfcpbis@ietf.org
References: <D30A9F22.68CF0%eckelcu@cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56E871EB.9040802@alum.mit.edu>
Date: Tue, 15 Mar 2016 16:34:51 -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: <D30A9F22.68CF0%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=1458074092; bh=VyLrwAo1e9fd7erqFvexbeH2IYKYI7/UMZdwev/hdLI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pHp8Loeoj+3iCCDesyYI0t7hIceVr/aByqBxX867twUdqkN3EYYgmQFy2feKXnmz/ cOxjXFt2nO7C4VwV61z6lhYXGCnIG7LPrzoblBRtEkJnrQtyz8GeP4rcsih3kLEqfC soKPUeGs4IqHfdvZ1imiRWoQzJNsxYEEz5I+Zu86jGHGq3NzeyGQDBThQo7iFBgMIQ Vq1FD9676UtjQ/c3E0gfZj7mG08LUpg4jiUVY0J4Hw225BOxuXGrw3dfpMPST6Z+W9 Hb3bos/scOJyOHlsJOper5v4GbxlyZbpyhtbeXmx7ZZgXPhnvovmflfD9dyKKKAdFA F3jwBirKE5W5Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/_y_FxCOw5pI_YeRQXGvMLpKGZY0>
Subject: Re: [bfcpbis] WGLC on draft-ietf-bfcpbis-sdp-ws-uri-01
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:34:55 -0000

Generally in good shape. A few comments:

* Section 3.2 says:

    This section defines a new SDP media-level attribute, 'ws-uri' which
    can appear in any of the media lines.

But this cannot appear in any media *line*. I think you mean it can 
appear in any media *section*.

This also applies to section 3.3.

* Section 4.1:

The text here says that the *answerer* "MUST add an "a=ws-uri" or 
"a=wss-uri" attribute". But Section 4.2 admits the possibility that the 
offerer might be the server. Clearly it is the *server* side that needs 
to include "a=ws-uri" or "a=wss-uri", regardless of whether that side is 
offerer or answerer.

I can see how this might be important, such as in cases where a UAC 
sends an offerless invite to the server and the server wants to use 
BFCP. And the "client" might not be *able* to act as a web server. The 
possibility of this case should also be discussed elsewhere in the document.

Also, this section has some problems in use of terminology: The 
construct "add an ... attribute in the "m=" line of each media-line ..." 
makes no sense. Perhaps what you mean is: "add an ... attribute in the 
media-section".

* Section 4.5:

It would be good to mention the use of "a=connection:existing" for 
websocket reuse.

	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-sdp-ws-uri-01
>
> 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
>