Subject: Will Pine Ever be Intelligent?

From: [email-masked] (Nick Lurie)
Date: 19 Nov 1994 22:13:48 GMT

Will Pine ever have the capability to read attached formatted files sent
from programs like Eudora without the user having to be a Unixhead?

---

From: [email-masked] (Ralph Sims)
Date: 20 Nov 1994 00:38:59 GMT

>from programs like Eudora without the user having to be a Unixhead?

Are you calling Eudora intelligent?

--

  Northwest NEXUS, Inc. takes Internet OUT of the box!
  [email-masked], finger [email-masked], or:
  http://www.halcyon.com; +1 206 455 3505 voice

---

From: [email-masked] (Nick Lurie)
Date: 21 Nov 1994 02:48:25 GMT

Yes!  If I want to attach a document I choose attach and then click on the
file I want to send.  Eudora translates the document.  If the person I am
sending the file to is running Eudora, NuPop or some other intelligent mail
program, the file is automatically translated back to the right format and
the person can choose where to store it.  That's intelligent.

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 20 Nov 1994 18:24:49 -0500 (EST)

Nick, are you commenting on the user interface in Pine for attachment
(assuming you've got some form of attachments to work) or on the fact that
attachments don't work at all?  Here's an answer if the latter is the
question: 

There's actually two formats that are commonly used for attachments these 
days, MIME and uuencode (Surely that has been discussed here before??).

Uuencode is kind of an old defacto convention that has many short 
comings (not reliable over all links, ill defined, can't tag the type of 
attachment.) 

MIME is soon to the be the Internet standard for attachments, and is 
fully implemented in Pine.  Eudora is capable of doing both uuencode and 
MIME though maybe not all versions.  I suspect if you got your Eudora 
using friends to reconfig it for MIME you'd find it operating quite 
intelligently!  

Also, I'm not sure what you mean by translation.  Pine and Eudora should 
do just fine for text files and binaries if you just want to move the 
bits around.

Laurence Lundblade                             
  [email-masked] (and a few other addresses) 
     http://oneworld.wa.com/laurence/home.html
        Virginia Tech CS -- Blacksburg, Virginia, US -- 703-552-2537

---

From: [email-masked] (Don Loflin)
Date: 23 Nov 1994 15:22:29 -0600

>days, MIME and uuencode (Surely that has been discussed here before??).

Well, three - binhex, the default used in Eudora.

>using friends to reconfig it for MIME you'd find it operating quite 

Eudora uses Binhex, not UUENCODE.  It can decode MIME, but the default for
sending attachments is BINHEX, not Base64 (the encoding used in MIME).  This
is wrong, IMHO.  The default ought to be MIME for outgoing, and my opinion
is that it shouldn't even allow Binhex for outgoing messages.

If you're using Mac Eudora, there's a trick to using proper MIME
encoding so that Pine can read the attachments.  You have to be sure and
check the box labeled "always as Mac documents" as well as selecting 
"AppleDouble" for the encoding, or Mac Eudora will binhex.  The PC
version of Eudora is much better, offering a simple choice of MIME vs
Binhex.  Hopefully, the Mac version will switch to that interface in a
future release.

Since this message was Cc'd to Qualcomm, I ask them: when will you remove
outgoing Binhex from Eudora, to reduce this kind of confusion and stop
hindering widespread MIME acceptance?

---
Don Loflin
Microcomputer Technologies,        // DISCLAIMER: I do not represent 
Computation Center - UT Austin     // the views of my employer, nor
[email-masked]             // am I acting officially for them

---

From: [email-masked] (Steve Dorner)
Date: Wed, 23 Nov 1994 16:09:41 -0600

In article <[email-masked]>, [email-masked]
(Don Loflin) wrote:

>is wrong, IMHO.  The default ought to be MIME for outgoing

Eudora never uses anything except MIME.  Even when it does BinHex or
uuencode, it uses MIME.

>and my opinion

You're welcome to your opinion.  My opinion is that you are a loon.

>"AppleDouble" for the encoding, or Mac Eudora will binhex.

BZZZZT.  WRONG.  Thank you for playing.

Selecting AppleDouble is sufficient.  Always as documents does not affect
the AppleDouble vs BinHex choice.

In fact, documents can be sent as MIME even when BinHex is chosen, if the
data type is marked in the mapping resources (equivalent to mailcap) as
having a superfluous resource fork & Macintosh type.

>Binhex.  Hopefully, the Mac version will switch to that interface in a

Sure, right after Apple drops MacOS in favor of MS-DOS, and there are no
resource forks to worry about anymore.  And right after the IANA picks up
Apple's extensive type registry, so that the Macintosh type information is
no longer often the only way to figure out what's in a file.

>hindering widespread MIME acceptance?

You are sadly misinformed.  Eudora uses MIME even when BinHex'ing, and it
accepts all sorts of MIME.  I'm hardly hindering MIME acceptance.

-- 
Steve Dorner, Qualcomm Inc.

---

From: [email-masked] (Nick Lurie)
Date: 26 Nov 1994 20:27:45 GMT

In article <[email-masked]>,
[email-masked] (Steve Dorner) wrote:

> having a superfluous resource fork & Macintosh type.
Steve,

Does this mean one should select AppleDouble all the time, only when
sending attached documents to Pine users, or never?

Thanks,

Nick Lurie

---

From: [email-masked] (Don Loflin)
Date: 28 Nov 1994 11:29:56 -0600

>Eudora never uses anything except MIME.  Even when it does BinHex or

I realize Eudora always uses MIME for identifying message parts -- Pine
does always identify a binhexed attachment as such -- but it doesn't
always use BASE64 for encoding binary data, which is what I tried to say.
I made the mistake of using "MIME" instead of "Base64" in my last
sentence.  Let me rephrase: "the default ought to be Base64 for
outgoing attachments, using AppleDouble to isolate Mac-specific data."

>>and my opinion is that it shouldn't even allow Binhex for outgoing messages.
>

Granted, I'm a loon, I can find several to attest, I'm sure :-)  But
please explain why Eudora *should* allow Binhex for outgoing messages.  
Doesn't AppleDouble+Base64 work just as well?  If not, then let's toss
it and define something else that does, but uses Base64 encoding of
binary parts.

