John Scudder's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Tue, 23 May 2023 17:06 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 5DD09C151B05 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 May 2023 10:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.648
X-Spam-Level:
X-Spam-Status: No, score=-7.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkmlMQ7aEPbH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 May 2023 10:06:09 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A799C151B09 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 May 2023 10:06:09 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1q1VSQ-00H6gZ-IM for ietf-http-wg-dist@listhub.w3.org; Tue, 23 May 2023 17:05:58 +0000
Resent-Date: Tue, 23 May 2023 17:05:58 +0000
Resent-Message-Id: <E1q1VSQ-00H6gZ-IM@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <noreply@ietf.org>) id 1q1VSP-00H6fh-BV for ietf-http-wg@listhub.w3.org; Tue, 23 May 2023 17:05:57 +0000
Received: from mail.ietf.org ([50.223.129.194]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <noreply@ietf.org>) id 1q1VSP-001If1-27 for ietf-http-wg@w3.org; Tue, 23 May 2023 17:05:57 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6708AC151B01; Tue, 23 May 2023 10:05:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-httpbis-digest-headers@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net
X-Test-IDTracker: no
X-IETF-IDTracker: 10.4.0
Auto-Submitted: auto-generated
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <168486155040.18102.4708896280233963777@ietfa.amsl.com>
Date: Tue, 23 May 2023 10:05:50 -0700
Received-SPF: pass client-ip=50.223.129.194; 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1q1VSP-001If1-27 3df8a34c1fd862139557149c5423cdc6
X-Original-To: ietf-http-wg@w3.org
Subject: John Scudder's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)
Archived-At: <https://www.w3.org/mid/168486155040.18102.4708896280233963777@ietfa.amsl.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51063
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>

John Scudder has entered the following ballot position for
draft-ietf-httpbis-digest-headers-12: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting NOOBJ largely on the basis that the document appears to be of
high quality and would probably be clear and usable if only I had the necessary
grounding in HTTP's more abstruse corners to make sense of it. (Thank you for
the references and examples, those got me halfway there, perhaps. The other
half is the part I'm taking on faith.)

I do have a few nits and questions --

## COMMENT

### Section 5, reserved token value

In your description of the Status template field, you have ""reserved" - for
algorithms that use a reserved token value that cannot be expressed in
Structured Fields". This is a well-formed sentence but I have no idea what it
means. I made a desultory attempt to suss it out by searching the document for
"token" and this was the only occurrence. If people who will actually be making
use of the registry can be expected to make sense of it, then feel free to
disregard my comment, of course.

### Section 5, "optionally the key"

A few lines further down you have "Reference(s): pointer(s) to the primary
document(s) defining the technical details of the algorithm, and optionally the
key". I couldn't work out what "the key" is in this context, that would be
placed in the registry. The values you've seeded the registry with don't
provide any examples, so I'm none the wiser for having checked there.

## NITS

### Section 6.5, e.g.

In "Since it is possible for there to be variation within content coding, the
checksum conveyed by the integrity field cannot be used to provide a proof of
integrity "at rest" unless the whole (e.g., encoded) content is persisted.", do
you actually mean "i.e." and not "e.g."?

### Appendix A, typo

/entires/1234 should be /entries/1234