RE: [office] RE: Directories in Zip packages

[robert_weir@us.ibm.com]

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