W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

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

From: Murray S. Kucherawy <superuser@gmail.com>
Date: Sun, 6 Nov 2022 15:18:01 +0000
Message-ID: <CAL0qLwbs6nMrVX4QXprkP9Nv5DbRLN--_-ZfDDPf8CApO-YqvA@mail.gmail.com>
To: ietf-http-wg@w3.org
Cc: francesca.palombini@ericsson.com
On Mon, Jun 20, 2022 at 1:03 AM Mark Nottingham via Datatracker <
noreply@ietf.org> 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
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/

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?
Received on Sunday, 6 November 2022 15:18:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC