HDTenEightyP/NetNews huggingface dataset:
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: 8-bit news
Keywords: ISO8859 ISO10646 8bit
Organization: Naval Research Laboratory, DC
Date: Mon, 14 Dec 1992 16:16:50 GMT

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

>> "Just send 8-bit email" does not work reliably now and never will.

>I've been listening to this "tale" very often...  ;-)
>I still know it not true.   =;^)

Nonsense.  

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

>This is your view. I've been told things like that in Germany, too
>regarding 8-bit clean news paths, and it was simply untrue. Admins
>have been very cooperative and after only a few months the major
>"toublemakers" were 8-bit clean.

  Some NNTP sites are 8-bit now, many will migrate to 8-bit
eventually, some cannot migrate to 8-bit because of limitations of
OS/hardware or the age of the system.

>Right. I'd prefer not to talk to much but do *implement* 8-bit clean
>paths everywhere. It is much easier than most pessimistic people try
>to make us believe. Still it's a lot of work, though...

  There are TWO issues here.  

  One is to implement wider bit transport which is nice and is useful
but is NOT necessary in a strict sense and is certainly not sufficient
(one still needs to know WHICH 8-bit or 16-bit character set was used
by the author).

  The second is to have a standard for marking the contents of
messages in standard headers using standard syntax and standard
tokens.  If I understand Henry correctly, he is putting together a
draft, based on MIME, that addresses this second issue.

Ran
atkinson@itd.nrl.navy.mil
Xref: sparky comp.std.internat:825 news.admin.misc:719
From: anselmo@nic.near.net (Ed Anselmo)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 13 Dec 92 17:49:25 GMT
Article-I.D.: nic.1gft35INN771
	<Bz6F6z.DvK@zoo.toronto.edu> <1992Dec13.100023.7056@clarinet.com>
Organization: NEARnet, Cambridge, MA
NNTP-Posting-Host: nic.near.net
In-reply-to: brad@clarinet.com's message of Sun, 13 Dec 1992 10:00:23 GMT

>>>>> In article <1992Dec13.100023.7056@clarinet.com>,
>>>>> brad@clarinet.com (Brad Templeton) writes:

Brad> For things like rich text, non-ASCII characters, I agree that
Brad> using encodings that fit into ASCII is a good idea.

Brad> However, when it comes to graphics and other binary information
Brad> in multimedia news articles, I find this to be too much of a
Brad> kludge in the service of old software.

Where does MIME say that you have to use a 7-bit encoding?  If you
look in RFC 1341, you'll see that MIME doesn't preclude the use of
8-bit clean transports.

With graphics/sound/smell (name your favorite multimedia thingy), you
still have to encode content-type, just like you do with richtext and
non-ascii characters.  MIME provides a way to do this.
Newsgroups: comp.std.internat,news.admin.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: 8-bit news
Organization: York University
Date: Wed, 16 Dec 1992 03:23:25 GMT

ckd@eff.org (Christopher Davis) quotes:
|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>

  In this case, I suspect the initiatives of our german cousins may 
make the larger problem of inappropriately-unencoded email easier:
The few programs which make up news transport will drop lots of
mailable 8-bit data into peoples's hands.
  We then watch german mailers crash and burn until we find out which
configurations/sites need to run their mail through a &07f sendmail
on their mailhub.

  This technique is know sarcastically as ``Canadian Political
Policy'': we get half the problems the Americans suffer from, three
years later.
  It's a real advantage to have someone else do a prototype for you.

  In the meantime, I'm running zmailer and mime, and watching out for
8-bit logic missles

--dave (:-)) c-b
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.
Newsgroups: comp.std.internat,news.admin.misc
From: win@in.rhein-main.de (Winfried Koenig)
Subject: Re: 8-bit representation, plus an X problem
Content-Type: text/plain; charset=ISO-8859-1
Organization: Individual Network, Rhein-Main
Date: Wed, 16 Dec 1992 20:16:53 GMT
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Keywords: ISO8859-1 CP850 fidonet gateway

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

>Most amusingly, US-ASCII does not even cover English.
>E.g. look at rle in your dictionary. :-)

And nave people don't know that they can find
the word navet in their dictionary.

Winfried

-- 
Winfried Knig         win@in.rhein-main.de
Arendsstrasse 12       win@in.sub.org
6050 Offenbach         +49 69 868707
Germany
Xref: sparky comp.std.internat:878 news.admin.misc:801
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit representation, plus an X problem
Keywords: ISO8859-1 CP850 fidonet gateway
Date: 16 Dec 92 21:57:07 GMT
Organization: Naval Research Laboratory, DC

