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]
- Mime, Netfax, and posting on Comp.Mail.Mime Alan R. Katz
- Re: Mime, Netfax, and posting on Comp.Mail.Mime Stuart Lynne