HDTenEightyP/NetNews huggingface dataset:
From: jav@mccall.com
Newsgroups: comp.mail.uucp
Subject: Looking for a feed in So. Cal.
Date: 12 Jan 93 12:07:34 GMT
Organization: The McCall Pattern Co., Manhattan, KS, USA

Hello,

I'm looking for a site willing to feed us news and mail, in the Ventura,
California, area (I can't restrict distribution of this posting to Southern
Cal., my apologies to the rest of the world).

Willing to do all the calling. If you're able to help, please contact me
at the address below.

Thanks,

Jav
jav@mccall.com
From: trsnyder@mcs.drexel.edu (Bob Snyder)
Newsgroups: comp.mail.uucp
Subject: Re: Top level domains (was Re: Mixed format addresses)
Date: 4 Jan 93 19:50:21 GMT
	<+j4NrAsCBh107h@boombox.apana.org.au>
	<930101.040025.7n1.rusnews.w165w@ricksys.lonestar.org>
	<0QvRrAPBBh107h@boombox.apana.org.au>
Organization: ASCI

In article <0QvRrAPBBh107h@boombox.apana.org.au> djk@boombox.apana.org.au (David Keegel) writes:

   Because (f'r instance) .GOV ought to either mean "Governments of some
   kind, all over the world" or "World governments".  Well, that's what
   seems logical to me, anyway.

Seems logical to me too.

   Now tell me, would the US Govt be happy to have the Australian Bureau
   of Statistics being called "abs.gov"?  Or does the US Govt claim to
   govern the world?

Not that I've heard recently; although we do reserve the right to kidnap
foriegn citizen (which is stupid, and a debate that belongs in another
newsgroup).  I don't believe there would be a problem with abs.gov; I recall
a discussion quite some time ago that used "kgb.gov" as it's example.  The
eventual outcome was that it wouldn't be a problem.

   Philosophicaly, I think the USA would look a lot less arrogant to the
   rest of The Net if its govt depts/agencies were in gov.us or us.gov.
   IMHO, the only govt with a right to be at the top level of .gov would
   be the UN (unless they want to allow all comers).

This is your opinion on how the net should be.  Not everyone agrees. Actually,
I would probably argue that the UN is a organization, and falls under .org,
but.....

Bob
Xref: sparky comp.mail.uucp:2556 can.uucp:270
From: terry@gtm-inc.com (Terry Gerritsen)
Newsgroups: comp.mail.uucp,can.uucp
Subject: Looking for FQDN for Ford Motor Company
Date: Tue, 12 Jan 93 17:46:33 EST
Reply-To: terry@gtm-inc.com (Terry Gerritsen)
Distribution: can
Organization: G.T.M. Incorporated, Kingston, ON (613) 546-3078
Content-Type: Text

Please help me find the FQDN for Ford Motor Company in Oakville
Ontario. The person I am trying yo reach is Reg Rea, I believe in
the Paint Section.
Please respond via E-mail.

---------------------------------------------------------------------------
Terry A. Gerritsen         |  G.T.M. Incorporated              (613) 384 0162
Transportation Consultant  |  Kingston, Ontario           Fax: (613) 389 4594
Air/Rail/Road         "Transportation is our business"
----------------------------------------------------------------------------
From: kosta@blues.kk.sub.org (Kosta Kostis)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Summary: Why not extra mail headers?
Date: 10 Jan 93 21:31:55 GMT
Organization: The Blues Family

ag129@cus.cam.ac.uk (Alasdair Grant) writes:

> Is there any convention for transmitting MIME messages if extra
> mail headers (Content-Type etc.) cannot be used for one reason or
> another?  Do any mailers understand messages whose first (text) line
> begins "MIME-Version..." or something?

The MIME-headers should be in the headers only.

Well, "my ideal" MTA would only analyse the headers of a message
needed for routing (if at all), transfer everything without changing
any bit (except adding "Received"-lines perhaps) and forward the
message to next next MTA on the way to the receipient.

It's the MUA's job to interpret the content of the message, only,
but the MUA must know about the encoding used and stuff like that.

RFC 821 explicitly forces you to cut the MSB, so SMTP MTAs fully
conforming to RFC 821 will not be able to transfer binary or even
8bit data. Quoted-printables and base64 may be transmitted without
any problems, but you'll have to tell your MUA manually to convert
the message, if at all possible. It's like using uuencode/uudecode.

What's your problem changing header lines? Maybe we can help you to
do this somehow.

        Kosta


-- 
  Kosta Kostis, Talstrasse 25, D-6074 Roedermark 3, Germany
  kosta@blues.kk.sub.org                                        (home)
  sw authors: please support ISO 8859-x!      dv|DV\_ = aeoeueAEOEUEss
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.mime
Subject: Assigned content & application types etc.?
Date: 8 Jan 93 19:06:58 GMT
Organization: U of Cambridge, England


Since the latest assigned numbers RFC predates MIME, is the latest list
of registrations (especially application subtypes) available anywhere?
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 9 Jan 93 20:18:13 GMT
Distribution: na,uk
Organization: U of Cambridge, England

In article <C0LnHt.C9J@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>files via "binary" mode ftp transfer.  I would not consider it
>desirable to have an ftp that looked inside the bits it was moving
>around (personal opinion).

No, this is not appropriate for the File Transfer Protocol; however, it
may well be appropriate for a file transfer client.  I already have a
shell script around FTP that does "uncompress" and "tar -xf" if the name
ends in .tar or .Z; luckily, this is possible because people conventionally
use these filenames (the FTP does not provide any useful information).
An FTP client could similarly recognise MIME files, but nobody is going
to use filenames like

   myfile.MIME-Content-Type:application/foobar

so the information will have to be conveyed by some eyecatcher in the file.
Perhaps a filename  myfile.MIME  would indicate that the first few lines
of the file (until a blank line) were in fact "headers".

But even this is not enough - one has to say whether .MIME files are text
or binary.  If an EBCDIC machine FTPs a .MIME file in binary mode, it must
assume the headers are in ASCII.  And if an EBCDIC machine provides a .MIME
file for anonymous FTP, it must use ASCII for the headers even if the data
is readable (EBCDIC) text.  Alternatively, you could say that .MIME files
are readable text using BASE64 etc. if necessary.  Or have .MIMEB and .MIMET
files.  Why not put MIMEB and MIMET into FTP, along with ASCII, BINARY and
EBCDIC?

Similarly, one could argue about how to annotate files that are sent to
a print server (via LPR, not SMTP).  Why shouldn't print servers be MIME-
capable?  Some already automatically detect the difference between text
and PostScript based on the file starting '%!PS-Adobe'. How are they
supposed to detect MIME?
From: de19@umail.umd.edu (Dana S Emery)
Newsgroups: comp.mail.mime
Subject: digest/archive site?
Date: 6 Jan 93 00:48:19 GMT
Followup-To: comp.mail.mime
Organization: personal

As luck would have it, the University of Maryland didnt pick up this
newsgroup [C.M.Mime] untill quite recently, and I have missed a lot of
traffic.

Is there an ftp'able archive/digest site any where? 
--

Dana S Emery <de19@umail.umd.edu>
Newsgroups: comp.mail.mime
From: tandle@flipper.pvv.unit.no (Morten Tandle)
Subject: Re: Looking for sh version of showexternal
Organization: Norwegian Institute of Technology
Date: Tue, 5 Jan 93 10:04:36 GMT

In article <C0D6yv.92z@pandora.sf.ca.us> mitra@pandora.sf.ca.us (Mitra) writes:
>Does anyone have a /bin/sh version of showexternal, the new (2.4)
>version distributed with metamail has numerous problems running under
>SCO Unix, and hacking a bin/sh version is much more likely to be
>successfull 

 This is a metamail FAQ.

 In mm2.4, there are contributed sh versions of the metamail scripts
in the 'contrib' distribution. (contrib2.4.tar.Z).
 I wonder why they are not the standard, given the disastrous state of
csh ?

 -Morten




-- 
         ___________________________________________________________
           Morten Tandle                        tandle@pvv.unit.no
               Computer Science/Telematics, NTH - UNIT, Norway
                           <MIME-mail welcomed>
Newsgroups: comp.mail.mime
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: Using MIME without extra mail headers
Organization: Naval Research Laboratory, DC
Distribution: na,uk
Date: Sat, 9 Jan 1993 18:32:16 GMT


In article <C0LA9I.9AB@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>MIME works fine as is with gopher.  I can't imagine a reason why it
>wouldn't work fine with ftp as well.  There is serious discussion of
>adding MIME to USENET news as a new enhanced article format.

In article <1993Jan9.143137.29608@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:

%   Forgive me for being stupid, but MIME states that certain
% information necessary for unpicking the text should be carried in
% message headers by the use of new header fields.  FTP does not have a
% concept of message (or file) headers.  If it does "work" with FTP
% (e.g. to allow the correct transmission of mixed text/binary files
% between systems with different character codes, which is one
% application I have in mind) it does so by some method not described in
% RFC 1341.  

Ah, I didn't follow your ftp thinking fully.  ftp indeed cares not
about anything internal to the file it is moving and it should never
ever look inside a file.  Normally one can safely move mixed content
files via "binary" mode ftp transfer.  I would not consider it
desirable to have an ftp that looked inside the bits it was moving
around (personal opinion).

Ran
atkinson@itd.nrl.navy.mil

Newsgroups: comp.mail.mime
From: brsmith@duncan.cs.umn.edu (Brian R. Smith)
Subject: Re: MIME in NEWS?
Organization: University of Minnesota
Distribution: comp
Date: Mon, 11 Jan 1993 19:43:16 GMT

In <1993Jan11.081251.19255@xenitec.on.ca> vances@xenitec.on.ca (Vance Shipley) writes:

>In article <DAVIDM.93Jan10225930@consilium.com> davidm@consilium.com (David S. Masterson) writes:
>>Since the talk has strayed into rich text in news reading, I'd like to ask
>>about all those people who read the news via dialups to a main system.  Rich
>>text is going to make it very hard for these people to read the news.  Is
>>anyone considering this (ie. is rich text still readable if you don't have a
>>rich text reader)?

>Dialup has nothing to do with it at all.

This is true enough.  I use a PowerBook with SLIP, telnet, and X server
via a dialup.  Multimedia news is not a problem.

What I think Mr. Masterson was referring to was people reading news via
dumb terminals/emulators/etc.  They're not going to have access to
graphics, sound, etc.  Even if RichText is readable on dumb terminals,
they won't *gain* anything from MIME additions to news, and, indeed,
they'll lose portions of articles that can't be displayed on dumb
terminals.

But, then, my response to that is: "So what?"  Folks with printing
terminals are inconvenienced by full-screen editors.  300 baud modems
aren't supported on many dialups nowdays either.  If dumb terminals are
finally dead (not yet, admittedly), I'll dance on their grave.  You have
to up the ante sooner or later...
--
Brian
brsmith@cs.umn.edu
Newsgroups: comp.mail.mime
From: mitra@pandora.sf.ca.us (Mitra)
Subject: Looking for sh version of showexternal
Organization: Pandora Systems
Date: Tue, 5 Jan 1993 04:54:29 GMT
X-Newsreader: TIN [version 1.1 PL6]


Does anyone have a /bin/sh version of showexternal, the new (2.4)
version distributed with metamail has numerous problems running under
SCO Unix, and hacking a bin/sh version is much more likely to be
successfull 

- Mitra
From: moore@cs.utk.edu (Keith Moore)
Newsgroups: comp.mail.mime
Subject: Re: Return-Receipt (Danger Will Robinson!)
Date: 6 Jan 1993 17:26:52 GMT
Organization: Univ. of Tenn. Computer Science, Knoxville
Distribution: world
Reply-To: moore@cs.utk.edu
NNTP-Posting-Host: yertle.cs.utk.edu

In article <rhoward.726332201@matd>, rhoward@matd.gatech.edu (Robert L. Howard) writes:
> What happened to the discussion on using MIME to handle a MUA
> level Return-Receipt (RR) mechanism?
> 
> Some points:
> 
> 1.  It MUST be voluntary.  Ideal behavior would be for a MIME
>     MUA to ask, "Sender has requested return-receipt, would you
>     like to return-receipt on this message? (y/n)".  MUAs
>     could have user configuration parameters to a) always send
>     RR without asking b) always ask or c) never ask and never 
>     send RRs.
> 
> 2.  I don't particulary care how this is to be handled MIME header-
>     wise (could someone recall previous discussions).
> 
> 3.  There should be a unique ID string type thing for RR message
>     parts so that when the receipt comes back the MUA can easily
>     match it to the message the receipt is for.

