HDTenEightyP/NetNews huggingface dataset:
From: brad@clarinet.com (Brad Templeton)
Subject: Re: 8-bit news
Organization: ClariNet Communications Corp.
Date: Wed, 16 Dec 1992 22:48:13 GMT

So redefine the NNTP standard to support full 8 bit paths, but include
in the negotations some information about what version you are supporting.

7 talks to 7 or 8 talks to 8, no change.  8 talks to 7 or vice versa,
the newer one does some mapping, adding a map header if encoding downwards
and removing/altering one if encoding upwards.

This means people on 7 bit systems who see articles that contained 8
bits will see them as encoding sequences.  There will be a few problems
with included text from such sites if the included text contains encoded
characters.

The other primary transmission mode, uucp, already is 8 bits clean.
-- 
Brad Templeton, ClariNet Communications Corp. -- Sunnyvale, CA 408/296-0366
Xref: sparky comp.std.internat:859 news.admin.misc:765
From: Markku.Savela@tel.vtt.fi (Markku Savela)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 15 Dec 1992 21:58:06 GMT
Organization: Technical Research Centre of Finland
Reply-To: savela@tel.vtt.fi (Markku Savela)
NNTP-Posting-Host: tel4.tel.vtt.fi
In-reply-to: kosta@blues.kk.sub.org's message of Tue, 15 Dec 92 01:23:06 MET

In article <89RsVB3w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:

>I fully agree. As long as we don't have one ultimate character set,
>which ISO 10646 claims to be, as the network character set we need

Actually we already have one ultimate character encoding system, sort
of. And that is ISO 2022 + registered character sets. Implementing
that is about the same complexity as ISO 10646, it's just different
encoding for the same information.

1/2 :-)

--
Markku Savela (savela@tel.vtt.fi), Technical Research Centre of Finland
Telecommunications Laboratory, Otakaari 7 B, SF-02150 ESPOO, Finland
Xref: sparky comp.std.internat:911 news.admin.misc:849
From: erik@poel.juice.or.jp (Erik M. van der Poel)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 18 Dec 92 12:10:57 GMT
Organization: sometimes

Sorry about the late reply.  I've got a slow feed. :-(


