Re: Digests: deprecating parameters?

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.


> But the discussion moved on to
> examples and real-world usage; as far as we can tell there are no
> canonical examples either in the specification or on the wild Internet.
> 
> Keeping this spec gap seems wrong, so one option we could consider is to
> simply deprecate "parameters". For use cases that might have a future
> need of such a thing, they could easily define a new algorithm that
> encodes their parameters in the digest-value (the encoded checksum) itself.
> 
> Please let us know what you think.

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.


Amos

Received on Tuesday, 18 August 2020 12:42:56 UTC