- From: Murray S. Kucherawy <superuser@gmail.com>
- Date: Sun, 6 Nov 2022 15:18:01 +0000
- To: ietf-http-wg@w3.org
- Cc: francesca.palombini@ericsson.com
- Message-ID: <CAL0qLwbs6nMrVX4QXprkP9Nv5DbRLN--_-ZfDDPf8CApO-YqvA@mail.gmail.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. -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..." 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