Re: Digests: deprecating parameters?

Hey Amos,

On Tue, Aug 18, 2020 at 1:42 PM Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 18/08/20 9:49 pm, Lucas Pardue wrote:
> > Hello folks,
> >
> > We're wondering what the group might think about deprecating the Digest
> > parameters. Please respond for or against the idea, either here or on
> > the GitHub issue https://github.com/httpwg/http-extensions/issues/850
> >
> > _Background_
> > While updating the Digests spec we've found somewhat of a gap when it
> > comes to "parameters". These are mentioned in RFC 3230:
> >
> > |For some algorithms, one or more parameters may be supplied.
> > digest-algorithm = token The BNF for "parameter" is as is used in RFC
> > 2616 [4]. All digest- algorithm values are case-insensitive.|
> >
> > It seems wrong to define parameters as part of the algorithm, so we
> > started on a PR to fix things up.
>
> I do not see any indication in RFC 3230 that the parameters have to be
> defined with the algorithm. There could be a specification which defines
> a parameter which is relevant to all algorithms but is optional. Eg a
> "q=" or "charset=" parameters.
>
> Such a parameter may be *sent* on some algorithms entries, but not on
> others depending on the sender implementation.
>
> So IMO, that particular line of argument against parameters is not a
> valid one.
>

This is probably where the gap leads to interpretation, and maybe I
misinterpreted things.

I think the terminology is the annoying thing here, since digest is a tuple
of algorithm and computed value. The BNF in 3230 doesn't make it super
clear where a parameter would be expressed. For instance, is it reasonable
to assume that the intended digest parameter delimiter was ';'? I do agree
with your "global parameter" concept, which could apply to all digests
independent of the algorithm used.

I think this would be a good time to refer to the structured headers
> document as a syntax basis
> <https://tools.ietf.org/html/draft-ietf-httpbis-header-structure>.
>
> That documents the possible existence of parameters even when they are
> not specifically defined by the header document (eg RFC 3230). Which
> allows dropping the mention of them from RFC 3230 successor document
> without formally deprecating or requiring any implementation changes.
>

That sounds reasonable, especially given the previous point. Does that work
for others?

Cheers,
Lucas