Robert Wilton's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Wed, 20 May 2020 14:19 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 0C30E3A09F1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 07:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q_ZIa-zjapEm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 07:19:32 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 806383A0A21 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 May 2020 07:19:29 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jbPW7-0001MH-PQ for ietf-http-wg-dist@listhub.w3.org; Wed, 20 May 2020 14:16:20 +0000
Resent-Date: Wed, 20 May 2020 14:16:19 +0000
Resent-Message-Id: <E1jbPW7-0001MH-PQ@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1jbPW6-0001LM-Ik for ietf-http-wg@listhub.w3.org; Wed, 20 May 2020 14:16:18 +0000
Received: from mail.ietf.org ([4.31.198.44]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1jbPW4-0000hk-P2 for ietf-http-wg@w3.org; Wed, 20 May 2020 14:16:18 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C41F3A0A13; Wed, 20 May 2020 07:16:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-httpbis-header-structure@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, Tommy Pauly <tpauly@apple.com>, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.130.1
Auto-Submitted: auto-generated
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <158998416528.29748.5730867215913093544@ietfa.amsl.com>
Date: Wed, 20 May 2020 07:16:05 -0700
Received-SPF: pass client-ip=4.31.198.44; envelope-from=noreply@ietf.org; helo=mail.ietf.org
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jbPW4-0000hk-P2 d1f688b0b3d198865d9ce02e1b1c041f
X-Original-To: ietf-http-wg@w3.org
Subject: Robert Wilton's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)
Archived-At: <https://www.w3.org/mid/158998416528.29748.5730867215913093544@ietfa.amsl.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37678
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>
Robert Wilton has entered the following ballot position for draft-ietf-httpbis-header-structure-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thank you for writing this document. As per the other comments, more effort to have a tighter specification of HTTP header fields is likely to be beneficial, particularly if there are readily usable open source libraries that implement these. However, my main comment (which possibly could have been a discuss) questions how this is specified. In my experience other specifications of encodings define exactly what the format the encoding must take, but leave it up to implementation to decide how to perform that encoding. Whereas this document specifies the format in 3 ways: (i) as a prose description of the format, (ii) as an ABNF description of the format, (iii) as a pair of algorithms that construct or parse the format. I would prefer for the ANBF to be definitive along with prose to describe/refine the ANBF as required. For the algorithms, I would have preferred that they are held in the appendix as non-normative text that provides a description of one possible method of writing the serialization or parsing code. The corner cases that the algorithm cover could be in the normative prose/ABNF description. I appreciate that this would be a significant change to the document and hence will leave it to authors/responsible AD to decide whether to process or ignore this comment. A few other comments on particular sections that I noted: 1.2. Notational Conventions When parsing from HTTP fields, implementations MUST follow the algorithms, but MAY vary in implementation so as the behaviors are indistinguishable from specified behavior. I find that sentence slightly strange in that the first part of the sentence states that your MUST follow the algorithm, and the second part states that you don't have to follow the algorithm. It might be more clear if this was worded differently. E.g. MUST have behavior that is indistinguishable from that produced by the algorithm. 3.1 Lists: An empty List is denoted by not serializing the field at all. This was slightly unclear to me. Does this mean that it isn't possible to distinguish between not providing the header and providing an empty list? Possibly it might be worth clarifying this here, although I note that it does become clear what the expected behavior is later in the document. 3.2. Dictionaries Dictionaries are ordered maps of name-value pairs, where the names are short, textual strings "short, textual" => short textual" It might also be helpful to explicitly state what the ordering is (i.e. I presume that it is the order that they are listed in the request) 3.3.1 Integers Are "00" "01" "-0", "-01" all allowed? 3.3.6. Booleans Should this cover the fact that if the boolean value is not present it is interpreted as true in a parameter or dictionary? E.g. as per the description in the parameter and dictionaries sections? Regards, Rob
- Re: Robert Wilton's No Objection on draft-ietf-ht… Julian Reschke
- Re: Robert Wilton's No Objection on draft-ietf-ht… Mark Nottingham
- Robert Wilton's No Objection on draft-ietf-httpbi… Robert Wilton via Datatracker
- Re: Robert Wilton's No Objection on draft-ietf-ht… Mark Nottingham