I don't see any problem with it, so long as it's clear that what's
being provided is an (optional) "read" acknowledgement, not a
"delivery" acknowledgement.  Basically someone needs to define a MIME
content type for read acknowledgement requests and another type for
read acknowledgements, and define how a supporting mail reader should
act when it receives a message containing a read acknowledgement
request.  Also needed is a definition of exactly what a read
acknowledgement means.

Note that the mail reader, having generated a read acknowledgement,
should probably mark the message in some way, so that duplicate read
acknowledgements are never generated for a message.

The term "return receipt" seems ambiguous.  It seems like some of the
past flaming (thought not all of it) has been due to confusion about
whether delivery acks or read acks were being discussed.

Keith Moore
From: erik@poel.juice.or.jp (Erik M. van der Poel)
Newsgroups: comp.mail.mime
Subject: MIME headers in all sorts of applications
Date: 12 Jan 93 16:04:42 GMT
Organization: sometimes

> My problem is
>   ... that I seem to be unique in thinking that MIME could be a general
>       solution for all kinds of file structuring applications

You are not unique in thinking that.  In June 1991 I posted (to
comp.std.internat) an absolutely ridiculous plan to add MIME-like
labels to _any_ series of bits.  I even talked about whether or not
audio CD players might be updated to support such headers.  The
proposal also included a migration plan.  Needless to say, I was
ignored by most and flamed at by many.

