An outline proposal

[robert_weir at us.ibm.com]

sc34wg1study-bounces at vse.cz wrote on 10/13/2010 12:20:22 PM:

> 
> My view,
> A bare outline, skipping the 'version'/type of zip, until we get legal 
input.
>

This WG has a deadline, so we should not wait or skip anything in the vain 
hope that legal assistance will be coming.  It won't come.
 
> Comments please?
> 
> 2010-10-09T21:29:51Z
> Outline requirements for a zip specification.
> rev 1.0, Dave Pawson
> 
> 1. Provide a compressed archive format for general use.
>

OK.

 
> 1.1. A compression algorithm shall be provided which is usable without
> infringing any existent patent.
>

The goal should not be that the algorithm is free of IPR but that the 
users of the standard may practice the algorithm without payment of 
royalties.  For example, the owner of the patent could pledge not to 
assert their patents for implementors of the standard.  Royalty-free and 
IPR-free are not the same thing, though they are often confused.

 
> 1.2. A compression algorithm shall be provided which may be used
> without payment of any sort.
>

OK.
 
> 
> 2. The packaged entity shall hold one or more file.
>

OK.  This needs further specification:  A file has a name, metadata (date, 
permissions, archive bit?) as well as contents.  Detailed requirements?
 
> 2.1 It will be possible to extract one or more individual files from
> the package.
>

OK.
 
> 2.2 Any file hierarchy present when the package is created shall be
> duplicated on extraction if requested.
>

So this leads to the requirement that you can store a file hierarchy.
 
> 2.3 The package shall hold any combintation of  binary and/or text
> files.
>

Not sure I agree that text files must be distinguishable from binary 
files.  Once you have text files you end up dealing with DOS/Unix CRLF 
conversions.  Better to just store the file as-is, directly, at which 
point there is no difference between text and binary files.

 
> 2.3.1 There shall be no difference between a file prior to being
> archived and the corresponding file when extracted from the archive.
> 

OK.  And per above, if you are not changing a text file on different OS's 
then there is no difference between text and binary.

> 2.3.2 No change shall be made to any character encoding by compressing
> and decompressing a file. I.e. an input file after decompression must
> match its character encoding prior to compression.
> 

Again, then why distinguish text from binary?

> 3. A means of verification of an archive shall be provided.
>

Not sure what is intended here.  Do you mean you want a specification of a 
verification procedure? (A validator?)Or that a conforming 
ZIP-consumer/ZIP-producer must include a means of verification?

 
> 4. A means of listing the contents of an archive without extraction
> shall be provided.
> 

Again, not clear who is providing this, the specification or a 
consumer/producer?

> 5. A package listing shall be created as a a plain text file within
> the archive which lists all files within the archive excepting itself.
>

I don't see this as a requirement.  In fact, if you look at the most 
common operations on an archive, including the incremental addition and/or 
replacement of files, you'll see that the most efficient encoding of 
directory information is unlikely to be a plain text file package listing.
 
> 
> 5. A means of extracting the contents of an archive shall be provided
> which meets the requirement of 2.3.1
>

Same response as to 2.3.1
 
> 5.1. A decompression algorithm shall be provided which is usable without
> infringing any existent patent.
>

Same response as to 1.1.

> 5.2. A decompression algorithm shall be provided which may be used
> without payment of any sort.
>

Same response as to 1.2.


Regards,

-Rob


> 
> 
> 
> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
> _______________________________________________
> sc34wg1study mailing list
> sc34wg1study at vse.cz
> http://mailman.vse.cz/mailman/listinfo/sc34wg1study