> >Perhaps the best approach for the American community would be to avoid
> >using the ESCAPE that is problematic in netnews and the 8th bit that
> >is problematic in both email and netnews, and to use a Viet-like or
> >Simonsen-like method, possibly together with an alt.chinese.text-like
> >method.  (And this is what you've started doing, right, Steve?)
> 
> Erik,
> 
>   I hope you are really intending that we collectively move to some
> MIME-derivative that can handle these existing interim formats, the
> public non-standard formats you've mentioned, and also that will
> handle the formats we should all be headed towards (namely ISO-8859-*
> and ISO-10646) along with non-text encodings for GIF, TIFF, and audio.

Well, yes, in the absence of MIME headers, it is difficult to tell how
the contents of the message are encoded.  (But if people really wanted
to, they could treat the

	Newsgroups: soc.culture.vietnamese

header as if it also said

	Content-Type: text/plain; charset=viet

or whatever, and similarly for the other encodings that I mentioned.
Needless to say, I'm mostly kidding here.)

In other words, MIME headers definitely get my Yes vote.

Re: "the formats we should all be headed towards", it would be nice if
we all had the same opinion, but I'm not sure that that's the case.

Also, once people put in a lot of work to support what you're calling
"interim formats", people may not be willing to change things yet
again after that.  The old "if it ain't broke, don't fix it" attitude
may then rear it's ugly head.

The fully anticipated reply to this is of course that we should then
skip these interim formats and go straight to nirvana.

Well, I wish those people the best of luck.  In the meantime, I will
watch.  I like to watch.
-
-- 
Erik M. van der Poel                               erik@poel.juice.or.jp
Newsgroups: comp.std.internat,news.admin.misc
From: davidf@golem.waterloo.on.ca (David J. Fiander)
Subject: Useless bits of SMTP (was Re: 8-bit news)
Date: Wed, 16 Dec 1992 21:56:06 GMT

According to avg@rodan.UU.NET (Vadim Antonov):
>>SMTP is bloated?  I'll trade you SOML, SEND, SAML, and TURN for an
>>eight-bit negotiation mechanism.  We'll still slim it by a command or two.
>
>It already has features nobody uses (VRFY, EXPN, SOML, SAML, TURN)
>and simply useless (HELO). Most implementations simply don't know
>what to do with all that (i know because i had a pleasure of
>implementing SMTP stuff).

You've obviously never had to debug a mail connection
remotely.  I use VRFY and EXPN regularly.  I'm willing to give
up SOML, SEND, and SAML, but I think that TURN could become more
useful, especially now that the Internet is so wide that it can
take a minute or two to form the initial connection.
Newsgroups: comp.std.internat
From: MICHAEL.WILLETT@OFFICE.WANG.COM ("Michael Willett")
Subject: RAID standards in Europe
Organization: Mail to News Gateway at Wang Labs
Date: Fri, 11 Dec 1992 17:55:02 GMT

Would anyone know if there have been any new developments in
Europe regarding ISO or ECMA standards for RAIDs, especially
higher level RAIDs such as 5, 6, or 7?  Are European governments
requiring anything particular in this regard?

Michael.Willett@OFFICE.Wang.com
Xref: sparky comp.std.internat:874 news.admin.misc:789
From: lwj@cs.kun.nl (Luc Rooijakkers)
Subject: Re: 8-bit anything?
Organization: University of Nijmegen, The Netherlands
X-Newsreader: NN version 6.4.19
Date: Tue, 15 Dec 1992 13:11:42 GMT

In <Bz4oDJ.87D@poel.juice.or.jp> erik@poel.juice.or.jp (Erik M. van der Poel) writes:

>> if a message was tagged (say as being latin1, or shift-JIS, or big5 or
>> 8859-9), we have no problem

>The problem is that, currently, not very many messages are tagged.
>Hopefully, MIME tagging will become more widely used soon.

The next nn version will use MIME header tagging to indicate the
character set used. It will actually refuse to post 8-bit characters
without such headers (they will be added automatically if you tell
nn what character set to use).

By the way, isn't it time to create a news.8bit group :-) This subject
has been cropping up in lots of newsgroups during the last few weeks.

--
Luc Rooijakkers                                 Internet: lwj@cs.kun.nl
Faculty of Mathematics and Computer Science     UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands         tel. +3180652271
Xref: sparky comp.std.internat:833 soc.culture.nordic:7849 soc.culture.german:9228
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 15 Dec 1992 18:20:45 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net

In article <CKD.92Dec15161747@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>The "nonsense" is assuming that "just sending 8 bits" will work in the face
>of these software issues.  There are three ways to send 8-bit email through
>SMTP:
>
>1) make agreements to "just send 8 bits".  Works within an enclave.
>
>2) extend SMTP in some way to be guaranteed 8-bit compatible.
>
>3) "just send it and hope it gets there okay."
>
>The problem is that (1) tends to generalize into (3)...where the real
>solution is (2).

Look, if you're not using anything but ASCII "just send 8 bits"
works just fine. If you have an old software and want to get
extended character set you can't do it anyway, right?

"Just send 8 bits" is the proper superset of "just send 7 bits"
-- exactly the same as adding new header fields. It breaks nothing
as long as you do not use extensions.

>I'm certainly not insensitive to the needs of languages that don't fit in
>USASCII.  However, I'm also not insensitive to the needs of sites that
>could care less about 8-bit characters, have vendor-supplied software that
>blows up on 8-bit data, and aren't prepared to upgrade immediately.

If the vendor-software crashes on, say, a file with 1025-byte line
it's a bug, isn't it? If a program craches on ANYTHING it's a bug.
A bug is a bug is a bug. Call their tech support and have them to
fix it.

>As soon as there's a compatible SMTP extension for 8 bits, I'll at least
>try to hack it into my mailer (assuming the UIUC IDA sendmail folks don't
>beat me to it). 

"Just send 8 bits" *is* backward compatible. Check your logic.

>But I won't install anything that tries to pull a Nike and
>"Just Do It" to some unsuspecting mailer somewhere.

Then why on the Earth did you upgrade your software the last time?

--vadim

