Re: [Fwd: Netscape Communicator: MIME issues on the Macintosh and plenty of other problems]

[trudelle@netscape.com (Peter Trudelle)]

Arnaud TADDEI wrote:

> When you install Netscape Communicator on a Macintosh, how is it going
> to decide which are the types and where are the applications it should
> start when receiving MIME attachments.
>
We use our own MIME table, which can be changed via Edit | Preferences |
Navigator | Applications.  We are also starting to use the Internet
Configuration System,  a popular solution on the Mac that should become
system software soon, but our support for it is still rather weak.

> Does it use the Desktop
> application database on the Macintosh?
>
Yes, if the application is not already running, we find it by using the
Mac APIs to the desktop database.

> What happens if this database is
> corrupted or not up dated?
>
Then we may not be able to find it, but  this feature is central to the
Mac UI, corruption would degrade many apps. The Finder may not be able
to find an app to handle opened documents either.  In practice this
doesn't happen much, and the database is easily repaired, even by end
users using a utility such as Norton Disk Doctor, or just holding down
the 'Apple' and option keys while the volume is mounting.

> Moreover what changed concerning MIME types et al between 4.02 and
4.03
> (or shall I say 4.03.1 as it seems there was a maybe clearly hidden
> release?) Indeed now if you send a mail with a word document with a
.doc
> extension it gets encoded Base 64 and although the icon and meta info
> comes right you cannot open the document.

Are we still talking about the Mac here, because it had a 4.0.3.1, but
no 4.0.2.  We just fixed a bug this week in our handling of received
AppleDouble attachments that also had file extension that we recognize.
Communicator 4.0.3 saved the raw encoded part rather than the file.  If
you drop the file  on a decoder like YA-Base64, the original is
restored.  Is this what you are seeing?  There is a workaround,  if you
add user_pref("mailnews.autolookup_unknown_mime_types", false);
to your netscape preferences these files decode properly.

> So I believe that the logics/defaults etc. must be really horrible on
> Netscape Mac. My surprise comes from the fact that other clients get
> it right so is Netscape too laxist, too clever, too strict, ?? Why
don't
> we have so many attachment problems on Windows 95 for example?

Well I only know for sure about our client, but I have heard that other
clients have bugs too, even on Window 95 :-(.  In this case we had a bug
in handling these files, but it is not in the typical case.  For most
Word files, only the data fork is significant, the resource fork is
discarded on other platforms.  So they don't need to be packaged as
AppleDouble, and in fact it is unusual to see that.

>  In particular we have a serious problem to exchange documents between
> Simeon (ESYS) and Netscape Communicator 4.03 on the Macintosh. Indeed
> WinWord documents sent from Simeon are not categorised correctly when
> received on the Macintosh and read with Netscape Communicator 4.03.

This is another bug we fixed this week.  As you pointed out, Simeon is
sending MIME types partly in uppercase, which is unusual but valid.  In
4.0.X, we introduced improper case-sensitivity in our handling of the
these types. The workaround described above also handles this.

> Note 2:
>  -------
> Moreover, we experienced issues when a user sends a WinWord attached
> document with Nestcape on the Macintosh. Recipients have often
problems in
> particular due to the Macintosh meta data file which is passed as an
extra
> MIME attached file to the recipients who get confused when getting  a
.UKN
> additional file. This problem is documented for our users at CERN at:
>         http://wwwinfo.cern.ch/service/mail/mime

It sounds like, once you get past the issue of which version of Word is
being used, that some recipients are having problems with AppleDouble
attachments.  We are trying to minimize use of this encoding to the
cases where the original document has a non-empty, significant resource
fork.  We are using Internet Config to determine whether to include the
resource fork information, so the user has some control over which
documents are sent that way. It is odd that users would be sending a Win
Word file from a Mac, and even stranger that it would have a resource
fork. But if you supply us with details about this we will look into it.

Thanks for your feedback, and especially your patience. We are fixing
these problems as we discover them.

Peter