- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Wed, 10 Oct 2007 17:13:27 +1000
- To: "Marcos Caceres" <marcosscaceres@gmail.com>, "public-appformats@w3.org" <public-appformats@w3.org>, "Jon Ferraiolo" <jferrai@us.ibm.com>, "Arthur Barstow" <Art.Barstow@nokia.com>
> > A Zip archive may be created using the ZIP64 extensions as defined in > > [ZIP], but preferably only when a widget resource exceeds > > 4,294,967,296 bytes (4 gigabytes). > > Is there any reason for expressing that preference? It strikes me > that it has no impact whatsoever on the interoperability of > implementations. The way I see it, Interoperability issues may arise if implementations are relying on platform APIs to do the decompression (no native platform API that I have found supports Zip64). To support Zip64, implementers must write, or otherwise acquire, their own proprietary Zip64 library and make it part of their widget engine... this might be standard industry practice, but I don't know. I put the Zip64 requirements in the spec because Jon has requested it on a number of occasions (and made a case about future proofing widgets). I personally don't see much value of mandating Zip64 support as no one seems to natively support it (and seems to come with a lot of complicated baggage (, which would go against the KISS principle(?)). It is highly unlikely that anyone will ever make a 4gb widget (and there is no point in using Zip64 unless you are zipping a file bigger then 4gb, AFAIK). I'm inclined to remove that requirement, but if people can present some more use cases I guess it can stay... I'll make sure that this gets marked as an issue and revise it once we get some implementation experience/feedback. > > The names of files and directories within a Zip archive must only be > > encoded in US-ASCII (IBM Code Page 437) or UTF-8, but only if general > > purpose bit 11 is set in accordance with the [ZIP] specification (set > > of UTF-8 or unset of US-ASCII). > > This sentence is confusing. > > Code Page 437 and US-ASCII are not the same. True. I have removed the reference to Code Page 437 as code points for the filenames should be treated as US-ASCII (or UTF-8 when appropriate). > The half-sentence "but only if general purpose bit 11 is set ..." > should be turned into a clause of its own, "General Purpose Bit 11 > MUST be set in accordance with the [ZIP] specification." I've modified the spec to read as you suggested. Kind regards, -- Marcos Caceres http://datadriven.com.au
Received on Wednesday, 10 October 2007 07:13:44 UTC