🚀 go-pugleaf

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?

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.

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

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.

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

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