HDTenEightyP/NetNews huggingface dataset:
From: erik@poel.juice.or.jp (Erik M. van der Poel)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 10 Jan 93 07:53:15 GMT
Organization: sometimes

Although I am by no means an official spokesperson for the group that
designed MIME, I believe the answer to your original question is that
MIME requires certain programs to be updated while most can be left as
is for transmission of MIME messages.

Base64, for example, was carefully designed to be transmissible
through virtually every email system out there.

On the other hand, there are e.g. mailing list servers that strip
unsupported headers such as "Content-*", so that users cannot expect
MIME messages to pass through with all headers intact.  As far as I
know, MIME's designers consider such programs to be "broken" and in
need of fixing.

On the third hand, RFC 1342 (the non-ASCII header proposal) does not
require such programs to be updated.  It embeds all the necessary info
within the existing "To:", "From:", etc headers.

Anyway, since the number of programs that strip MIME headers is small,
it will be easy to get them updated and re-installed.
-
-- 
Erik M. van der Poel                               erik@poel.juice.or.jp
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.mail.mime
Date: Mon, 11 Jan 1993 15:01:23 -0500 
From: John Gardiner Myers <jgm+@CMU.EDU>
Subject: Re: Using MIME without extra mail headers
	<1993Jan11.001838.13304@lut.ac.uk>

M.T.Hamilton@lut.ac.uk ([*] M.T.Hamilton) writes:
> This is a gross hack but it would be of practical benefit to those 
> people who are in the same position as Alasdair.

No, it will not be of benefit to such people, at least not in the long
term.  Such a kludge would do two things:

1) Remove the incentive to get the broken gateways fixed.  Once
established, such an "interim" convention would never go away.

2) Encourage people to generate messages of this form.  Such messages
are not in MIME format and will not be interpreted by many correct
MIME implementations.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From: moore@cs.utk.edu (Keith Moore)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 8 Jan 1993 21:14:19 GMT
Organization: Univ. of Tenn. Computer Science, Knoxville
Distribution: world
Reply-To: moore@cs.utk.edu
NNTP-Posting-Host: wilma.cs.utk.edu

In article <1993Jan7.191810.1857@infodev.cam.ac.uk>, 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?

There is a proposal for using a MIME-like syntax to extend the kinds
of body parts that can appear in X.400(84) messages that does
something like what you suggest...if a body part of a particular type
begins with "MIME-Version:", the body part is assumed to be in MIME
format.  The application of this proposal is supposed to be limited to
gatewaying X.400(88) messages to X.400(84) messages, though it could
be used for RFC 822-to-X.400(84) gatewaying as well.

The current version of this proposal is in the file
internet-drafts/draft-ietf-mimemhs-harpoon-00.txt, available from your
favorite internet drafts repository (nnsc.nsf.net is one).  Please
note that the proposal is still under development.

Similar conventions might be useful for other non-Internet mail systems.

But there isn't any such convention for RFC 822 messages in general,
nor should there be.
--
Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN  37996-1301
Internet: moore@cs.utk.edu      BITNET: moore@utkvx
Let's stamp out ASN.1 in our lifetime.
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 11 Jan 1993 18:28:34 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

[*] M.T.Hamilton (M.T.Hamilton@lut.ac.uk) wrote:

: This suggestion will probably appall purists, but here goes:

Would it not be simpler and more expedient to work on the wone
gateway that doesn't know how to handle MIME headers right, than
to hack up 100 MIME-ready clients to implement some nonstandard
options?


  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB
From: ddj+@cs.cmu.edu (Doug DeJulio)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 12 Jan 93 18:27:15 GMT
Article-I.D.: cs.C0r79G.2BM.2
Organization: School of Computer Science, Carnegie Mellon

In article <1993Jan12.123329.16748@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>If the problem were only about gateways, it would be more easily fixable.
>But it is not, it's about domains. What is a gateway supposed to do to a
>MIME message destined for a domain that does not support the inclusion
>of MIME headers in the "header part" (something well-defined in RFC 822
>but by no means universal) of messages?  Perhaps people with limited
>experience of heterogenous mail domains should ponder this question before
>leaping in with the suggestion that it's all about gateways.

Well, in those domains, something other than pure MIME is going to
have to be the solution.  Perhaps the business with the headers at the
beginning of the body would work.  BUT, I would assert that this is
still a gateway problem.  The gatewaying software should take a
correct MIME message and convert it into something that the broken
domain can understand, and it should make sure that any hacked-up
format is converted back into pure MIME before sending it back out
through the gateway again.  The fact that the MIME standard is well
defined should simplify the task of writing such a "smart gateway"
somewhat.
-- 
Doug DeJulio
ddj+@cmu.edu
Newsgroups: comp.mail.mime
From: viljanen@klaava.Helsinki.FI (Lea Viljanen)
Subject: --Press any key to go on.-- in metamail 2.4
Organization: Pussy Galore's Flying Circus
Date: Mon, 4 Jan 1993 09:43:24 GMT

