W3C home > Mailing lists > Public > public-appformats@w3.org > December 2007

Re: FW: [waf] Agenda for 2007-12-05 Voice Conf

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Tue, 18 Dec 2007 14:55:15 +1000
Message-ID: <b21a10670712172055n26e7a725q5518bf01f1392b29@mail.gmail.com>
To: "Tex Texin" <tex@yahoo-inc.com>, "public-appformats@w3.org (public)" <public-appformats@w3.org>

Hi Tex,

> > > My view remains that cp437 is not well understood, and is no longer
> > > used with frequency, and so its support is not required.

This is generally true for OSs. However, according to the Zip spec,
Zip should treat/expect file names as cp437 to conform.

> > > Supporting cp437 will simply lead to misuse as unintentionally, or
> > > intentionally, it will be used as a proxy for iso8859-1 or other
> > > encodings and cause unnecessary problems.

True.

> > > Although zip has a method for declaring the encoding, and could be
> > > implemented in a compliant fashion, it also may not be.
> > > There isn't a good way to detect and reject a filename with an
> > > encoding other than cp437 or utf-8.
> > >
> > > It is reasonable and prudent for Widgets to insist on UTF-8
> > > filenames with the appropriate bit setting, and eliminate the
> > > ambiguity, and be 100% compatible with the zip spec.  Problems with
> > > the encoding are more likely to be detected if  UTF-8 is required.

I've now included "Encoding File Name Field in UTF-8 is recommended"
into the spec. This explicitly makes it the preferred encoding format
for widgets.

> > > Authors can use a modern tool with support for UTF-8, or restrict
> > > their names to ASCII.
> > >
> > > So, I do not see any reason to support the cp437 encoding.
> > >
> > > That said, if there isn't support for this viewpoint, it is ok to go
> > > ahead, we can agree to disagree. The world is plenty polluted with
> > > encodings, this won't do that much damage over what already exists.
> > > I think otherwise we are (or I am) getting repetitive in stating the case.

I don't think anyone disagrees. It's just that the tools are for
creating UTF-8 zip archives are not all there yet. I am sure that will
change with time (especially now that it is part of the Zip spec).

> > > Separately, you list semicolon as a character that can be used in filenames.
> > > On many systems it is a command separator and is disallowed in
> > > filepaths. I would make it a reserved character.

Done.

> > > Plus is also used for command syntax and I would think should be reserved.
> > >
> > > If not reserved, then a warning should be given.
> > >

I've noted it as a potential issue in the spec.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au
Received on Tuesday, 18 December 2007 05:39:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:24 GMT