From: Hans Aberg (firstname.lastname@example.org)
Date: Mon Jun 01 2009 - 10:57:39 CDT
On 1 Jun 2009, at 16:56, Phillips, Addison wrote:
> Uh... the IETF does not define UTF-8. The Unicode Consortium does.
> But even if you want to build on the IETF documents, RFC 3629 was
> published six years ago. Basing a new implementation on something
> published 11 years ago and obsolete the last six years? Not a good
It says the date is November 2003, so it must be 2015 now :-). But I
do not remember this, but I think the original UTF-8 was not by the
Unicode, but by some Unix group. For some period of time, there were
two different one, one with the UTF-16 limitation, the other not.
> One problem with using a non-conformant UTF-8-like encoding to
> transmit non-textual data is that other processes probably are
> sensitive to the proper formulation of UTF-8. Such a process might
> reinterpret the data using another character encoding or otherwise
> stop processing it as an error (or security risk).
Sure, but not in the context at hand.
> Besides, there are many fine transfer encoding syntaxes available
> for transmitting binary data that don't involve pretending that the
> data is text.
Yes sure, but unfortunately, they can't be used in argument passing.
Setting up IPC just to get some arguments and environmental variables
is overkill. And it would not illustrate the idea of passing objects
in the arguments.
This archive was generated by hypermail 2.1.5 : Mon Jun 01 2009 - 11:01:02 CDT