The new 2.4 version of metamail has lost some functionality
with the new "--Press any key to go on.--" prompt. 

In the previous version ^C would interrupt and (in elm)
return to message menu, but with this new prompt every
key I press will display the rest of the message.

I'd really like to see a way to quit reading the message
in the "--Press any key to go on.--" prompt. 

Accidentally I've rm'ed the old source tree, so I can't
investigate what has changed. I hope someone can.

-- 
Lea 'LadyBug' Viljanen     University of Helsinki   "Every real program
Lea.Viljanen@Helsinki.FI   Computing Centre          has some input" - H&P
Newsgroups: comp.mail.mime
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: Assigned content & application types etc.?
Organization: Naval Research Laboratory, DC
Date: Sat, 9 Jan 1993 01:09:06 GMT

In article <1993Jan8.190658.18488@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>
>Since the latest assigned numbers RFC predates MIME, is the latest list
>of registrations (especially application subtypes) available anywhere?

The most recent Assigned Numbers RFC is recent and has a number of
MIME registrations listed.

Ran
atkinson@itd.nrl.navy.mil
From: giese@schwartz.loria.fr (Jean-Claude Giese)
Newsgroups: comp.mail.mime
Subject: Metamail and lemacs
Date: 5 Jan 93 16:15:13 GMT
Reply-To: giese@loria.fr
Organization: Crin-Inria-Lorraine




	The patch for emacs-vm and metamail don't work for me,
	because the package "transparent.el" don't work with
	lemacs-19.3.
	Does it exist a new package "transparent.el" for lemacs
	or better, an other patch for metamail using the lemacs's
	goodies ?




-------------------------------------------------------------------------
|Jean-Claude GIESE			| Humans are making mistakes    |
|INRIA-Lorraine				| Humans are making computers   |
|Campus Scientifique			| Computers are making mistakes |
|615, rue du Jardin Botanique - B.P. 101 -------------------------------|
|54602 VILLERS-LES-NANCY CEDEX						|
|Tel: 83 59 30 31		Telex: 850 238 F			|
|Telecopie (Fax): 83 27 83 19	e-mail: Jean-Claude.Giese@loria.fr	|
-------------------------------------------------------------------------
From: Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel)
Newsgroups: comp.mail.mime
Subject: Encoding a message
Date: 4 Jan 1993 18:18:36 +0100
Organization: INSA Informatique, Lyon, France
NNTP-Posting-Host: grasp1.univ-lyon1.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

RFC-1341 indicates that "multipart" messages shall not be encoded in
order to avoid ecursion in the encoding.  Is it safe to assume that 
any other type (including future ones :)) can safely be encoded
to quoted-printable or base64 ?

-- 
Christophe Wolfhugel    |    Email: Christophe.Wolfhugel@grasp.insa-lyon.fr
  "Premier reve de 93: l'Europe, un cauchemar."
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 10 Jan 93 15:02:52 GMT
Organization: U of Cambridge, England

In article <C0MoKr.5wn@poel.juice.or.jp> erik@poel.juice.or.jp (Erik M. van der Poel) writes:
>Anyway, since the number of programs that strip MIME headers is small,
>it will be easy to get them updated and re-installed.

The number of programs that strip MIME headers is _not_ small.
Because mail is particularly amenable to gatewaying, there is far less
incentive to upgrade every single user agent. The mailer I use every day
doesn't use SMTP; it sends to an Internet gateway, but there is no way
to get that gateway to lift MIME headers out of the message text into
the real header. Yes, there are draft recommendations for X.400/SMTP
gatewaying, but guess what, my mailer doesn't use X.400 either.

And many non-mail programs only use "files" rather than "text PLUS headers".
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?
From: rhoward@matd.gatech.edu (Robert L. Howard)
Newsgroups: comp.mail.mime
Subject: Return-Receipt (Danger Will Robinson!)
Date: 6 Jan 93 14:56:41 GMT
Organization: Georgia Tech Research Institute

Okay, I recall that this was discussed once before.  I know, I know,
this is likely to cause a flamefest...

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.

Has anyone tried this yet (perhaps at an X-header level)?

[Flame-proof suit on]

Thanks,
Robert
--
| Robert L. Howard              |   Georgia Tech Research Institute     |
| robert.howard@matd.gatech.edu |   MATD Laboratory                     |
| (404) 528-7165                |   Atlanta, Georgia  30332             |
-------------------------------------------------------------------------
| "See, when the GOVERNMENT spends money, it creates jobs; whereas when |
| the money is left in the hands of TAXPAYERS, God only knows what they |
| do with it.  Bake it into pies, probably.  Anything to avoid creating |
| jobs." -- Dave Barry                                                  |
From: moore@cs.utk.edu (Keith Moore)
Newsgroups: comp.mail.mime
Subject: Re: Any better rich-text viewers out there?
Date: 5 Jan 1993 01:21:43 GMT
Organization: Univ. of Tenn. Computer Science, Knoxville
Distribution: world
Reply-To: moore@cs.utk.edu
NNTP-Posting-Host: wilma.cs.utk.edu

