> 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
  reasons, it might help here, if TCP does not impose width
  restrictions on the traffic passing over it.  Thereafter, one
  wouldn't need to discuss folding of 822 for unintended reasons
  (see comments at end).
 
  However, I assumed this topic was brought up on LSTSRV-L because
  it addressed a LISTSERV (or a MAILER) concern.  I answered about
  what 822 conventions allow, because LISTSERV and MAILER both
  purport to use something akin to 822 syntax (although neither of
  them really takes this too seriously, unfortunately).
 
> 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
  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
  80 byte tree images, that is of little concern to me (even furthur
  down, by the way, it works with electrons, but no one asks me
  whether I prefer left-spin or right-spin atoms in my reader).
 
  There are, of course, subareas of the network that still cannot
  accept unrestricted length files.  I don't understand why, since
  the software, for practically all conceivable systems, has been
  available for quite some time.  None-the-less, so is it.  Clearly,
  then, their subarea cannot communicate at the same level as the
  rest of the network, and they should be communicating through some
  sort of gateway.  The idea that they should hold the network back
  to 80 byte MAIL images is silly.
 
  Section 3.4.10 of RFC822 addresses, perhaps not in enough detail,
  how messages should flow through networks that don't allow an
  exact expression of RFC822 messages, and how a gateway between
  non-homogeneous networks should work in this regard.
 
  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.
 
  Incidentally, folding in 822 was meant to enhance readability, not
  to make up for lack of functionality in the transport layer.
  That's why people run into problems trying to make 822 fold on
  very hard boundaries.  It wasn't designed to do that.
 
Michael