On Thu, Apr 26, 2018 at 6:46 AM, Susan Hares <shares@xxxxxxxx> 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