I have also heard reports that the Plan 9 encoding of ISO-10646 will
be included in the final draft of ISO-10646 (which is rumoured to be
out next month maybe).  The AT&T Plan 9 encoding sounds like the most
promising approach to me.  I think there are plenty of problems to
address in news right now so that we can afford to wait a few weeks to
address ISO-10646 after it is published in final form.
Newsgroups: comp.std.internat,news.admin.misc
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: 8-bit news
Organization: Naval Research Laboratory, DC
Date: Wed, 16 Dec 1992 01:10:59 GMT

In article <BzBpxG.D93@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

> The one thing that needs careful thought is adapting news to use of
> RFC-1342 for encoding non-ASCII stuff in *headers*.

Agreed.

>  The MIME (RFC-1341) facilities for use in the *body*, for stating
> which character set you are using and encoding >7-bit sets to survive
> 7-bit transmission channels, appear to be directly applicable without
> modification.  I'm debating how much detail to include about them in
> the draft, but the bottom line will be "see MIME".  Almost everything
> in MIME has potential applications to news, and I don't see any
> compelling reason to re-invent or re-specify it.

Sounds good.  

  There might be some legitimate room to address the question of which
character sets are "preferred" for use in articles while being
transported between sites.  There will be more long-term
interoperability if the "preferred" transport character set(s) are
minimised.

  In MIME, the intent was to encourage use of ISO-8859-* and ISO-10646
over all else for longer term interoperability reasons.  In the short
term, it was recognised that other existing practices (e.g. VISCII,
ISO-2022-JP, -KR) would also be used within some communities until 
better alternatives came along.

  The character set used for transport need not be native to the
machine used to display the article.  It only needs to be translatable
to some character set on the system.  X11-based news readers will be
especially able to display multilingual text and images, but even
other devices can probably display correctly using other mechanisms
(e.g. PCs can switch code pages or use MS-Windows or whatever).

Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.std.internat,news.admin.misc
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 14 Dec 92 23:00:53 GMT
Organization: Xenix Support, FICC

In article <Bz6F6z.DvK@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
> While 8-bit-clean transmission paths are nice, there is no need to wait
> for them or rely on them.

The same is true of MIME. I'm still supporting systems that will never be
able to run any MIME mail readers unless they're written by Henry Spencer
or someone else with a clue about how to write portable code.

While MIME is nice, there is no need to wait for or depend on it.

> We can start using 8-bit character sets (note plural) now,

We can start using NET-UTF now,

> and have our
> readers show us what was really meant -- or the closest approximation
> our terminals can display --

and have our terminals display a close approximation to the desired text

> without waiting for 8-bit links, or 8-bit
> terminals, or universal agreement on a single 8-bit character set.

without waiting for new mail readers.

Ragging on NASA again, Henry?
-- 
%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,soc.culture.nordic,soc.culture.german
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit representation, plus an X problem
Summary: lets not get carried away here
Date: 17 Dec 92 16:01:33 GMT
Article-I.D.: alice.24433
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1gpruaINNhfm@frigate.doc.ic.ac.uk>, rap@news (Ross Paterson) writes:
> It's hard to imagine that FSS-UTF will be popular with users of those
> alphabets (all originating in Asia, BTW) whose letters are going to
> take up 3 bytes, while they take up 2 in UTF-1 and 7 bits or so in
> existing standards.


	i wish folks would just come out and say the character sets they mean.
if you mean kanji (shift-jis), or chinese (GB2312-80 or Big 5), or korean,
then the existing practice is two bytes per character.

	UTF-1 does #00-#9f in one byte, #a0-#4015 in two bytes, and #4106-#ffff
in three bytes. FSS-UTF does #00-#7f in one byte, #80-#7ff in two bytes and
#800-#ffff in three bytes. given the unified han characters now start at #4e00,
i'd say FSS-UTF and UTF-1 had pretty much the same performance here.

	certainly, the characters between #800 and #4015 will take 50% more
space in FSS-UTF than UTF-1. from our file command (which guesses at languages),
this would seem to include Devanagari, Bengali, Gurmukhi, Gujarati, Oriya,
Tamil, Telugu, Kannada, Malayalam, Thai, Lao, Tibetan, Georgian,
Japanese (hiragana etc), chinese (some) and korean. (with the exceptions
of the CJK scripts and perhaps georgian, there is no measureable email
traffic in these scripts.)

 	and even for these scripts, i would guess connectivity (in the sense
of being able to send/receive messages at all) matters more to those folks
than the increase in space (how much of your disk is mail?) or decrease in
bandwidth (in most messages i see, headers are 30-50% of the message).

	in any case, i agree there is a space overhead. its up to users
