Re: Publication has been requested for draft-ietf-httpbis-digest-headers-10

"Murray S. Kucherawy" <> Sun, 06 November 2022 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C48F2C14F722 for <>; Sun, 6 Nov 2022 07:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.059
X-Spam-Status: No, score=-5.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zdigG0BmAdhz for <>; Sun, 6 Nov 2022 07:31:51 -0800 (PST)
Received: from ( []) (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 (Postfix) with ESMTPS id EE037C14CE22 for <>; Sun, 6 Nov 2022 07:31:50 -0800 (PST)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1orhPs-002neC-GY for; Sun, 06 Nov 2022 15:18:32 +0000
Resent-Date: Sun, 06 Nov 2022 15:18:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1orhPq-002ncu-MP for; Sun, 06 Nov 2022 15:18:30 +0000
Received: from ([2a00:1450:4864:20::535]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1orhPk-007I0h-KW for; Sun, 06 Nov 2022 15:18:30 +0000
Received: by with SMTP id s12so4435223edd.5 for <>; Sun, 06 Nov 2022 07:18:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xQPXSamzxQD/Xgt//ZLPCZhiNaMjxKWR8jgLNEpJ8xg=; b=IZG5O7RhOZEoGpvzIMv+Rf1TCaxoUepqhSUF7XDEI1EKSIKtWD0rUKnPuUiDJym3+p hjgkRqREza+4ujNiCXesdTwHTYYOhQIPPSq0l8mP5PGLt2BSVGqemzBA5r+8f0BNNeji 34v6dZs9Ya3y1pKjiiBk+NCnpMFzIhuA/Q2Vt22eiP/sIvy8AXGe4U/JK8sniwvZKqYt dS9picxZsTc31FMuwaWpgxr+BT20o01GdelBn3mVMc4I6aEEGO//618lkXMz9Jr6+g95 vC0tirJ+Cb8X+2q+Q3guzcVRERoGEoOYS4DblGQ1+vKGzo2LC2RaRHCPcWue9mlu8Pyj JIKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xQPXSamzxQD/Xgt//ZLPCZhiNaMjxKWR8jgLNEpJ8xg=; b=cRO21vcVuhUHIZ/UKRhM0NGx9IcEEQOB+DMraiTjMbc2Fq0ru06HQiA+9wPtVpt9ld KN5uVU8JH8tZ+KZJbMOYbvYfY67cEA7+0fJQsOv1UeR/ToE+cLpyxvOaZsZN0rNrPDCh jLrVs48w3RjpbEdjnqfqHOyUPeOxbH8+Bda6NSy2Db8LgH+cf03QurFf4vFqaJUj339d tiGOTNPtjKsxxenRe5CD1+J3p/Krhf6zf1A1Dwk+3mNtdkms1pDvClP5BaETagIvS6KB PpSnY337B6tDCLnpdq8MKrBmguVVp87zHtgiCw9ZrTe0+4hPc7Qtu7qLEYzTKtrgIpFG 3+CQ==
X-Gm-Message-State: ACrzQf2vmwb4HzB9Pzcji03dxhfPR9EdTF+R/LkaPUaeoRt/GQmMxM88 0DF3PKTQlD6aoME6kdRByP+lP0EyDZQd3Me7M5gD+19FhQpq0Q==
X-Google-Smtp-Source: AMsMyM7WdujWslCIk26enlLPJ9sKLvVJoFRBzP+8KLGGTq1Tl9AvcyAFo8mccTVYbnUhYeRT/lxLmw+s/1jBG6OMWgc=
X-Received: by 2002:aa7:c697:0:b0:462:a87b:52d with SMTP id n23-20020aa7c697000000b00462a87b052dmr45831478edq.361.1667747892758; Sun, 06 Nov 2022 07:18:12 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sun, 06 Nov 2022 15:18:01 +0000
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000b90ec305ecced0c3"
Received-SPF: pass client-ip=2a00:1450:4864:20::535;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1orhPk-007I0h-KW 60276ac27f6683d99639c5c4dee37acb
Subject: Re: Publication has been requested for draft-ietf-httpbis-digest-headers-10
Archived-At: <>
X-Mailing-List: <> archive/latest/40529
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, Jun 20, 2022 at 1:03 AM Mark Nottingham via Datatracker <> wrote:

> Mark Nottingham has requested publication of
> draft-ietf-httpbis-digest-headers-10 as Proposed Standard on behalf of the
> HTTPBIS working group.
> Please verify the document's state at

AD review here.  Apologies that it took me a while to get this finished.

Generally, nice job.  All I have are some comments that can just be
considered Last Call feedback, and I'll request Last Call shortly after
sending this.  Please note that the Last Call may be extended a bit given
the request is being sent during 115.




* I may be showing some ignorance of this space here, or I may have missed
something, but I'll ask anyway: Is there any advice to be given for a
situation where a client requests digest(s) but the server provides none,
especially when that client has reason to expect that this specific server
implements this specification?  i.e., "Hmm, I asked for the digest(s), and
they ought to be there but aren't, that's weird..."

Section 1.2:

* I believe "different headers" should be "different header fields".
(Might want to check generally for the use of "header" or "headers" to make
sure they're all correct or adjusted appropriately.)

Section 1.3:

* The sentence "The most common mistake being ..." seems like it should be
part of the previous sentence.  If you want it to be on its own, I suggest
changing "being" to "is".

Section 2:

* I suggest including a forward reference to the appendices, where examples
of replies including multiple hashes can be found.

Section 3:

* same suggestion as Section 2

Section 5 and Section 7.2:

* I encountered this section and followed the link to find that this
section is talking about a registry that doesn't actually exist.  That this
section is actually specifying a new registry was not clear until Section
7.2.  Can we clarify this somehow?  For that matter, why not merge this
section down into what's in 7.2?

* A "Specification Required" registry obligates the assignment of one or
more Designated Experts.  Section 4.6 of RFC 8126 says the defining
document should contain guidance to the DEs about what criteria are to be
applied when doing reviews.  None seem to be present here.  Is there
anything that needs to be said?