"Not only is UNIX dead, it's starting to smell bad." -- Rob Pike
Newsgroups: comp.std.internat
From: andrew@alarbus.oz.au (Andrew Reye)
Subject: Week Numbering
Reply-To: andrew@alarbus.oz.au
Organization: Sun Microsystems, Inc.
Date: Fri, 18 Dec 1992 00:01:03 GMT

Is there an international standard for numbering weeks.

Some 1993 diaries have the week with Mon 4th Jan as week
1 and otheres have it as week 2.

Is this different in different countries ???

---
regards,

Andrew Reye.

 _____________________________________________________________________________
| 	                  TELECOM  AUSTRALIA             	  |           |
|_________________________________________________________________|   /-_|\   |
| Email:andrew@nmpd.oz.au| Snailmail: Telecom Australia	  	  |  /     *  |
| Phone: +61 7 837 5074  | Network Management Protocol Development|  \_,-._/  |
| Fax:   +61 7 837 5253  | 14/151 Roma St, Brisbane Q. 4003 	  |       v   |
|________________________|_AUSTRALIA______________________________|___________|
|X.400:/C=AU/ADMD=TELEMEMO/PRMD=TELECOM011/O=TELECOM/OU=NMPD/PN=ANDREW.REYE/  |
|_____________________________________________________________________________|


Xref: sparky comp.std.internat:869 news.admin.misc:781
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 15 Dec 1992 02:47:55 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net

In article <id.6AUV.IAA@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Dec13.100023.7056@clarinet.com> brad@clarinet.com (Brad Templeton) writes:
>> We're not running the same sort of net any more.  So many links are tcp/ip
>> now.
>
>That's the problem. UUCP is 8-bit clean. It's TCP/IP that's most likely
>to trash articles.

C'mon. TCP/IP *is* 8-bit clean AS DESIGNED. The problem is in the
stupid (c & 0177) people add to their programs for absolutely no
reason (except for wish to be "compatible" with RFC822). Fix your
sendmail and you'll get all 8 bits NOW. (BTW, EUnet already is
8-bit clean).  The only brute force action necessary is to declare
that 7 bits is no longer considered "standard".

--vadim

"Many hideous crimes were committed in the name of backward compatibility".
					(Forgot where i saw it)
Xref: sparky comp.std.internat:863 news.admin.misc:772
From: ckd@eff.org (Christopher Davis)
Subject: Re: 8-bit news
Organization: Electronic Frontier Foundation Tech Central
Date: Tue, 15 Dec 1992 21:17:50 GMT

RA> == atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
KK> == Kosta Kostis <kosta@blues.kk.sub.org>

 KK> Well, we don't have an 8-bit clean Internet yet, but I think we should
 KK> be working on instead of crying it can't be done. It can be done, and
 KK> should it take some time, so what.

So we should do it with a backward-compatible protocol extension, not "send
8 bits and pray".  Or should we "fix" SMTP so that it sends the message
even if there's nothing listening on port 25? :)

 RA> I *KNOW* of at least 3 systems (combinations of OS + hardware) that
 RA> will flat out crash if offered certain fairly common 8-bit
 RA> ISO-8859-like characters.  I'm not going to say which ones in public
 RA> because some lurker would go and use this to crash someone else's
 RA> machine maliciously.

 KK> I have never said one can do that *without* changing some software
 KK> at some places. So, what's the "nonsense" in here?

The "nonsense" is assuming that "just sending 8 bits" will work in the face
of these software issues.  There are three ways to send 8-bit email through
SMTP:

1) make agreements to "just send 8 bits".  Works within an enclave.

2) extend SMTP in some way to be guaranteed 8-bit compatible.

3) "just send it and hope it gets there okay."

The problem is that (1) tends to generalize into (3)...where the real
solution is (2).

Similar arguments apply to NNTP, since it's a traditional "TCP stream in
NETASCII" type protocol.

I'm certainly not insensitive to the needs of languages that don't fit in
USASCII.  However, I'm also not insensitive to the needs of sites that
could care less about 8-bit characters, have vendor-supplied software that
blows up on 8-bit data, and aren't prepared to upgrade immediately.