There were at least two severe problems with the plan:

(1) It is hard to get the attention of, and reach consensus among, the
    huge number of people that deal with "series of bits".

(2) In order for such a plan to succeed in protocols that are already
    being used, you need to reach a certain "critical mass" of conformant
    systems before people can even start to use the new format in any
    meaningful way.  I.e. no warm invitation for the first users.

However, _new_ protocols can be designed from the start to include
such headers.  It was therefore rather refreshing for me to read, in
this newsgroup, that it is being used in Gopher, though I don't know
about the first versions of the Gopher protocol.
-
-- 
Erik M. van der Poel                               erik@poel.juice.or.jp
Newsgroups: comp.mail.mime
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Using MIME without extra mail headers
X-Md4-Signature: 25e654a776aaa9972172e8ebaa6dc6bc
Organization: Nat'l Center for Supercomputing Applications
Date: Tue, 12 Jan 1993 20:47:20 GMT

In article <1993Jan12.191444.19513@twg.com> "David Herron"
<david@twg.com> writes:

   MIME could be a file structuring thing as you're suggesting.  It's
   was designed with mail systems in mind but I can't think of many
   things which are unique to them.  The most obvious is encoding
   anything not 7-bit clean.

   But why is MIME *uniquely* suited to this purpose?  

It's not, but it is available, extensible, and becoming very popular.

