Epub-specs: Restrictions on mimetype: extra fields

[dauwhe]

Starting a discussion on how best to express the restrictions on the mimetype file, based on Matt's comment:

(For the record, that sentence is a really ugly mash-up of requirements that should be split into a list in a future version, and no MUST should ever use such vague language as "presented above".)

Spec says,

The contents of the mimetype file MUST NOT contain any leading padding or white space, MUST NOT begin with the Unicode signature (or Byte Order Mark), and the case of the media type string MUST be exactly as presented above. The mimetype file additionally MUST NOT be compressed or encrypted, and there MUST NOT be an extra field in its ZIP header.

I wonder about the last statement "there MUST NOT be an extra field in its ZIP header." What are we trying to prevent? It seems extra fields have lots of different uses, and that the whole idea was designed so zip processors could just skip over fields that they don't understand.

[mattgarrish]

What are we trying to prevent?

It wrecks the magic number aspect of the file if you use the extra fields, as you won't find the expected strings at their designated positions. Ran into that headache with a zip library that was inserting them on me once.

[dauwhe]

How about:

The first file in the OCF ZIP Container MUST be the mimetype file, which meets the following requirements:

• The contents of the mimetype file MUST be the MIME media type [RFC2046] string application/epub+zip encoded in US-ASCII [US-ASCII].

• The mimetype file MUST NOT contain any leading or trailing padding or white space.

• The mimetype file MUST NOT begin with the Unicode byte order mark U+FEFF.

• The mimetype file MUST NOT be compressed or encrypted, and there MUST NOT be an extra field in its ZIP header.

[dauwhe]

Closed via #1251