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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Nov 8, 2022 at 10:39 AM Lucas Pardue <[e-mail]>
wrote:

>
> 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
> https://github.com/httpwg/http-extensions/pull/2298/files for a different
> fix
>

LGTM.


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


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

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.

-MSK