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

Hi Murray,

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

On Sun, Nov 6, 2022 at 3:32 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

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

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;
https://github.com/httpwg/http-extensions/pull/2173. 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
https://github.com/httpwg/http-extensions/pull/2298/files 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.


> 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
https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml, 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.

Cheers,
Lucas


[1] https://www.rfc-editor.org/rfc/rfc3230.html#section-6