[1285] in BarnOwl Developers
Re: Zephyr charset-aware patch
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Thu Oct 29 18:14:57 2009
Resent-From: nelhage@mit.edu
Resent-To: barnowl-dev-mtg@charon.mit.edu
X-Original-To: nelhage@lunatique.mit.edu
Date: Tue, 03 Feb 2009 13:52:29 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nelson Elhage <nelhage@MIT.EDU>
cc: Keith Winstein <keithw@MIT.EDU>, Karl C Ramm <kcr@MIT.EDU>,
Sam Hartman <hartmans@MIT.EDU>, Greg Hudson <ghudson@MIT.EDU>,
Anders Kaseorg <andersk@MIT.EDU>, Geoffrey G Thomas <geofft@MIT.EDU>,
asedeno@MIT.EDU, "Mark W. Eichin" <eichin@MIT.EDU>,
dirty-owl-hackers@MIT.EDU, jhutz@cmu.edu
In-Reply-To: <200902031817.n13IHHOC017922@grapenut.srv.cs.cmu.edu>
--On Tuesday, February 03, 2009 01:16:38 PM -0500 Nelson Elhage
<nelhage@MIT.EDU> wrote:
> On Tue, Feb 03, 2009 at 11:57:05AM -0500, Jeffrey Hutzelman wrote:
>> How does this interact with use of zephyr notices to carry non-textual
>> data, for which implicit character set conversion may be totally
>> inappropriate? For example, I know there are tools in use for carrying
>> on encrypted conversations using zephyr notices to carry ciphertext.
>
> If you're referring to 'zcrypt', it encodes all data as ASCII before
> shoving it into a notice. If there are other tools that don't do this,
> then it might indeed be an issue for them, but I think I would be
> inclined to consider them buggy for not doing so.
I don't consider things which use zephyr to transport binary data to be
buggy, and I don't think it's reasonable to redefine notice fields to be
text and subject to manipulation by the low-level library, just because one
application of zephyr is an IM system we'd like to see have better
non-ASCII support. Further, even if we were to consider only that IM
system, it may still be the case that some applications would rather do
their own translation than have the library do it for them. This is likely
to be the case for any GUI application, since for best results they're
going to want to work with unicode even if the user has a non-unicode
locale.
Why does this behavior belong in ZSendNotice and ZReceiveNotice, and not at
some higher layer?
-- Jef