I don't know about y'all, but at this point in time that's all I need
to hear...

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.mail.mime
Subject: Re: MIME in NEWS?
Date: 11 Jan 1993 20:42:52 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
Distribution: comp
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <brsmith.726781396@duncan> brsmith@duncan.cs.umn.edu (Brian R. Smith) writes:
>What I think Mr. Masterson was referring to was people reading news via
>dumb terminals/emulators/etc.  They're not going to have access to
>graphics, sound, etc.  Even if RichText is readable on dumb terminals,
>they won't *gain* anything from MIME additions to news, ...

But if you're reading news, you've got a computer *somewhere*!  :-)
MIME means more than graphics and sound, and yes, you'll lose graphics
and sound posted in news messages.  MIME also means (relatively) painless
retrieval of publically available files, completely painless transmission
of binaries, smooth handling of digests, and reasonable handling of non-
7-bit-ASCII characters, even when passing through 7-bit and EBCDIC systems.
Surely users of dumb terminals can benefit from at least a few of these?

My point about MS-DOS, before, was that from a MIME perspective, a straight,
non-Windows MS-DOS computer isn't much better than a dumb terminal.  (No
wise-cracks, please!)  Nevertheless, MIME is quite useful for the above
purposes.  It's not going to do nifty graphics and sound, but the users
here will sure be happy when they can send and receive binary enclosures
in a standard way, and the ones who use languages other than English will
appreciate having e-mail that doesn't dictate the language used.