>having a superfluous resource fork & Macintosh type.

Well, there must be a bug in 1.4.3 Eudora, because I did several
experiments sending Excel and Word documents and always, if I left
"send as Mac documents" unchecked (but AppleDouble was selected instead
of binhex), the document was sent using binhex instead of appledouble+
base64.  Of course, peering closer, I see that the AppleDouble vs
Binhex selections are *indented* under the "always as mac docs" box, so
I suppose if the box isn't checked, the setting below isn't used.  At
the least, that needs to be clearer to lightheaded users (myself
included :-)

[I finally checked out 1.5.1b3 - very impressive.  The new settings 
 dialog is very nice, and yes, it sent using the proper encoding, 
 regardless of "include Mac info" setting.]

I guess I'm trying to say that a) for most users, "MIME" means "base64
for binary parts" (whether they're aware of base64 or not -- they just
know that another MIME mailer ought to be able to read the attachment),
b) most users don't know what appledouble is either, so the attachment
configuration dialog is confusing (and binhex is familiar, so they pick
that), and c) most users won't ever bother with the mapping resources,
but still expect their documents to be sent using AppleDouble when they
select that. 

>no longer often the only way to figure out what's in a file.

Again, in the PC version, "MIME" seems to imply "base64" instead of
binhex.  I was just suggesting a simplification of the dialog,
substituting "MIME" for "AppleDouble" so that users would be more
likely to use that when sending to non-Eudora or unknown-MUA users, to
enhance the probability that their document will be usable at the other
end.

As for type information, where there isn't already an "application/xxx"
type, how about including the info in the Content-Description (i.e
"Macintosh Excel Document")?  Mac mailers could just dip into the other
AppleDouble parts, of course, but I don't think non-Mac MUAs should be
responsible for doing that.  Most people are going to tell you what
type of document they're sending in the body anyway, so just being able
to save off the data portion easily will go a long way toward better
interoperability.  It may be that major Mac and/or quasi cross-platform
types (i.e most Microsoft ones :-) should indeed be registered as Media
Types.

>accepts all sorts of MIME.  I'm hardly hindering MIME acceptance.

Yes, I agree, Eudora is very MIME compliant.  I'm just saying it should
prefer using AppleDouble over Binhex.  When users send a binhexed
document to a user running a different MIME MUA, or using a MIME
gateway, they typically can't use the document without hassle, at least
on PCs.  If the senders use AppleDouble, the data portion is much more
readily accessible, thus the user sees MIME as a useful thing, and will
push for its use.  If not, they look at how easy their proprietary mail
system (ccMail, MSMAIL, etc) handles attachments, and think "I don't
need MIME, look how well this works".  *That's* what hinders MIME
acceptance.

If every MIME program is required to support Application/Binhex in
order to exchange documents, and parse out the pieces if they want to
display the type, then the purposes and potential of MIME are
circumvented, IMHO.

---
Don Loflin

---

From: [email-masked] (Steve Dorner)
Date: Tue, 29 Nov 1994 19:39:14 -0600

> please explain why Eudora *should* allow Binhex for outgoing messages.  

Because that's what a large percentage of the pre-MIME installed base is
using.  I can't ignore the need to send data to all those users.

There is also the fact that BinHex's checksum is much more convenient to
compute than content-md5, and we do have quite a few users running over
non-guaranteed-clean channels.  Sure wish there were a way to put the MD5
at the END of the body part rather than the beginning.

> of binhex), the document was sent using binhex instead of appledouble+

Well, I dunno what to say.  That's certainly not what MY copy of 1.4.3
does.  I tested it then, and I retested it just now.

You can get Base64 with BinHex selected (if you set the mapping tables up
that way), but nothing will induce Eudora to use BinHex if you have
AppleDouble selected.  Except, evidently, space aliens in Texas. :-)

> but still expect their documents to be sent using AppleDouble when they

Like I said, it does.

> "Macintosh Excel Document")?

The RFC reads to me like Content-Description is supposed to be about the
content, rather than the type, of the body part.  I think such usage would
be unconventional at best.

> I'm just saying it should
> prefer using AppleDouble over Binhex.

Someday it will.  Perhaps even soon.  Currently, we're too concerned about
compatibility with non-MIME mailers to make the switch.