Re: Digests: deprecating parameters?

[Roberto Polli <[e-mail]>]

Hi @all,

today me and Lucas had a brief meeting on the parameters subject,
and considering those feedback we decided the following:

- given this comment from @Mark Nottingham
https://github.com/httpwg/http-extensions/issues/1211#issuecomment-675208548
  and as this specification is a refresh of RFC3230, we cannot *still*
switch to S-F. We would really like to switch in the future,
  and we both agree with @Poul-Henning Kamp considerations;
- given that digest-algorithms are case insensitive, we'll make a PR
saying that they SHOULD
  be used in *lowercase*, to ease a future transition to S-F;
- in absence of implementation, we'll follow @Julian Reschke  propose
to DEPRECATE http-parameters usage and
  wait for implementor feedback. We think that @Amos Jeffries
considerations are reasonable, but decided to make
  an attempt to simplify the spec.

Related PRs will land on the repo: feel free to provide more feedback
or suggest implementers to engage with the WG.

Clearly further feedback is always welcome!

Have a nice day,
R:

Il giorno mar 18 ago 2020 alle ore 18:39 Roberto Polli
<[e-mail]> ha scritto:
>
> Il giorno mar 18 ago 2020 alle ore 18:20 Poul-Henning Kamp
> <[e-mail]> ha scritto:
> >
> > --------
> > Roberto Polli writes:
> >
> > > While I like sf-binary, actual digest-algorithms define their own serialization
> > > method (in this case it's accidentally the same of structured headers) but other
> > > algorithms use eg. integer.
> > >
> > > To support SF we could say that digest-algorithms like sha-256 and
> > > sha-512 should be supported
> > > in both sf-binary and the traditional token format.
> >
> > The most sensible way (IMO) is to define that *all* digests are *always* sf-binary.
>
> I certainly agree on all your statements, but we cannot break current
> implementations
> of sha-256 and sha-512 for fixing the parameters issue.
>
> So:
> -  ok to prepare Digest to be SF-ready
> - ok if there's a way do describe the current Digest syntax with SF,
> so that we can later obsolete non sf-binary algoritms
> - not sure that fixing the parameters issue is a valid reason to
> introduce SF now
>
> My 2c,
> R.