Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <CALK=YjNn9=v7byz=BMQFjMnUngswqb=BWKLCUasKSrfBhtcg2A@mail.gmail.com>
References: <20160729220052.29A973A0056@svn01-us-west.apache.org>
 <CALK=YjMYfDNKLRaFjEQnnRXzYND=WmYOUf0wMN-ReTpt1QzE+w@mail.gmail.com>
 <CALK=YjOL6=eedb=C0L7jQNpvz9P27TcDXhA-=eiRFesO+uXZ8g@mail.gmail.com>
 <CACsi253fcuGK6ur7fEQqynukHnMZ_35sraLY_zjMuiBcvqwxww@mail.gmail.com>
 <CACsi252-8UqXa0VCNY0ce=AmwzcgWhozk3uSZNv5Gs_oEBGkbQ@mail.gmail.com>
 <CALK=YjOVSEUqZD7oQVwS+d=LgSoGNopRHopjBOZYuxU87tzOWQ@mail.gmail.com>
 <CACsi251T7pbBqGOXSTLtA8JK8PpTEYKYcdNKjLEOx_tibFxDNA@mail.gmail.com>
 <CALK=YjMnmM7dT8JB73V6rJcunCEtah+911mAqNhJsuL43jYd8g@mail.gmail.com>
 <CALK=YjM7CReL86xe4VsJnLPFOFZn52VwNKOpaJmh7ZtUzsUVQw@mail.gmail.com>
 <CALK=YjOugeCvwmTh9EnFN_N+MkqSQOa-b7Y3TfspAEb76LFtkg@mail.gmail.com>
 <CALK=YjMSLD8x5kkqYupoYPjjLENKLoim6bXJ1xWmfwXAPeJKuw@mail.gmail.com>
 <CALK=YjOnNTFBocAkSHWRzGrrht3X=uZu38ffo=Q+BaT6OywpSg@mail.gmail.com> <CALK=YjNn9=v7byz=BMQFjMnUngswqb=BWKLCUasKSrfBhtcg2A@mail.gmail.com>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Mon, 1 Aug 2016 14:22:01 -0500
Message-ID: <CACsi251Nd7zEqCaAPi=P0ZqgNUF=cGtqBReJS6PowQHED1ZsuA@mail.gmail.com>
Subject: Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a11474b8ccc0f9d053907830a
archived-at: Mon, 01 Aug 2016 19:22:07 -0000

--001a11474b8ccc0f9d053907830a
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 1, 2016 at 2:08 PM, Eric Covener <covener@gmail.com> wrote:

> The mainframe guys say it's an unfortunate but intentional
> working-as-designed fudge of the iconv results to make the preferred
> line separator (0x15)map to/from 0x0A.  Seems like safest would be to
> not use a table for conversion but instead go through the same iconv
> that we're using to convert the data?


We have a few choices, but the bottom line is that we treat /r/n
as 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping.

Choice 1; map both 0x15 and 0x37 to ASCII 0x0d, which grows the
number of ascii equivalents by one. Both would be treated at CTRL.

Choice 2; invert our current mapping, ASCII NL to EBCDIC LF and
visa-versa. That would leave 0x37 'unguarded' and allowed as opaque
text chars.

Choice 3; treat the entire C1 codeplane on EBCDIC as CTRLs, and
ignore some 32 'opaque bytes' as unsupportable.

Thoughts?

--001a11474b8ccc0f9d053907830a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 2:08 PM, Eric Covener <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:covener@gmail.com" target=3D"_blank">covener@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">The mainframe guys say it&#39;s a=
n unfortunate but intentional<br>
working-as-designed fudge of the iconv results to make the preferred<br>
line separator (0x15)map to/from 0x0A.=C2=A0 Seems like safest would be to<=
br>
not use a table for conversion but instead go through the same iconv<br>
that we&#39;re using to convert the data?</blockquote><div><br></div><div>W=
e have a few choices, but the bottom line is that we treat /r/n</div><div>a=
s 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping.</div><div><br></d=
iv><div>Choice 1; map both 0x15 and 0x37 to ASCII 0x0d, which grows the</di=
v><div>number of ascii equivalents by one. Both would be treated at CTRL.</=
div><div><br></div><div>Choice 2; invert our current mapping, ASCII NL to E=
BCDIC LF and</div><div>visa-versa. That would leave 0x37 &#39;unguarded&#39=
; and allowed as opaque</div><div>text chars.</div><div><br></div><div>Choi=
ce 3; treat the entire C1 codeplane on EBCDIC as CTRLs, and</div><div>ignor=
e some 32 &#39;opaque bytes&#39; as unsupportable.</div><div><br></div><div=
>Thoughts?</div><div><br></div><div><br></div><div><br></div></div></div></=
div>

--001a11474b8ccc0f9d053907830a--