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

From: Susan Hares <[email-masked]>
Date: Thu, 26 Apr 2018 06:46:25 -0700

Reviewer: Susan Hares
Review result: Has Issues

Status: ready with issues
Overal-comment: This specification has carefully defined all the Careful
specification the bits and bytes of the compression /decompression.  However,
it unclear how common error codes are shared between implementations.

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.

Authors: What you need to do to clear my issue question:
Please talk to your AD and experts to determine the need for the error codes or
the specific codes.  I'm only qualified to suggest this area of inquiry might
be fruitful.   After you consider this concept with your AD, you can send a
message to the OPS-DIR list to indicate the resolution of my question.

reviewer caveat: I am not a expert on compression in media types.  If the
OPS-NM area ADs, feel this should be reviewed again with
compression/decompression expert for media data to determine what error codes
are needed, they should probably select someone who has worked with these
libraries.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 26 Apr 2018 10:19:51 -0400

It appears I entered typos via the web interface:

Overall-comment: This specification has carefully defined all the bits and
bytes of the compression /decompression.  However, it unclear how common
error codes are shared between implementations.

Sue Hares

-----Original Message-----
From: OPS-DIR [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, April 26, 2018 9:46 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [OPS-DIR] Opsdir last call review of
draft-kucherawy-dispatch-zstd-01

Reviewer: Susan Hares

Status: ready with issues
Overal-comment: This specification has carefully defined all the Careful
specification the bits and bytes of the compression /decompression.
However, it unclear how common error codes are shared between
implementations.

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.

Authors: What you need to do to clear my issue question:
Please talk to your AD and experts to determine the need for the error codes
or the specific codes.  I'm only qualified to suggest this area of inquiry
might
be fruitful.   After you consider this concept with your AD, you can send a
message to the OPS-DIR list to indicate the resolution of my question.

reviewer caveat: I am not a expert on compression in media types.  If the
OPS-NM area ADs, feel this should be reviewed again with
compression/decompression expert for media data to determine what error
codes are needed, they should probably select someone who has worked with
these libraries.

_______________________________________________
OPS-DIR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-dir

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Apr 2018 09:03:45 -0700

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

> suites

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