As soon as there's a compatible SMTP extension for 8 bits, I'll at least
try to hack it into my mailer (assuming the UIUC IDA sendmail folks don't
beat me to it).  But I won't install anything that tries to pull a Nike and
"Just Do It" to some unsuspecting mailer somewhere.
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>
Xref: sparky comp.std.internat:840 news.admin.misc:740
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 14 Dec 92 22:56:16 GMT
Organization: Xenix Support, FICC

In article <th0efeo@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> What Henry wrote was literally true.  "There is no way to mandate
> updates."

It's also as pointless as "RFC822 will never be changed". If enough people
simply start using ISO8859.1 or NET-UTF for casual mail, enough systems
will be forced to upgrade that the remaining bogons can simply be ignored.

When was the last time you saw a line eater?
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
Newsgroups: comp.std.internat,news.admin.misc
From: ckd@eff.org (Christopher Davis)
Subject: Re: 8-bit news
Organization: Electronic Frontier Foundation Tech Central
	<CKD.92Dec15161747@loiosh.eff.org> <1glp8dINN4sc@rodan.UU.NET>
Date: Tue, 15 Dec 1992 23:59:05 GMT

VA> == Vadim Antonov <avg@rodan.UU.NET>

 VA> "Just send 8 bits" is the proper superset of "just send 7 bits"
 VA> -- exactly the same as adding new header fields. It breaks nothing
 VA> as long as you do not use extensions.

Not if the standard specifies 7-bit NETASCII.  Most header standards
(certainly '822 and '1036) allow for user-defined and future headers.  (If
I put X- in front of all my 8-bit data, does that work? :)

 ckd> I'm certainly not insensitive to the needs of languages that don't
 ckd> fit in USASCII.  However, I'm also not insensitive to the needs of
 ckd> sites that could care less about 8-bit characters, have
 ckd> vendor-supplied software that blows up on 8-bit data, and aren't
 ckd> prepared to upgrade immediately.

 VA> If the vendor-software crashes on, say, a file with 1025-byte line
 VA> it's a bug, isn't it? If a program craches on ANYTHING it's a bug.  A
 VA> bug is a bug is a bug. Call their tech support and have them to fix
 VA> it.

And if the standard says "<protocol> data is 7-bit NETASCII." and something
claiming to be doing that protocol sends 8-bit ISO-8859-1 data, that's a
bug too.  Sure, the software *should* gracefully deal with it in an
implementation-defined manner (since the standards currently don't cover
the situation).  To stretch a point, dumping core could be considered an
implementation-dependent behavior :)

 ckd> As soon as there's a compatible SMTP extension for 8 bits, I'll at
 ckd> least try to hack it into my mailer (assuming the UIUC IDA sendmail
 ckd> folks don't beat me to it).

 VA> "Just send 8 bits" *is* backward compatible. Check your logic.

It's not backward compatible, because the standard says 7 bits, and some
software will enforce that (either by clipping the 8th bit, or dumping
core).  If I get "550 EMAL: command unrecognized" and then convert the body
to quoted-printable, that's backward compatible.  If I get "Connection
closed" and try it again every half hour (generating a core dump each
time), that's not.

 ckd> But I won't install anything that tries to pull a Nike and
 ckd> "Just Do It" to some unsuspecting mailer somewhere.

 VA> Then why on the Earth did you upgrade your software the last time?

Because it gave me better configuration flexibility than the old version,
and was more robust, and followed the SMTP standard.
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>
From: keld@login.dkuug.dk (Keld J|rn Simonsen)
Subject: Re: 8-bit representation, plus an X problem
Keywords: ISO8859-1 CP850 fidonet gateway
Organization: DKnet
Date: Thu, 17 Dec 1992 09:16:51 GMT

unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) writes:

>Will there be other ISO standards (e.g. POSIX, etc.) that define
>precisely how to handle the numbers defined by ISO 10646? The Plan 9
>stuff seems to be very promising.

POSIX .2b is planned to include the Plan9/XOpen encoding of 10646.
Here the UTF2 encoding will be normatively defined by ISO.

