Xref: utzoo news.software.b:5308 news.misc:5118
Path: utzoo!utstat!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!ukc!strath-cs!ctssuk!VERKADE
From: VERKADE@CTSS.CO.UK (Herman Verkade)
Newsgroups: news.software.b,news.misc
Subject: Re: Time for 8 bit news, isn't it?????.
Message-ID: <900802011259.00001B1F@MARVIN.CTSS.CO.UK>
Date: 2 Aug 90 01:12:59 GMT
Organization: CompuThoughts Software Solutions (UK) Ltd, Glasgow, Scotland, UK
Lines: 60

A couple of comments on 8 bit news. It seems to me that it is not necesary to
convert the whole net to 8 bit. The 7 bit restriction is only a problem for
specific newsgroups: newsgroups in languages other than english and newsgroups
containing binary data, such as bitmaps, .gif files, etc. So, I don't think
**everybody** needs to upgrade to some implementation that supports 8 bits.
Only those that wish to carry newsgroups, that need it. All we would need
is a standard, not necesarily a world-wide upgrade of software.

For example, if the Germans and the Fins decide that their local language
newsgroups will be 8 bit, then that is of no business of the Americans,
British, Spanish or Russians. As long as there is some software that support
8 bits (And C News seems to do that or alternatively a few changes in B News)
and maybe some way of indicating that a particular group expects 8-bit, so
that when posting to a 7 bit group another signature can be used; one that
doesn't have 8 bit characters in it. And if people want to start a new
newsgroup for .gif files in 8 bit mode then, again, the sites that want
to carry it must install an 8 bit version. If your feed doesn't support it,
get another feed for that newsgroup (A similar situation exists in the UK,
where UKC doesn't carry nor forward `alt.sex.pictures'. Sites that want it
get another feed for that group).

The next problem would be how to read an 8 bit group, both for groups that
use different character sets and for groups that carry other 8 bit data. As
someone earlier suggested, maybe an extra header should be added to the
standard that indicates what type of data it is. For mail there are RFC-1049
(Content-Type) and RFC-1154 (Encoding), which are extensions to RFC-822. The
extra header fields would only need to be interpreted by the news reader. So,
only if you want to read an 8 bit group, get an 8 bit reader. As long as we
can agree on some standard.

My proposal would be RFC-1154-style, because it also allows one message to
contain encodings in different parts and could therefore also be used to
automaticaly convert different parts of a message in 7 bit groups. For
example, a message containing a uuencoded file preceded by some explanation
in ASCII and a signature at the bottom, could have a header such as:

    Encoding: 10 text, 1045 uuencode, 5 text

A smart news reader could display the two text parts and ask whether you want
the uuencode bit to be uudecoded. For an article containing a header like:

    Encoding: 15 text, 637 uugif, 5 text

the reader could then automatically extract the uuencoded .gif file and
display an image instead. Etc, etc, etc. And only users that want such
functionality switch to a news reader that supports it.

I realise that I am discussing two seperate topics here:
1) Provide 8 bit transport mechanisms so that international character sets
   can be used, but enable 8 bits only on a newsgroup by newsgroup basis
   with either a designated character set for such a group, or an Encoding
   header to indicate the character set.
2) An Encoding: header for carrying data other that text (in either 7 or
   8 bit groups).

For both I suggest to provide a standard, but not to force anybody to upgrade
to new software. I think this proposal provides for backward compatibility
and allows the requirements of a fair number of net.people.

Herman Verkade