I'm not sure I've read all the posts in this thread, but I believe:
1) ZIP totally allows zip items representing zero-byte files as well as
items representing empty directories. The later in particular is quite
useful in general ZIP usage. I remember seeing some bugs in the early
1990's with some ZIP programs not handling this correctly. But some uses,
like self-extracting ZIPs that contain a pre-made empty directory for user
data, will not work correctly without support for empty directories.
2) A zero-byte XML file is never correct. Or at least it doesn't conform
the the XML Recommendation since it is not well-formed XML.
3) On the other hand, except for the handful of ODF-defined ZIP items,
like contents.xml, etc., we don't have any anti-spoofing requirement,
right? In other words we don't have a conformance requirement that says
that content-type in the manifest matches the zip item. If we had that
restriction then it would not be conforming to have an zero-byte XML with
content type text/xml or application/xml. This would also make
non-conformant potentially more sinister things like an EXE pretending to
be image/png and stuff like that.
4)However, there would be nothing wrong with a zero-byte foo.xml with a
content type of text/plain or something similar.
5)Digital signatures apply to the contents of a file. So you might think
there is nothing to sign. But in fact the zip item does bear a name and a
time stamp, and either of these may bear information that could be harmed
by tampering. We cover the name by singing the manifest. But we don't
appear to cover tampering with the time stamp. Of course, this is
independent of the zero byte issue.
6) The most straightforward way for someone to implement a generic ODF
package consumer would be to create a hashtable of each "file" in the ZIP
and associate it with a record that contains metata on the entry (date,
zip, compression method, etc.) as well as access to the underlying data.
This is very simply in most programming languages. Then when modifying
and saving the package, I would recreate the manifest and write out all
the other ZIP items.
My guess is authors of this straightforward approach will often fail to
properly handle the empty directory case, both on reading and on writing.
(We have no way of notating an empty directory in the manifest). So I'd
favor a recommendation against (should not) or a prohibition against
(shall not) an ODF package containing empty directories. We have no need
of it, and it will probably not work well across implementations.
-Rob
