From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomas Mraz Subject: Re: A change to string encoding Date: Tue, 10 Mar 2009 17:22:32 +0100 Message-ID: <1236702152.3485.18.camel@vespa.frost.loc> References: <1236683237.3386.22.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from [10.32.10.93] (vpn-10-93.str.redhat.com [10.32.10.93]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2AGMYUg021632 for ; Tue, 10 Mar 2009 12:22:35 -0400 In-Reply-To: <1236683237.3386.22.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, 2009-03-10 at 11:07 +0000, Matthew Booth wrote: > The problem with current string encoding is that it is parsable, but > non-human readable. It also complicates parsing by requiring 2 different > decoding methods to be implemented. > > It occurs to me that a URL encoding scheme would also meet the parsing > requirements. Additionally: > > 1. It is always human readable. > 2. There is only 1 encoding scheme. > 3. Substring matching on encoded strings will always succeed. > > URL encoding is just one way to achieve this, and has the advantage of > being widely implemented. However, the minimal requirements would be a > scheme which encoded only separator characters (whitespace in this case) > without the use of those separators. > > I'm sure this has been considered before. Given that it's a road I'm > considering heading down, what were the reasons for not doing it? It was already discussed here without a conclusion: http://marc.info/?l=linux-audit&m=120978583018941&w=2 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb