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

Roberto Polli <> Wed, 09 November 2022 10:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24751C1522BC for <>; Wed, 9 Nov 2022 02:07:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Status: No, score=-2.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, MAILING_LIST_MULTI=-1, 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 Vats8yoc1UBy for <>; Wed, 9 Nov 2022 02:07:35 -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 43312C1522B7 for <>; Wed, 9 Nov 2022 02:07:35 -0800 (PST)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1oshwv-00C4xg-Sq for; Wed, 09 Nov 2022 10:04:49 +0000
Resent-Date: Wed, 09 Nov 2022 10:04:49 +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 1oshwt-00C4wW-TF for; Wed, 09 Nov 2022 10:04:47 +0000
Received: from ([2607:f8b0:4864:20::536]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1oshwr-008gqG-Tb for; Wed, 09 Nov 2022 10:04:47 +0000
Received: by with SMTP id 130so3417021pgc.5 for <>; Wed, 09 Nov 2022 02:04:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VN0IjwVB1cr2YskOIQ0QxeAwx+JmSEiV0kcWktifYvE=; b=kwJtelQaocx932/YI4WUc5uf0jia0Y4QYtCAWyVA72RnfFdso5KHMb0DcCAK+FZKCU bFzvMRwy/SFOYLwzIjkV5QIbDs5qI/DK3aQZAuLcDloYJEo5hwg+cyRswc68K+mYsjKa 5lqJS1EbOPnUcUzF+5T0WP4HnCXfBXR8EamFqzbKh9WRMppE2bL7N/wOuGcg/4R07haV PdiSrdlz3b1721E26K7jF6hrEt8Do94Afkhq8yuKGLQlwd8FDyLZKSsnusFVZzNRwq4Q 8uDNPXR+WpGYmqeTv6va88yOmN/U63pTco4RNFHeM0vXMXEzJrIyFFiWs++4O/tS+wug 1pVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding: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=VN0IjwVB1cr2YskOIQ0QxeAwx+JmSEiV0kcWktifYvE=; b=R5JrJEaJwLlzOJIy3JyTJoUwa1vFkUy7JVltLgyyXys3WKn0dXRrNvs8nAQzkfG3Ci StPdbfAZn+q44VCuT7oo//CLz5sollQbcdTe/lMvkG7pdIY+Y8e/1+UB9b7pvNoijeZM oczBBaAAJUnTIhxeZ61EvyttdUSRZjgFLDUP4FkpEOE+qDT8kQZTP/2usMseI4IISpU0 EwR8zctlAn5nViQfF7TO5BvwY7L0pRkct58z1Q7RlhpQEnxgz3+9RG0J8BWVwV/rQEjk iZTU1cIjnfH9ORKbg+vhQb8ON8BaRIR5fx6oIygXZ09e3uftocDjv8nBU+W8qLKkkWv8 qgIw==
X-Gm-Message-State: ACrzQf38AYCqylren/VlOPOowz9d5gOm9C/CD6e5qUVxayaPjF3FUzNu HVy1UZcve4YAa2OLLfBaVXNrqbsgn1bEaBJlwQs=
X-Google-Smtp-Source: AMsMyM4vCHhNw4gL6EfF5xS7LerNCBQze2JlQfbxBEv++6qM5hWF0RKJUNOSCrBBJ5yLZjfJ5JcrgngkQ1N9tNQfujk=
X-Received: by 2002:a65:5b47:0:b0:46b:1a7d:7106 with SMTP id y7-20020a655b47000000b0046b1a7d7106mr50832410pgr.513.1667988273943; Wed, 09 Nov 2022 02:04:33 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Roberto Polli <>
Date: Wed, 09 Nov 2022 11:04:22 +0100
Message-ID: <>
To: "Murray S. Kucherawy" <>
Cc: Lucas Pardue <>,,, "Manger, James" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2607:f8b0:4864:20::536;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-6.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1oshwr-008gqG-Tb 690d9f8da3a9426b25ba01c5ed0a2c25
Subject: Re: Publication has been requested for draft-ietf-httpbis-digest-headers-10
Archived-At: <>
X-Mailing-List: <> archive/latest/40551
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Murray,

thanks for the review! +Manger, James who is the current DE for dig-alg

On Tue, 8 Nov 2022 at 11:53, Murray S. Kucherawy <> wrote:
> On Tue, Nov 8, 2022 at 10:39 AM Lucas Pardue <> wrote:
>>> Section 2 [and 3]:
>>> * I suggest including a forward reference to the appendices, where examples of replies including multiple hashes can be found.
>> [..] In each of these sections, [..we..] immediately give an example of a field containing sha-256 and sha-512.
> 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 case.

I did not create a gh-issue for this, then. If you think this should
be addressed, please let us know!

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

In "document-structure" we say that we are bootstrapping a new
registry. I'm ok to express that in the "abstract" if this can help.

>>> For that matter, why not merge this section down into what's in 7.2?

iirc we did something similar to
in order to avoid normative statements in IANA. To avoid inserting
normative statements
in IANA considerations, I think we could move the table only in 7.2
leaving 5. in the current place.
Does it make sense to you?

>>> * 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?
> 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 think it's ok not to mention FCFS since it causes confusion. For the
specific policy
I'd hear from Mark/Francesca and the other folks.

>> 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.
>> now would be a good time to discuss between authors, chairs, ADs and the current designated expert of the old registry
>> What we were trying to do was create something that followed a similar process to how the current registry has been operated

Please, can you take a look at wrt how to
the old registry (which is currently used by Digest implementers)?

>> I'm not comfortable mandating DE criteria without involving the current DE in the discussion.

@Manger, James have your say :)

Thank you all,