In article <1993Jan4.102716.12291@lth.se>, kurt@dna.lth.se (Kurt Swanson) writes:
> I just installed metamail on my SPARCstation 2.  While generally happy
> with this, I noticed that metamail doesn't have a good method for
> displaying rich text format mail...  It seems only to try to use that
> which is available with the standard shelltool/xterm/whatever...  That
> leaves out color, italics, amongst others...  Is ther anything better?

If you have groff, you can install my richtext to groff converter, and
use the gxditview previewer to view richtext messages.  It supports
most of the features defined in RFC 1341.  Anonymous ftp to
cs.utk.edu, directory pub/MIME, files "richtogroff.c" and
"richtogroff.README".

> Also, is the rich text format found on NeXT machines a broader format?
> It seems to have definitions for fonts & other things.  

NeXT uses a variant of Microsoft's RTF (for "Rich Text Format").  They
aren't related and the similarity of names is unfortunate.  MIME's
richtext is designed to be relatively simple -- just enough to add a
bit of expressability to email messages.  As I understand it, RTF is
designed to allow interchange of documents between various word
processors.

--
Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN  37996-1301
Internet: moore@cs.utk.edu      BITNET: moore@utkvx
UNIX is your brain..............SYSV is your brain on drugs.
Newsgroups: comp.mail.mime
From: "David Herron" <david@twg.com>
Subject: Re: Using MIME without extra mail headers
Sensitivity: Personal
Encoding:  48 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Tue, 12 Jan 1993 19:09:10 GMT

kosta@blues.kk.sub.org (Kosta Kostis) == >

> The MIME-headers should be in the headers only.

Well, they aren't.  There's an earlier RFC for multi-bodypart called
RFC-1154.  It used a single line in the header to describe the bodyparts.
It has many problems:

- Obviousness.  To a recipient who doesn't have an 1154-aware UA it isn't
  obvious that there are many bodyparts in the message.  All the information
  is stuck up in the header which most people don't look at.

  Since MIME scatters headers among the body parts it is much more
  obvious where they are.

- Lack of expressive power.  There isn't a lot of room to put a good and
  adequate description of the content.  In fact 1154's only description
  is a line count and one or two words.  A more powerful syntax for
  describing content (on a single header line) is possible, at the cost
  of a more complex parser.  It would be very hard to achieve the same
  descriptive ability which MIME has.

- Reliance on line counts.  Line counts have been known to change due to
  software bugs mostly.  At one time I installed something in the ukma 
  news system to compare actual line counts against the ones claimed
  in the header.. it was amazing how often it was different.

> 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.

My what a rosy picture...

First, as you noted in the next paragraph RFC-821 insists in chopping
off a bit.  This certainly requires analyzing the content.

Second MTAs frequently act as a UA and do UAish things.  Three examples:

- Mailing lists.
- Gateways to foreign mail systems or FAX or printers.
- List/information servers.

In all three cases the entity which does the work lives within
the MTA.  All three must analyze the content to some extent.

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- "That's our advantage at Microsoft; we set the standards and we can change them."
<- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.
Newsgroups: comp.mail.mime
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Subject: Using MIME without extra mail headers
Organization: U of Cambridge, England
Date: Thu, 7 Jan 1993 19:18:10 GMT


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?
From: de19@umail.umd.edu (Dana S Emery)
Newsgroups: comp.mail.mime
Subject: Re: MIME Frequently Asked Questions
Date: 6 Jan 93 00:45:56 GMT
Followup-To: comp.mail.mime
Organization: personal

> 2.6 Newsgroups and mailing lists
> 
> The newsgroup [comp.mail.mh] contains discussions of MH, which, as of
> MH 6.7.8, includes MIME.
>  
> There is also a [comp.mail.multi-media] newsgroup, which contains
> general discussions of multi-media e-mail, not necessarily MIME.
> 
> (ietf wg lists, plus comp.mail.*, etc)
> 

How could you forget the newsgroup you posted this to? [comp.mail.mime]


--

Dana S Emery <de19@umail.umd.edu>
Newsgroups: comp.mail.mime
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Subject: Re: Using MIME without extra mail headers
Organization: U of Cambridge, England
Date: Fri, 8 Jan 1993 21:10:48 GMT

