Re: Opsdir last call review of draft-kucherawy-dispatch-zstd-01

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

On Thu, Apr 26, 2018 at 6:46 AM, Susan Hares <[e-mail]> wrote:

> Error code issues:  Compression/Decompression is normally a specific
> library
> function.  As a library function, it is often tested with reference test
> suites
> against a referece implementation.  What I do not undersatnd form this
> specification is how errors get passed to the calling program.
>
> A face book implementation of this zstd return errors codes:
> (https://facebook.github.io/zstd/zstd_manual.html)
> #define ZSTD_CONTENTSIZE_UNKNOWN (0ULL - 1)
> #define ZSTD_CONTENTSIZE_ERROR   (0ULL - 2)
>
> Should this type of operational information be included in the compression
> specification?  It seems like common error codes would help the
> interoperability of different implementations  so that compression by one
> implementation would correctly be decompressed by a second.
>

Hi Susan, thanks for the review.

The material you're asking for strikes me as the kind of thing that is
chosen within a particular implementation and test framework, not something
the protocol document needs to specify globally.  Interoperability can
instead be verified using, for example, a hash function, e.g., "the SHA256
of the payload you get out of decompression should be X", or to test
self-symmetry, "the SHA256 of the payload you get out of decompression
should be the same as that of what was fed to compression".  That the
Facebook implementation chose those codes isn't an indication that a
standard set of such codes is necessary for interoperability with other
implementations.

In another working group where I'm participating (DMARC) we had the same
kind of discussion about stipulating a specific ordering for parameters in
order to make test frameworks simpler and more universal, and consensus
there was also not to impose constraints like this where other more
flexible options are available.

-MSK