Mime, Netfax, and posting on Comp.Mail.Mime

"Alan R. Katz" <katz@adonis.com> Sun, 07 March 1993 01:56 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08507; 6 Mar 93 20:56 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08501; 6 Mar 93 20:56 EST
Received: from stubbs.ucop.edu by CNRI.Reston.VA.US id aa18463; 6 Mar 93 20:56 EST
Received: by stubbs.ucop.edu (5.57/1.34) id AA09151; Sat, 6 Mar 93 17:33:38 -0800
Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23577 for ; Sat, 6 Mar 93 20:27:48 -0500
Received: by Adonis.Com (4.1/DA1.0.3) id AA12089; Sat, 6 Mar 93 17:23:18 PST
Date: Sat, 06 Mar 1993 17:23:18 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Alan R. Katz" <katz@adonis.com>
Message-Id: <9303070123.AA12089@Adonis.Com>
To: Harald.T.Alvestrand@delab.sintef.no
Cc: Cohen@isi.edu, mhn@stubbs.ucop.edu, netfax@stubbs.ucop.edu
Subject: Mime, Netfax, and posting on Comp.Mail.Mime

Copy of My posting to Comp.Mail.Mime regarding other posts about
Netfax and MIME:

				Alan
-----

Regarding G3 (and other) FAX and MIME:

As one of the authors of RFC1314 (A File Format for the Exchange
of Images in the Internet) I thought I should respond to some
of the posts in this newsgroup.  

I am no longer involved in this area (at least for now) since
I left USC/ISI last year.

RFC1314 was the end product of the IETF Network Fax (Netfax) 
working group and was authored by Danny Cohen (Cohen@Isi.edu)
and myself.  We tried to propose a standard that would be 
compatible with much existing technology as much as possible
but still take advantage of the best encoding techniques.

The Netfax format IS in fact a registered MIME type with the IANA (as
I understand it).  [As Ned Freed (MIME co-author) told me, though all
example MIME types in the current MIME RFC are registered, the
converse is not true.]  The reference to Netfax was taken out of
the MIME document at the direction of the IESG, apparently because
they felt that decoupling standards where possible is a desirable thing.


Now, let me respond to some recent comments by Harald Tveit Alvestrand.
I will also cc this to the Netfax mailing list and suggest that further
discussion be directed there (Netfax@Stubbs.ucop.edu).


> It turns out that there are 3 problems with the Netfax RFC:
> 
> 1) Their format is actually a SUPERSET of G3Fax. So what do we do when
>    an extended-feature message hits the gateway?
> 

We recommend that images be encoded MMR (Group 4 encoding) because it
is so much better than G3 (MR or MH).  The G3 protocols assume you
do not have a reliable communications path and so do encode more than
a few lines at a time.  On the Internet, we HAVE a reliable transport
mechanism (many: mail, ftp, etc) so why use an inefficient encoding?

We allow for MR or MH encoding, but then require scan lines to
be "byte-aligned" (padded with 0's so that each line begins on
a byte boundary) to be compatible with existing fax cards and 
the TIFF-F (TIFF Fax) format.

So, if you are building a gateway that accepts message with G3 data
in it (say X.400), you have three choices:

	1.  Decode the data and encode in Netfax, MMR recommended
	    unless you want to eat up disk space (or have low quality
	    fax images).

	2.  Decline to translate certain types (say, if its MR or MH
	    but not byte-aligned).

	3.  Define yet another MIME body part called raw G3 or something
	    and use that.  If you do, you are pushing the conversion
	    problem onto the recipient.


> 2) Some (perhaps hypothetical) features of G3Fax were not mentioned
>    in the RFC, and some issues (bit order in bytes!) were not mentioned.

The RFC is currently a PROPOSED standard and there are certainly some 
changes that will end up being made before its adopted (if it is).

Bit order in bytes:  YES!  We DID miss on this.  And Danny Cohen is the 
one who wrote the definitive paper on this and coined the term "-Endian"
many years ago.  Definitely needs to get fixed in the next revision.

> 
> 3) The addresses of the authors in the RFC did not respond to my probes.
> 

So sorry, but I left USC/ISI and your message probably got lost (I did
not have good e-mail access for a while).  As I say, I am no longer
paid to do Netfax related work so am going to be hard pressed to
do much more on it.  Mark Needleman (MHN@Stubbs.ucop.edu) is (or at
least WAS) the Netfax chair.  However, that working group has been
suspended after the publication of 1314 until it is needed again.


> So, I chose to ignore NetFax and define the simplest possible mapping.
Comments invited!

I think this is the wrong thing to do for the reasons we write about
in the RFC.  Its bad enough that over half of the transatlantic 
phone traffic is bad quality digitized images ("faxes") with 
inefficient encoding, turned into sounds (by fax machines) and sent
on voice channels with are then re-digitized (on T3 or whatever)!
Lets not keep (or at least send) our images over the Internet in this form.

In conclusion,

There are a number of groups who plan to use Netfax, notably big
library systems who are developing very large databases of images.
There is no rule saying you should store your images in the same
format as they are exchanged in, but it does make the exchange 
easier.  

By the way, we envision Netfax not only used via MIME, but a 
variety of other transports (such as FTP).  One main goal was
to decouple the encoding and file format from the transmission means.



		Alan (Katz@Adonis.Com) 

     [Because our newsgroups are not completely working, I am posting
     this from another account.  Please send me mail at
     Katz@Adonis.Com and NOT at halcyon]