- From: Tex Texin <tex@yahoo-inc.com>
- Date: Sun, 16 Dec 2007 22:38:37 -0800
- To: <public-appformats@w3.org>
- Cc: "Marcos Caceres" <marcosscaceres@gmail.com>, "Tex Texin" <tex@yahoo-inc.com>
Resending to this list as requested. I trimmed the preceding mails, since I wasn't sure if it was appropriate to send them to the public list, even though there didn't seem to be anything contentious or private there. Tex > > From: "ext Tex Texin" <tex@yahoo-inc.com> > Date: December 5, 2007 8:06:13 AM EST > To: "Arthur Barstow" <art.barstow@nokia.com>, "ext Richard Ishida" > <ishida@w3.org> > Cc: "member-appformats WG" <member-appformats@w3.org>, "Doug Schepers" > <schepers@w3.org>, "Tex Texin" <tex@yahoo-inc.com> > Subject: RE: [waf] Agenda for 2007-12-05 Voice Conf > > > Hi, > > Thanks for the concern and attention to my comment. It is much appreciated. > > My view remains that cp437 is not well understood, and is no longer > used with frequency, and so its support is not required. > 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. > > 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. > > 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. > > > 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. > > Plus is also used for command syntax and I would think should be reserved. > > If not reserved, then a warning should be given. > > Hth > tex
Received on Monday, 17 December 2007 06:40:07 UTC