I agree with your point about printing terminals, 300 baud, and so on.
Dumb terminals certainly cannot take advantage of all MIME has to offer.
The world is moving ahead, though, and just as we've all grown past designing
text editors with ASR-33's in mind, we have to start designing e-mail
software with sophisticated user interfaces in mind.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu
From: trier@odin.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 11 Jan 1993 03:18:57 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: odin.ins.cwru.edu

In article <1993Jan10.150252.11230@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>Perhaps the MIME people see MIME only as a temporary solution for
>TCP/IP mailers, which would be rather sad.  Surely it doesn't take much
>imagination to see it as a much more usable alternative to ODA?

Well, as has been said, MIME is in use in the Gopher community, where it
is defined as "a file starting with MIME headers".  I have heard suggestions
for its use with WAIS, though I think that idea fizzled.  It works with
Gopher because Gopher already presumes that all text transactions are done
in US-ASCII or a superset like ISO-8859-1.  Gopher also provides for 8-bit
binary data.  I don't know which of the two is used by MIME.

It's not appropriate for use in FTP.  It might be useful on local systems
for file storage and retrieval, though.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu
Newsgroups: comp.mail.mime
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: Using MIME without extra mail headers
Organization: Naval Research Laboratory, DC
Date: Sat, 9 Jan 1993 13:46:29 GMT

In article <1993Jan8.211048.21332@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:

>If I wasn't using an SMTP mailer, for example (I use a Grey Book mailer)
>or if my mailer stripped out unrecognised headers for some reason.
>
>Surely this problem also comes up in connection with using MIME as a
>general file format, for use in (say) Gopher or FTP?  Or has nobody
>thought of doing that?

MIME works fine as is with gopher.  I can't imagine a reason why it
wouldn't work fine with ftp as well.  There is serious discussion of
adding MIME to USENET news as a new enhanced article format.

Ran
atkinson@itd.nrl.navy.mil
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 11 Jan 93 12:22:32 GMT
Organization: U of Cambridge, England

In article <1993Jan11.001838.13304@lut.ac.uk> M.T.Hamilton@lut.ac.uk ([*] M.T.Hamilton) writes:
>  Lines: 24
>
>  ###MIME headers follow###
>  Content-Type: text/richtext

Yes, this is precisely the sort of thing I meant.  Except that '#' is
probably not a good character to use - see RFC 1341 Appendix B.
If a tag is thought necessary, I suggest

  .)MIME

but perhaps a better scheme would be:

The message (or file) is scanned until the end, or the first line that
doesn't start with one of the five text strings used to represent MIME
"headers" in RFC 1341.  If a MIME-Version "header" is found, the file
is considered to contain MIME; any detected MIME headers are removed from
the content of the file as used by the application.

The remaining problem is with "Received:" headers, which have a habit of
being moved to message texts by gateways sending to non-RFC822 domains.
But then MUAs can do ad hoc processing (perhaps removing them altogether
or creating a new MIME text body part to contain them); this problem will
not be present in non-message-transfer applications.
Newsgroups: comp.mail.mime
From: vances@xenitec.on.ca (Vance Shipley)
Subject: MIME in NEWS?
Content-Type: text/richtext
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA
Content-Id: <235_12617_726675863_4@xenitec>
Date: Sun, 10 Jan 1993 14:56:06 GMT
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Status: OR



Does anyone have patches for trn which will interface it to metamail?  Is
anyone working on MIME in NEWS?  It seems to me that this news group would
be a likely place to start.  The thing about MIME is that there are so few
good authoring tools that it is not practical to use for day to day stuff.
A "one to many" correspondence like posting news is a better application for
MIME right now.  The more people read multi media mail the more use they'll
see for it.  Below is a bit of richtext.  If you do not have a MIME smart
news reader  you will see a lot of formating codes.

<nl><center><bold><underline>MIME in NEWS
</underline></bold></center><nl><flushleft>It seems to me that all =
we need to start posting =
<italic>MIME</italic> content stuff are news readers which have =
<italic>MetaMail</italic> integrated.  That shouldn't be hard.  This message =
is a test, it was created with a <bold>Content-type: </bold>header declaring =
this message to be of <bold>text/richtext</bold> format.  I have put it =
together by hand because I don't have a <italic>MIME</italic> smart news =
reader.  <nl><nl></flushleft>=

-- 
Vance Shipley 
vances@xenitec.on.ca         vances@switchview.com         vances@ltg.uucp