- From: Tex Texin <tex@yahoo-inc.com>
- Date: Sun, 2 Dec 2007 18:48:11 -0800
- To: "Marcos Caceres" <marcosscaceres@gmail.com>
- Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>, <www-international@w3.org>, <public-appformats@w3.org>
Marcos, I don't see a conflict with my proposal. The benefit is it eliminates perpetuating the encoding ambiguity and interoperability problems that plague many of our specs and apps. Restricting filenames to utf-8 would mean if you don't have the latest zipping tools, you need to stick with ascii names, which is not such a big burden (and kinder than adding in cp437 support!). Regarding the design principle, it seems to give too much weight to operating system vendors and therefore somewhat inappropriate for the W3C. Search for downloadable freeware compression utilities, and there are many that support zip format. Perhaps the principle should reflect more what is commonly available for no cost, rather than begin tied to OS support. I seearched for "zip files download unicode filenames" and see many that support unicode filenames. (I didn't check to see how many were free or how broad the OS coverage was.) tex -----Original Message----- From: Marcos Caceres [mailto:marcosscaceres@gmail.com] > If we were talking about ancient zip files, then we might have to tolerate such names. But as we are discussing new specs, instead of supporting all possible zip files, why not specify the use of zip files, with the constraint that filenames be stored as utf-8, and make the non-utf-8 names unacceptable. Perhaps with modern tools, this isn't a problem. One of our design principles [1] for the Widget spec is that authors should be able to create widgets just using the zipping tools that have been pre-packaged with an OS. Because the introduction of allowing UTF-8 names in Zip is a very recent addition to that spec, we might not see implementations for a long time.
Received on Monday, 3 December 2007 02:48:38 UTC