In article <1993Jan8.201921.17081@twg.com> david@twg.com (David Herron) writes:
>I don't understand how you wouldn't be able to insert Content-Type:'s
>into the header..?

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?
Newsgroups: comp.mail.mime
From: connolly@convex.com (Dan Connolly)
Subject: Re: Using MIME without extra mail headers
Date: Wed, 13 Jan 1993 00:18:09 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1iqov1INNivb@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>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.

"Well, there you go again..."

I suppose I'm beating a dead horse, but ...

The Gopher project equates the gopher type M with the MIME message/rfc822 content-type.
While the message/rfc822 content type can contain a body of any type, I'd like
to see the gopher project go a little farther: dispense with the single character
data type namespace alltogether in favor of the MIME namespace. (i.e. no more I
for images: put "image/gif" in the gopher listing in stead. But the data stays
the same: you don't add headers or base64 encode it.) At least formally equate
the rest of the single-character types with MIME types (excepting the single-character
types that refer to protocols, like telnet and CSO).

The WAIS project leaders have said they are going to do "the right thing." i.e.
not just include the message/rfc822 content-type in their type namespace (as "MIME")
but replace their namespace with the MIME namespace. So no more WAIS "TEXT" type:
it's "TEXT/PLAIN", and no more "GIF", but rather "IMAGE/GIF" and no more "PS" but
in stead "application/postscript".

Dan
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.mime
Subject: Re: Assigned content & application types etc.?
Date: 9 Jan 93 14:25:57 GMT
Organization: U of Cambridge, England

In article <C0KB76.p4@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>The most recent Assigned Numbers RFC is recent and has a number of
>MIME registrations listed.

The most recent Assigned Numbers according to the index at NIC.DDN.MIL
is RFC 1340, which was released concurrently with MIME.  It lists a number
of registrations but only those described in RFC 1341.  Is it really the
case that despite the rapid adoption of MIME, no application subtypes have
been registered since then?
From: M.T.Hamilton@lut.ac.uk ([*] M.T.Hamilton)
Newsgroups: comp.mail.mime
Subject: Re: Using MIME without extra mail headers
Date: 11 Jan 93 00:18:38 GMT
Organization: Dept of Computer Studies, Loughborough University, UK
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Mime-Version: 1.0

In article <1993Jan10.150252.11230@infodev.cam.ac.uk>, 
  ag129@cus.cam.ac.uk (Alasdair Grant) writes:

/ The number of programs that strip MIME headers is _not_ small.
/ ...

This suggestion will probably appall purists, but here goes:

We could always establish an interim convention whereby user agents
can be told to use the first few lines of the message body for MIME
info - as though they were an extension to the headers-proper.  
To keep things simple we could use a token to indicate that this
scheme is being followed, e.g. in Usenet it might look something 
like this:

  From: vances@xenitec.on.ca (Vance Shipley)
  Newsgroups: comp.mail.mime
  Subject: MIME in NEWS?
  Message-ID: <235_12617_726675863_3@xenitec>
  Date: 10 Jan 93 14:56:06 GMT
  Organization: XeniTec Consulting, Kitchener, Ontario, CANADA
  Lines: 24

  ###MIME headers follow###
  Content-Type: text/richtext
  Content-Id: <235_12617_726675863_4@xenitec>
  Mime-Version: 1.0
  Content-Transfer-Encoding: quoted-printable
  
  Does anyone have patches for trn which will interface it to metamail?  Is
  ...

This is a gross hack but it would be of practical benefit to those 
people who are in the same position as Alasdair.

Martin  
--
M.T.Hamilton@lut.ac.uk | cp141@freenet.cleveland.edu | mhamilto@nyx.cs.du.edu
Dept of Computer Studies, Loughborough University of Technology, LE11 3TU, UK
+44.(0)509.222799  "i hope it all melts and is gone by the time i leave"-pjf.
From: kurt@dna.lth.se (Kurt Swanson)
Newsgroups: comp.mail.mime
Subject: Any better rich-text viewers out there?
Date: 4 Jan 93 10:27:16 GMT
Organization: Lund Institute of Technology, Sweden

I just installed metamail on my SPARCstation 2.  While generally happy
with this, I noticed that metamail doesn't have a good method for
displaying rich text format mail...  It seems only to try to use that
which is available with the standard shelltool/xterm/whatever...  That
leaves out color, italics, amongst others...  Is ther anything better?
Also, is the rich text format found on NeXT machines a broader format?
It seems to have definitions for fonts & other things.  Being that
there exists all kinds of fancy text viewers (dvi viewers, postscript
viewers, etc...) it would seems that there ought to be something
better for rich text...
-- 
Kurt Swanson, Dept. of Computer Science,
Lunds universitet.  Kurt.Swanson@dna.lth.se
-- 
Kurt Swanson, Dept. of Computer Science,
Lunds universitet.  Kurt.Swanson@dna.lth.se
Xref: sparky comp.mail.mime:96 comp.infosystems.wais:805