Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!sun!amdcad!ames!sdcsvax!ucbvax!ucbarpa.Berkeley.EDU!fair
From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair)
Newsgroups: news.misc
Subject: Re: Messages with >80-character lines
Message-ID: <21357@ucbvax.BERKELEY.EDU>
Date: Tue, 20-Oct-87 04:34:10 EDT
Article-I.D.: ucbvax.21357
Posted: Tue Oct 20 04:34:10 1987
Date-Received: Wed, 21-Oct-87 07:21:03 EDT
References: <7526@g.ms.uky.edu> <4756@oberon.USC.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: USENET Protocol Police, Western Gateway Division
Lines: 44

There are two issues here:

	1. Netnews transport
	2. Netnews presentation

The first issue is perfectly clear to me: all systems should be
able to transmit netnews articles through their gizzards without
change (excepting those changes in the headers that are mandated
by normal netnews operation, like updating "path:"). If there is
some type of netnews article that some minority of the network
can't swallow, then they're broken, and should be fixed, or left
on the periphery of netnews distribution so that their brokeness
won't affect the rest of the network. I do not intend to preclude
IBM systems from storing things in some internal format that is
more efficient for them; I just want them to understand that when
they transmit such an article to the outside world that the article
should be converted back to what the rest of the network views as
"normal": ASCII, with no transliterations, substitutions, or other
information loss.

The second issue is a bit more thorny. Taken to logical extreme,
we need to write articles in some formatting or page description
language, which the user interfaces interpret for whatever display
the user is using. SGML, anyone? Or perhaps {n,t,dit}roff? Maybe
PostScript?

Whatever we finally choose should be relatively easy to interpret,
easy to learn and write things in (nroff with -ms isn't so bad, if
you don't do anything too fancy), and yet powerful enough to do the
sort of fancy things you might see on a Sun or Macintosh. Not a
weekend hack project, it seems to me.

Given that none of the existing user interfaces is prepared to deal
with this sort of thing automatically (sure, you can pipe articles
to external interpreters, but that's not the point), we have to
make some assumptions, and the prevailing assumptions are 24 lines
of 80 ASCII characters, with various format effectors like tabs,
blank lines and form feeds. People who violate these assumptions
should bear in mind that in making their articles harder to read
on what is certainly the standard display size on the USENET today,
are decreasing the probability that their message will be read and
understood.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu