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

"Murray S. Kucherawy" <> Tue, 08 November 2022 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61A14C14F693 for <>; Tue, 8 Nov 2022 02:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.759
X-Spam-Status: No, score=-7.759 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_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 nOAbmkkXgsdD for <>; Tue, 8 Nov 2022 02:53:07 -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 3C17BC14F72D for <>; Tue, 8 Nov 2022 02:52:29 -0800 (PST)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1osMAd-008UJV-0f for; Tue, 08 Nov 2022 10:49:31 +0000
Resent-Date: Tue, 08 Nov 2022 10:49:31 +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 1osMAc-008UIY-4y for; Tue, 08 Nov 2022 10:49:30 +0000
Received: from ([2a00:1450:4864:20::62e]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1osMAa-0089Uy-CD for; Tue, 08 Nov 2022 10:49:29 +0000
Received: by with SMTP id ud5so37535192ejc.4 for <>; Tue, 08 Nov 2022 02:49:28 -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=d48aY0/06dPgkNvKZjaJZ7h82pXfVP8N+4lUn044i3w=; b=Nv1elGSIKeyv7otvpzE/me6VDJs5wlzq7X1tDrLUWf9J2E6Ob8ZSD2zQcWLfTHfSWX yaBEEu0wbgH0fntvNjMlBlyDE/oI79X9oej3u5YVVqaC2QFBcGru05utpA87tAXnnG3y zZZ9c8cpnZ7SJj+aUHzcyJhlypRumNeiL+9LmTXGPpu9rD+Mb+7RZycEEox7yl+xiGnS JGONa/v6zxKNdICPaYwPIMT1VX46QuTD5zfAjTbGybeJCcoBFOT20rmB092y/J/imdNb 0dsHJ6oPpN1FNzW0VhvwKozFNJK6IiQFBFixk60sZt4qT0oEN3rLiryaozN9K3S4fHaz HeXg==
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=d48aY0/06dPgkNvKZjaJZ7h82pXfVP8N+4lUn044i3w=; b=18Ma8c7tm7SL7NGBTNTxqqWxZrRMX61dA4Zy3nndQu/DFR0xVOXemCnjGbWBUw7EU4 Uzebs3OfHLB/jL+5VqDJQMQYHB/xnvzHoaoI0E+mnqZ8MAWdxKh4AqpQriZqouUVEfsk dsGQVtkfUQTToGT3RiKix2GKOxYOw8eenx+QAY0/9NZu3xSNCtyGqYee+e1xX1H0dhe2 Ux1a3whF+3VU4fM099jgiyTV2tgOdLeZeIYZAPWFjk8m2iP3xw7XfblrceZlG5gM/M4+ KzsnVE5s0SXZK+icMv0yu0xdCxIA8fMm8KbFNPVtTxPjD5ElMPYGkUql5ntH6EYVwuKW 0zrg==
X-Gm-Message-State: ACrzQf2tyZwCRkGwDxqy3mM8ZUT8/7dOkNWIEvZo0D6qJfJwXOQY62KJ 1bYV+mnrJ8eM1mNhiAzuoU0wmgslryV9IUpCgiY=
X-Google-Smtp-Source: AMsMyM57+W9xY7mCg/ih8ra2epi0Tx4byYgbeO1z4tJ7CzpM1fOgrHsYQiRNTUWM6Wb5thbtRyUvk5ZJXAc/eVzRs1w=
X-Received: by 2002:a17:907:6a09:b0:7ae:2793:aa23 with SMTP id rf9-20020a1709076a0900b007ae2793aa23mr23473793ejc.184.1667904557043; Tue, 08 Nov 2022 02:49:17 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Tue, 08 Nov 2022 10:49:05 +0000
Message-ID: <>
To: Lucas Pardue <>
Content-Type: multipart/alternative; boundary="000000000000a45d0d05ecf34af4"
Received-SPF: pass client-ip=2a00:1450:4864:20::62e;;
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: 1osMAa-0089Uy-CD 479e73678733d9490d13897aeb4ce575
Subject: Re: Publication has been requested for draft-ietf-httpbis-digest-headers-10
Archived-At: <>
X-Mailing-List: <> archive/latest/40536
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Nov 8, 2022 at 10:39 AM Lucas Pardue <>

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

Yep, that would close this for me as well.  Thanks.

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


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

I think my suggestion is just that as I read these two sections, I found
myself immediately wondering what multiple hashes would look like, and in
particular that it would be a good thing to demonstrate.  I found out later
that those examples do exist down in an appendix.  Not a major point in any

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

Yes, I think this is a good time for the WG to have that discussion.  I
also think that text in 3230 is confusing to me.  The first sentence is
pretty much exactly the definition of "Specification Required".  I don't
understand how it can simultaneously be that and "First Come First Served",
which is its own (far less rigorous) registration model.  I would refer you
to RFC 8126 which is the current guidance for writing IANA Considerations
sections.  Happy to provide any advice you need here.