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

Lucas Pardue <> Tue, 08 November 2022 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A890C1522A0 for <>; Tue, 8 Nov 2022 02:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.758
X-Spam-Status: No, score=-7.758 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_HI=-5, 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_BLOCKED=0.001, 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 kytziZRFj4Ui for <>; Tue, 8 Nov 2022 02:43:22 -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 E1200C15E6F9 for <>; Tue, 8 Nov 2022 02:43:02 -0800 (PST)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1osM1D-008S8y-35 for; Tue, 08 Nov 2022 10:39:47 +0000
Resent-Date: Tue, 08 Nov 2022 10:39:47 +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 1osM1B-008S86-PL for; Tue, 08 Nov 2022 10:39:45 +0000
Received: from ([2607:f8b0:4864:20::334]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1osM19-0089KZ-SV for; Tue, 08 Nov 2022 10:39:45 +0000
Received: by with SMTP id a7-20020a056830008700b0066c82848060so7963232oto.4 for <>; Tue, 08 Nov 2022 02:39:43 -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=ddnSp/fUQVkirpCOyYSW44ObNBhFmm18GgKGXcFTmWE=; b=JLuJz6Uyj/+TZAhAF7HsTrpv5RABVK8coo9NI71RyhGXo3UE3WBKKexVdVCxDSBzkS ceSAFVKZacOqfMHRGxPXAtBGirJ9CPkDBLFpq756M+0XVh30N/vWSMOg2Xbm6ylQX3Ta MdJGAVFtL46mTdBqR5oTD2shnhZ0WxifWBtCRZD3uG2gkbJZySSW4ynTok01ZyuMe7TQ 9f2c2aXfNvzE9lb3dea52ZTNurZDAU307zTXxZamhlWOTdraybBz6WAhevd6xjBGnfCc 1Vt+PB4UhmyPx7Jy+2KydTDnXby281myTW79haxvNJ6dEUbBn0/MVpZ7DKZnEsUob+ts rGiw==
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=ddnSp/fUQVkirpCOyYSW44ObNBhFmm18GgKGXcFTmWE=; b=Gf1y9+lsDLWI5kYMFlT+nihMubEiEez4q37HeRtq21ssCvKoxwcYCcZqxC/CbztwKN AoOYNSlaCiR0HPE5pMDW/jzkIp4V3iek84FhO0HCcFCuUi2sZbVWLzTX/7mBENTm071b Wx8Y866otHaM8l0M6OlLMEbNTQwzOu24qtXl3vrz9zj/QZizj9s6Oca5ebJxMPFllVuZ DSNq/mM7+blq/VrMycScu0DncWzCZtlJUMAmHecKKYnvz0MVOzh/aMNxwqTmwB3S4F9K B8gHGk3m01tJ11K4UKL/rjgeZDBeeKVkrpPDBoEmN0O1dgo0IEcR54GkLkGmekaUCvbW 3WRg==
X-Gm-Message-State: ACrzQf1fqnsPLqsDauVv3rchaZnlZVeaLosu2RNQu7yGyLmewd3UUl2T XVfrD/GJZDPWRJPEBHE/bpuiyi2DPCVNuSVU5Qw=
X-Google-Smtp-Source: AMsMyM4gWAt1bFyKOqMA5zrSmuRWTvYHu2lRBRU214eikl/wuxPOjPON/svaz7t0d+InMLRMjVF+6GHQqTGVN5Ww2D4=
X-Received: by 2002:a9d:6119:0:b0:66c:92a4:450d with SMTP id i25-20020a9d6119000000b0066c92a4450dmr10586582otj.123.1667903972833; Tue, 08 Nov 2022 02:39:32 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 08 Nov 2022 10:39:21 +0000
Message-ID: <>
To: "Murray S. Kucherawy" <>
Content-Type: multipart/alternative; boundary="000000000000d1ffd105ecf32791"
Received-SPF: pass client-ip=2607:f8b0:4864:20::334;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Scan-Sig: 1osM19-0089KZ-SV bd85c70bea431fd42fa39fa072a4eef8
Subject: Re: Publication has been requested for draft-ietf-httpbis-digest-headers-10
Archived-At: <>
X-Mailing-List: <> archive/latest/40535
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Murray,

Thank you for the review! Initial responses in-line:

On Sun, Nov 6, 2022 at 3:32 PM Murray S. Kucherawy <>

> 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.
> -MSK
> --
> General:
> * 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..."

We fall into the general realm of HTTP feature negotiation here, which has
some well-trodden problems. If the client and server have some prior
knowledge or OOB channel that lets them build an exception for digest, they
can define their own rules for how to handle its absence - I don't want to
go too far down the path of trying to describe that. I think what is useful
is to highlight, with an editorial change, the very real possibility that
an endpoint sends "want-*-digest" and the peer ignores it and doesn't
provide any "*-digest" at all. Then all we should say is that dealing with
this situation is an implementation decision.

> 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.)

Fixed already in the editors copy by Julian; I trust his skills for
finding these problems with terminology, so I think we're all good.

> 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".

Agree this could be worded better, please see for a different

> 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

I'm a little confused by this ask. In each of these sections, we highlight
the field is a Structured Fields Dictionary and it can have multiple
values, then immediately give an example of a field containing sha-256 and
sha-512. That seems sufficient to me. There's a single example in the
appendix that provides multiple hashes but that's not the sole purpose of
the example, and it only speak to Repr-Digest. I thnk forward referencing
to that example would be confusing. Adding more examples in the appendix
would just seem duplicative of the existing example in each section.

> 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?

IANAIANAE (I am not an IANA expert) - during the spec development we kind
of punted the matter of the registries until this phase of the document
cycle. I think now would be a good time to discuss between authors, chairs,
ADs and the current designated expert of the old registry to figure out a
path forward that has the least friction. The current registry is, it states
the policy is "RFC Required or Specification Required". However, RFC 3230
Section 6 [1] says:

   Values and their meaning must be
   documented in an RFC or other peer-reviewed, permanent, and readily
   available reference, in sufficient detail so that interoperability
   between independent implementations is possible.  Subject to these
   constraints, name assignments are First Come, First Served

Is the current IANA policy in agreement with what RFC 3230 asked for?

What we were trying to do was create something that followed a similar
process to how the current registry has been operated. I'm not comfortable
mandating DE criteria without involving the current DE in the discussion.