Keld
Xref: sparky comp.std.internat:813 news.admin.misc:702
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 16-bit news
Summary: plan 9 utf details
Date: 11 Dec 92 21:47:14 GMT
Article-I.D.: alice.24388
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Dec9.202955.4809@HQ.Ileaf.COM>, walters@HQ.Ileaf.COM (Tim Walters) writes:
> For those of us not attending Usenix, would it be possible to get a
> brief description of the difference between fss-utf and utf? Or is
> there an ftp-able description somewhere?
> -- 
> Tim Walters, Interleaf          uunet!leafusa!walters, walters@HQ.Ileaf.com


	I have made available a package of the plan 9 utf related
manual pages on netlib. there is an ascii and postscript version
(utfman.asc and utfman.ps) in the directory research/memo.
that's all you nee dto know for netlib; for ftp, login
into research.att.com as netlib.

for a quick idea, i quote the man page:

          Letting numbers be binary, a rune x is converted to a multi-
          byte UTF sequence as follows:

          01. x in [00000000.0bbbbbbb] b 0bbbbbbb
          10. x in [00000bbb.bbbbbbbb] b 110bbbbb, 10bbbbbb
          11. x in [bbbbbbbb.bbbbbbbb] b 1110bbbb, 10bbbbbb, 10bbbbbb

          Conversion 01 provides a one-byte sequence that spans the
          ASCII character set in a compatible way.  Conversions 10 and
          11 represent higher-valued characters as sequences of two or
          three bytes with the high bit set.  Plan 9 does not support
          the 4, 5, and 6 byte sequences proposed by X-Open.  When
          there are multiple ways to encode a value, for example rune
          0, the shortest encoding is used.


andrew
Xref: sparky comp.std.internat:816 news.admin.misc:705
From: kosta@blues.kk.sub.org (Kosta Kostis)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit representation, plus an X problem
Date: Sat, 12 Dec 92 11:13:07 MET
Organization: The Blues Family

peter@ferranti.com (peter da silva) writes:

> In article <1992Dec7.184546.11068@osf.org> dbrooks@osf.org (David Brooks) wri
> > A significant and growing number of people are using 8859/1 already,
> 
> Another problem is people using *IBM-PC* 8-bit characters, *in headers*.

Yuk! Allthough I'm sitting in front of an IBM PC clone using
IBM Code Page 850, I would never think of bothering the rest 
of the world with characters between 128 and 159. That's why
I convert between CP850 and ISO 8859-1.

> This is common, apparently, in Fido. There is a character in Houston who
> has been using the name "(R<e dieresis><centered dot>gan)@???.fidonet.org",
> using the PC encoding. I think that involves characters *outside* the G0
> and G1 sets, too.

Right. Who maintains the fidonet/usenet gateway software?
I'd love to send him/her two nice conversion tables from/to
ISO 8859-1.

        Kosta

-- 
  Kosta Kostis, Talstrasse 25, D-6074 Roedermark 3, Germany
  kosta@blues.kk.sub.org                                        (home)
  kostis@frsmic.enet.dec.com                                    (work)
  sw authors: please support ISO 8859-1!        =aeoeueAEOEUEss
Xref: sparky comp.std.internat:909 news.admin.misc:843
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit representation, plus an X problem
Date: 18 Dec 1992 19:39:59 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
Keywords: ISO8859-1 CP850 fidonet gateway

glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:

>I find it extremely doubtful that it "will be normatively defined."
>Especially, since UTF-1 is only an informative annex.  I would expect
>other UTF-* to also be informative, and not normative.

>Of course, a usage profile might wish to make it normative, but that would be
>outside the scope of 10646.

Ok, ISO 10646 defines only a table that assigns characters to numbers.
But why don't you start to develop a new normative ISO standard that
defines UTF-2? This will be a very useful ISO standard. Call it
"Single and multiple octett encoding of UCS compatible with ISO 646 IRV"
or give it a similar ISO typical title and start the process.
I believe that many people are waiting on a standard that defines what
will be the future replacement of ASCII text files. UTF-2 seems to
be promising, so why not making an ISO standard? Do all ISO standards
(e.g. ISO 2022) have to be complex and difficult to implement? :-)

This standard could also define for all times the problem of the end of
line control codes: LF or CR LF or only CR or NL or any of the new
Unicode codes?

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----
Newsgroups: comp.std.internat,news.admin.misc