OCF encryption.xml MUST vs. SHOULD conformance requirement for Compression element

[danielweck]

Related issue:
#646

draft prose:
http://rawgit.com/IDPF/epub-revision/master/build/31/spec/epub-ocf.html#sec-enc-compression

"Streams of data that are compressed before they are encrypted SHOULD provide additional EncryptionProperties metadata to specify the size of the initial resource (i.e., before compression and encryption), as per the Compression XML element defined below."

CC @murata0204

[danielweck]

CC @thkim2015 @drminside

[danielweck]

I think SHOULD is strong enough, especially as there are real implementability problems only with streaming codec media such as audio/video. MUST would cause "backwards compatibility" issues because pretty much all conformant EPUB <3.1 content where resources are compressed prior to being encrypted would become "strongly" invalid (arguably, SHOULD is slightly less stringent). Sure, EPUB-Check does not process DRM'ed publications, so in the real world this is not so much a visible problem. PS: note that IDPF-endorsed font obfuscation is explicitly not considered "encryption" by the EPUB specification, even though encryption.xml is used.
So, I am satisfied with SHOULD. Any thoughts @murata0204 @thkim2015 @drminside ?

[thkim2015]

I think there are 2 issues about this matter.
One is mandatory use of the EncryptionProperties and the other is compression issue of the audio and video resources.

We know that, without additional EncryptionProperties metadata, there is no way that implementer knows the size of initial resource if it is COMPRESSED before encrypted.
So IMO, to use the EncryptionProperties should be a mandatory, not recommendation.
Therefore, the context of this issue is required to be:

Streams of data that are compressed before they are encrypted MUST provide additional EncryptionProperties metadata to specify the size of the initial resource

And the other matter we have to discuss is related to compression itself.
Since EPUB 3.01 specifies:

When stored in a ZIP container, streams of data MUST be compressed before they are encrypted and Deflate compression must be used.

we should consider the backward compatibility as @danielweck said.

So I think we need to add some exceptional sentence for the compression case like following:

When stored in a ZIP container, streams of data MUST be compressed before they are encrypted and Deflate compression must be used. However if the mime type of the resource is either audio or video, streams of data SHOULD not be compressed before they are encrypted.

[danielweck]

thank you @thkim2015
could you please review the existing draft prose?
http://rawgit.com/IDPF/epub-revision/master/build/31/spec/epub-ocf.html#sec-enc-compression

[thkim2015]

I am sorry but when I wrote my previous opinion, the upper site was not available and showed me not found(404) error.

It is a matter of correction or upgrade of the specification.

Actually, even though some EPUB 3.01 contents could not be compliant to EPUB 3.1 due to the mandatory EncryptionProperties metadata rule, IMO it should be corrected for the safe implementation so that MUST is recommended.

However, if you think the backwards compatibility issue is more important than the safe implementation, then it could be an upgrade issue and SHOULD is required.

But in SHOULD case, I think we need to make a notice for the implementer of the EPUB 3.1 to handle without EncryptionProperties metadata case, which is they always have to allocate reasonably enough memory(e.g. 10 times bigger than compressed size) to get unknown original resource from compressed one, even though it does not guarantee the safe.

MUST or COULD issue is now up to you.

I'll follow your final opinion.

[mattgarrish]

Proposed solution:

Make no change. Leave as a "should" requirement.