Review of draft-ietf-httpbis-bcp56bis-09

Cullen Jennings <fluffy@iii.ca> Wed, 20 November 2019 09:42 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F071208A6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Nov 2019 01:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level:
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4QSHtPoH344k for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Nov 2019 01:42:40 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC7C1208A0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 Nov 2019 01:42:40 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iXMSp-0002qd-HS for ietf-http-wg-dist@listhub.w3.org; Wed, 20 Nov 2019 09:39:55 +0000
Resent-Date: Wed, 20 Nov 2019 09:39:55 +0000
Resent-Message-Id: <E1iXMSp-0002qd-HS@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <fluffy@iii.ca>) id 1iXMSn-0002pr-FZ for ietf-http-wg@listhub.w3.org; Wed, 20 Nov 2019 09:39:53 +0000
Received: from smtp64.iad3b.emailsrvr.com ([146.20.161.64]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fluffy@iii.ca>) id 1iXMSm-0001Mk-3t for ietf-http-wg@w3.org; Wed, 20 Nov 2019 09:39:53 +0000
X-Auth-ID: fluffy@iii.ca
Received: by smtp9.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 74AE22016D; Wed, 20 Nov 2019 04:39:47 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from dhcp-890a.meeting.ietf.org (dhcp-890a.meeting.ietf.org [31.133.137.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 20 Nov 2019 04:39:48 -0500
From: Cullen Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 20 Nov 2019 17:39:43 +0800
Message-Id: <371380E9-7204-41EC-8F32-653E9B5272D8@iii.ca>
To: ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-bcp56bis.all@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=146.20.161.64; envelope-from=fluffy@iii.ca; helo=smtp64.iad3b.emailsrvr.com
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iXMSm-0001Mk-3t 48e35a847964181f1eda69e9d38dc154
X-Original-To: ietf-http-wg@w3.org
Subject: Review of draft-ietf-httpbis-bcp56bis-09
Archived-At: <https://www.w3.org/mid/371380E9-7204-41EC-8F32-653E9B5272D8@iii.ca>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37155
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I do not think the document is ready to publish. 


Let me take the example of an spec defining an API to get an random number 

Lets say I have registered the ./well-known/fluffy space and I want to define a protocol for IOT devices to get a random number that changes each day by doing a GET of https://example.com/.well-known/fluffy/v1/rand (and the spec for this has all the appropriate info about catch control etc ) 

It seems like the last paragraph of 4.4.1 says this is allowed. I think this example is illustrative of the main things people have been complain with about the BCP 56 (the current version, not the bis draft here ) 

Let us start by if we agree the above is allowed or not. If I am wrong that this is not allowed, then ignore the rest of this email and we can talk about why it is not allowed. 


Section 4.4.1 of the drafts say 

   Applications MUST NOT define a fixed prefix for its URL paths; for
   reasons explained in [RFC7320], this is bad practice.

This seems wrong and needs to call out the exception for the .well-known space 



Section 3.2 seems to forbid the .well-known space at all so I think this section needs to specifically mention and carve out the .well-known space. 



Section 4.4, last paragraph - This seems not true for example above so this seems wrong 


Section 4.4.1 says 

   The most straightforward mechanism for URL discovery is to configure
   the client with (or otherwise convey to it) a full URL.  This might
   be done in a configuration document, in DNS or mDNS, or through
   another discovery mechanism.

What's the advice on how to do the full URL in DNS ?