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

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

From: Tex Texin <tex@yahoo-inc.com>
Date: Sun, 16 Dec 2007 22:38:37 -0800
Message-ID: <012AB2B223CB3F4BB846962876F4721785E7EE@SNV-EXVS08.ds.corp.yahoo.com>
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 GMT

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