to figure out if its worth it; i just wanted to clear up factual errors.


			andrew
Xref: sparky comp.std.internat:899 soc.culture.iranian:11018
From: mammad@parsis.com (Mammad Zadeh)
Newsgroups: comp.std.internat,soc.culture.iranian
Subject: A Persian GUI Toolkit
Keywords: Persian, Farsi, internationalization, GUI, OpenLook
Date: 18 Dec 92 02:00:52 GMT
Organization: Parsis, Inc.


Those of you who are interested in obtaining a copy of the following
paper on a Persian GUI toolkit, please contact me directly at:

        e-mail: mammad@parsis.com
        or:     Mammad Zadeh
                Parsis, Inc.
                1736 Franklin St., Suite B
                Santa Monica, CA 90404
                (310) 917-2650

This paper can be sent to you electronically in PostScript format, or
you may request a hardcopy version.



         A Persian Graphical User Interface Toolkit

                        Saied Kazemi
                      Mammad M. Zadeh
                        Parsis, Inc.

                     December 17, 1992


                          ABSTRACT


     Availability of  computers  to  a   large   number   of
non-technical users  during  the last decade has resulted in
an ever  increasing  demand   for   user-friendly    systems
and  software.   The  pioneering  work  of Xerox Corporation
on a Graphical User Interface (GUI) has become a  tool   for
many system manufacturers to build intuitive and easy-to-use
GUIs for users  with  a   broad   diversity   of   technical
skills.   Today,   personal   computers,   workstations  and
departmental systems offer at least  one  flavor  of  a  GUI
toolkit.   Virtually all  of the toolkits in the market have
been initially written for the English  language.   A  small
number   of   elements in  any toolkit are language indepen-
dent because they are based on graphical  images.   However,
most  of  a  toolkit's  elements  read  or  write  text  and
are therefore  language  dependent.   There  has  been  much
effort   to   internationalize  GUI   toolkits   and   major
advancements  have  been  made to address the needs of Euro-
pean   and   far  eastern  languages.  But so far, a Persian
GUI toolkit based on a standard ``look and feel'' technology
has  not  been  available.

     In  this paper,  we  will  present  a  complete  object
oriented  Persian  toolkit  for  the  X  Window System  that
implements  the  OPEN LOOK specification.
Xref: sparky comp.std.internat:902 news.admin.misc:836
From: mbs@adastra.cvl.va.us (Michael B. Smith)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Distribution: world
X-NewsSoftware: GRn-beta 1.16g (10.12.92) by Michael B. Smith & Mike Schwartz
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 18 Dec 92 06:50:47 EDT
Organization: Well, I haven't decided on a name yet...

In article <id.QCXV.K14@ferranti.com> peter@ferranti.com (peter da silva) writes:
> Unfortunately, some UUCP links use dirty mail software, like sendmail.
> Fortunately, there are few if any UUCP links that can't easily upgrade
> to one of the 8-bit-clean routing agents.

I wouldn't go that far.

There are lots of us folks out here that don't run Unix, and our choices of
routing and transport agents are VERY limited. I know that what I use as a
sendmail-equivalent isn't 8-bit clean and without a massive investment in
time and energy, that isn't going to change any time soon....
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us  -or-  uunet.uu.net!virginia.edu!adastra!mbs
Newsgroups: comp.std.internat,news.admin.misc
From: dhd@exnet.co.uk (Damon)
Subject: Re: 8-bit news
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sat, 12 Dec 1992 23:44:48 GMT

In article <th0efeo@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>problems in products that I worked on years ago.  Most people just do
>not think upgrading a systems that works well enough for them is a good
>use of their time.  People who to try to force them to upgrade their
>systems are either ignored or castigated.  That may not be sensible or
>convenient, but it is a fact.

If it's not broke don't fix it...

