> From:         Michael Wagner +49 228 303 245 <WAGNER@DBNGMD21>
> > MAYBE (yes?) this topics be moved over to IBMTCP-L ?
>
>   I think you're confusing layers here.  I assume IBMTCP-L is a list
>   for discussing that funny idea that BITNET should run TCP as a
>   transport layer.  Although the idea is funny for different
 
I assumed it was to talk about IBM's TCP/IP product colloquially called
FAL.  That can also encompass it's use as a basis of BITNET, but I'd think
it would also be a place to discuss bugs as well.  We found one, but didn't
get to squish it.
 
> > How would you like your mail?  Print?  That's still limited to 132
> > or 150.  How about disk dump?  netdata?  card dump?  pick your
> > poison and rewrite MAILER.
>
>   I would like my mail to arrive the way it was sent.  I want no
 
OK, one big stream of ASCII characters when it comes from such a machine.
 
I think I was talking about the mechanism it comes in; which would best be
used to represent the image of the mail, since it is not practical to make
the mail be exactly the way it was sent if it originated on a different
machine.  Since mail is text, shouldn't it be treated as such, and not binary?
 
>   folding in it that the user didn't put in himself.  The network
>   (on some level) should provide a transport service that handles
>   lines of any length.  In fact, it does.  Netdata.  The others you
>   mentioned also work, although, for various reasons, they aren't as
>   good or universal.  If, furthur down, the network really works in
 
All three have bad points.  Netdata has it's bad points, too, just like
CARD does.  Transportability is not so much a problem as deliverability
since in deliverability, the choice of representation format affects the
user directly.  Since mail is basically a one file at a time transport,
NETDATA should suffice over NJE.
 
>   No one should be rewriting MAILER to fix a problem in the
>   definition of the transport layer.  More importantly, MAILER
>   should never have had that restriction built into it.  It did,
>   however, because, as I said before, it wasn't meant to solve the
>   wide variety of problems that it is now being pushed into.
>   However, fixing the network fixes it for all applications.  Fixing
>   MAILER only solves one problem.  So it's pretty clear where I
>   think time should be spent.
 
I don't think I follow this.  If MAILER were to transport mail over
BITNET's NJE network in such a way that upon delivery, the long lines
were still long lines, unmangled, then is that not A solution to
THE problem?  RFC822 does not mandate the use of TCP/IP.  If RFC822
can be implemented in another environment, it's still RFC822 but in
another environment.