From: jwagner@PRINCETON.EDU
Newsgroups: bit.listserv.ibmtcp-l
Subject: Re: encoding binary-file attributes for mailing
Date: 10 Apr 92 18:45:29 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-To:         IBM TCP/IP List <IBMTCP-L@pucc.Princeton.EDU>
              06 Apr 92 23:14:47 +0200. <9204062119.AA14350@Princeton.EDU>

> On Mon, 6 Apr 1992 17:12:04 -0400 jwagner@PRINCETON.EDU said:
>
> >Transport of MIME within BITNET will require a new convention about what
> >is translated  to EBCDIC.  This will  have impact not  only on  SMTP and
> >Mailer but also on JNET and  UREP (they can't simply translate EBCDIC to
> >ASCII any more).
>
> JNET uses reversible  translation tables. This is one of  the reasons why
> so many people copy  the JNET tables when they need an  A2E or E2A table.
> In other words, if JNET translated a MIME message to ASCII before feeding
> it to the mailer, which then places  it in the user's mailbox, all it has
> to do is translate back.

I suspect JNET's translation tables are only reversible if the input is
printable EBCDIC.  MIME will allow transport of byte values that fall outside
the printable character range.  If I translate characters in the character set
GLORP using the process

     GLORP -> Ebcdic to Ascii -> bytes -> Ascii to Ebcdic  ->  other bytes
                translation                 translation

it is likely that I will not get the original out the back end.  GLORP isn't
EBCDIC and no reversible tables I know of are entirely reversable for all 256
possible byte values.  The same logic applies to other character sets that are
not ASCII.  If you translate something believing it is EBCDIC (or ASCII) and it
is something else you are likely to get garbage.

Good examples of this class of problem (arbitrarily handling data as if you
knew what the data was) already exist on the network today.  If I send mail in
EBCDIC with the following

     string1<CR><LF>string2

(EBCDIC CR is x'0D' and LF is x'25') what will the destination site see?
Assuming a one way pass though a JNET system (i.e. Ebcdic to Ascii translation
done) I expect they will see

      string1
      string2

Similarly if I send a solid vertical bar (Ebcdic x'C9') will I get back a solid
bar or a split bar?  The only way to sure is to label the data as being in
EBCDIC and not translate it inappropriately.

The base issue is that all systems must recognize that we live in a
multi-character set world and behave appropriately.  MIME is designed to aid in
appropriate behaviour because it labels the mail as to its content.  This
allows the various pieces of software to make a decision as to what should be
done.  But it does mean that all software must be "smart" or, if it is  not
smart, it must not do anything that will destroy the "integrity" of the data it
is processing (such as arbitrarily apply a character set translation).

One possible solution to this problem for the NJE world is to simply transport
bytes as bytes.  NJE carries "lines" defined by byte counts.  Since this
doesn't attach significance to the meaning of the bytes they can be transported
and delivered and the meaning can be assigned at the destination (where the
bytes leave the NJE network).  As long as the data is labeled at the origin
this process is simple (the process is simple, that doesn't mean that makes
implementation simple).

  John

   John
Newsgroups: bit.listserv.ibmtcp-l