I might be getting old to say that, and I don't always follow it (B^>),
but there are oh so many things to do in life, and oh so many things
that are genuinely and clearly broken and in need of fixing, that
`fixing' 7-bit paths when MIME is said to make their presence
unimportant...

Remember, 7-bit paths are not broken for US English, the language of
the owners of much of the equipment in question.

Ie, if MIME is an end-to-end fix which doesn't bother intermediaries
and does solve the problems, why chose a method that *does* bother the
intermediaries?

I say this with no strong feelings either way except that if there is a
way for *me* to avoid spending another n-hour session with my mailer,
I'll prefer that solution.

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Newsgroups: comp.std.internat,news.admin.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: 8-bit news
Organization: Xenix Support, FICC
Date: Thu, 17 Dec 1992 21:03:35 GMT

In article <CKD.92Dec15000326@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
> That's not the problem.  TCP is 8-bit clean.  It's NNTP that's most likely
> to trash articles.  :)

OK, "uuxqt and rnews and newsrun are 8-bit clean, it's NNTP that's likely to
trash articles".

Better?

The point is that pointing fingers at UUCP links is pointless. It's the
TCP/IP links that are the problem. Because the application layer used
in TCP/IP news and mail links is not 8-bit clean.

Unfortunately, some UUCP links use dirty mail software, like sendmail.
Fortunately, there are few if any UUCP links that can't easily upgrade
to one of the 8-bit-clean routing agents.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.std.internat,news.admin.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: 8-bit news
Organization: York University
Date: Fri, 18 Dec 1992 13:24:24 GMT

avg@rodan.UU.NET (Vadim Antonov) writes:
|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).

  SAML and SOML are underused on the internet, yet the equivalent
on BITnet is heavily used....
  Don't take them out of the spec: you may want them later,and a standard
way of doing them is desirable.

  VRFY is utterly necessary to postmasters, and is therefor mandated by the
Hosts Requirements RFC: finger is shut down on all too many sites, and so
vrfy/expn are required to verify adressees when mail goes astray.

  And HELO is the hook for stronger authentication: even now it and thge
recieved lines allow me to spot (poorly-)forged mail at a glance.

(small flame)  If you've implemented smtp, you should really know all that...

--dave
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.
Newsgroups: comp.std.internat,news.admin.misc
From: "David Herron" <david@twg.com>
Subject: Re: 8-bit news
Sensitivity: Personal
Encoding:  21 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Tue, 15 Dec 1992 18:45:16 GMT

brad@clarinet.com (Brad Templeton) writes:
> I say, let such articles break on machines with old software.
...
>	b) If you're a truly major node, one of the top 100 on Brian's
>	graph, you had better have 8 bit clean news software.  But there
>	are only a small number of you, so we can manage it.

Okay .. hmmm.. "who elected him ghod anyway...?" ;-) ;-)

Seriously it is not a good idea to break existing things.  It's bad karma
and all that (I can say "bad karma" now that I live in California ... ).

Please, don't "just send 8" .. this has been hashed around on the IETF-SMTP
mailing list many times and there are occasions where it will break.  For
instance if a character happens to look like `.' when you strip it down
to 7 bits ..

I expect "just send 8" will work most of the time but will occasionally break,
and that's unacceptable.

What happened to the NNTPv2 work that Eliot was doing?

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
Newsgroups: comp.std.internat
From: eric@giga.mks.com (Eric Gisin)
Subject: Summary of the 8 bit problem
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Wed, 16 Dec 1992 22:27:35 GMT

I think I understand what the problems are,
but I haven't seen a summary of what the solutions are.

I see two completly different problems, in points 2 and 3.

1. The low level transports.
UUCP, TCP, and ISO protocols are 8 bit. No problem here.

2. The high level transports.
SMTP is 7 bit, but there is a replacement.
But, even with a replacement, we have to deal with old software.

So the problem is encoding 8 bit data to deal with 7 bit gateways.
We do not have to deal the particular character sets
or with multi-byte encodings at this level.

How does MIME or other solutions deal with this?

3. The applications.
Applications have to be aware of the character set and encoding.
The simplest solution is to handle just the ISO 8859-1 character set.
This should be no problem with most modern software and hardware.
This can be called the "western european solution".

The second best solution is to handle all of the ISO 8859-# character sets.
The problem here is displaying the right character set,
and having all the fonts in hardware or software.
Not having all the fonts might be a problem for many people.
This can be called the "indo-european solution".

Any programmer can pick up some good books and implement most of this.
The two things that are poorly documented (or non-portable)
are locale naming conventions and selecting display fonts.

The best solution is to have full support for multi-byte character sets.
I think this is much more difficult than the previous solution,
because of the lack of library support for developing such applications.

How does MIME or other solutions deal with these problems?

		Eric Gisin, Mortice Kern Systems.
Xref: sparky comp.std.internat:914 news.admin.misc:861