Mailing-List: contact dev-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of justin.ross@gmail.com
 designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <521606E8.2030508@redhat.com>
References: <20130821200457.256250@gmx.com>
	<CANVjZ_SH5r_8_gR5U8O2os-XNXraD9kKKwFnZLE6R_-znzEAKQ@mail.gmail.com>
	<521606E8.2030508@redhat.com>
Date: Thu, 22 Aug 2013 10:36:44 -0400
Message-ID: 
 <CANVjZ_RJuRnLv9uxfiprjGww4yH6N_Sk-u_n5nXVe2SwJsdJfQ@mail.gmail.com>
Subject: Re: UTF8 / binary strings in dynamic languages
From: Justin Ross <justin.ross@gmail.com>
To: "dev@qpid.apache.org" <dev@qpid.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 22, 2013 at 8:41 AM, Gordon Sim <gsim@redhat.com> wrote:
> On 08/21/2013 10:43 PM, Justin Ross wrote:
>> "If I put a binary value in a map and encoded it some of the time it
>> might be valid utf8, other times not."  This shouldn't be allowed to
>> happen, IMO.  You meant it to be a binary value--we have to find a way
>> to capture and preserve that information.
>
> I believe the point was that for an application sending binary data via the
> ambiguous string type (between two processes in languages that have such a
> type), if that was encoded on the wire as str16 (i.e. utf8) it could lead to
> subtle bugs.
>
> Testing could work until the actual binary payload was changed in some way
> such that it was not valid utf8.

Right.  I'm saying that sucks, so don't do that.  For instance, we
could ask our users to use a 'Data' class to input arbitrary bytes,
and otherwise treat ambiguous strings as textual.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org