- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 18 Aug 2020 16:20:14 +0000
- To: Roberto Polli <robipolli@gmail.com>
- cc: Amos Jeffries <squid3@treenet.co.nz>, Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
-------- 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. That makes for simpler parsing and simpler APIs to plug new digest algorithms into. The alternative is that the digest algorithms are allowed a choice from (a subset of) sf-item (= sh-integer / sh-decimal / sh-string / sh-token / sh-binary / sh-boolean). I have a hard time seing any non-speculative advantages in that ? I dont know of any contemporary digest algorithms, and have a very hard time even imagining future digest algorithms, which do not output a finite sequence of binary 8-bit bytes, ready to stuff into a sf-binary. If some past/future/speculative digest algorithm wants a particular serialization, only sf-binary is 100% certain to be able to carry it anyway, it might for instance contain newlines. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 18 August 2020 16:20:30 UTC