[Note: I am copying both ipp and ietf-fax mailing lists since this message
affects both groups.]
As a representative for MFPA, we are interested in both Facsimile and
Printing. It is definitely important to these manufacturers to have a
common methodology so that a device need not have disjointed approached for
the printing of fax images or the printing of printer files.
I am reflecting on a curious situation:
First, let's review "history":
1) PRINTING:
Printing has customarily been a "batch" oriented affair, frequently with
one or more spooler queues between the act of submission and the printer.
There is no "negotiation" with the printer because the driver is matched to
the printer and knows very well the printer can perform. The data content
standards for printing are nearly all proprietary, with all standards-based
data-content formats never forming any true backing in the industry (such
as IOS-8613 ODA). The "protocol" is minimal, just copy data to the device.
(True, some recent devices have two-way protocols).
2) FACSIMILE:
Facsimile is a combination of a negotiation protocol and a collection of
standard data formats. The protocol is required to optimize the use of the
scanner and printer devices in a dial-up situation. The protocol provides
for negotiation of capabilities of the marking device so that the
transmitter may scan the data to a resolution no less than that actually
required by the marking engine. (True, some recent fax-server and
computer-fax software doesn't really support much in the way of negotiating
all formats, and run in more of a queued "printer model" mode.
Now:
1) FACSIMILE: the ietf-fax group is advancing the idea that "internet
facsimile" will be the simple transport of compressed images, with little
or no capabilities negotiation. Luckily, we have a "small" set of
capabilities that may need to be negotiated, and bandwidth issues are not
an issue with "free" bandwidth of the internet, so compressed images may as
well be sent at very high resolution, regardless of the capabilities of the
printer. This group is willing to ignore the scanning operation, which is a
noted deficiency in their scope compared with customary facsimile.
2) PRINTING: customary printer files will fit into a MIME attachment very
nicely, but due to the large amount of variation in the type of printer
file formats, fonts, etc. internet printing now more than ever requires the
sort of negotiation that was historically used for facsimile. The situation
of having a driver matched with the printer no longer holds.
IS THIS "MIX-UP" and "REVERSAL OF ROLES" A PROBLEM?
Not really. But I would hope that these groups will acknowledge that their
work does overlap in the area of capabilities negotiation with the remote
device. (I am a bit worried that attacking the PRINTING problem using
customary file formats for print jobs will be difficult to standardize due
to the complexity of these file formats. This would result in ipp protocols
only useful for intranet applications instead of the more general internet
issues.)
If MIME is used to transmit print jobs (whether they be G3fax, TIFF/F, PCL,
PostScript, SPIFF, LDPA "spooler" format, HTML, or whatever) from one site
to another (and this is indeed a handy facility to have) then if the
destination cannot handle the job, the return-receipt methodology can be
used to indicate the capabilities of the remote device.
Please, let's not come up with different methods for this common problem.
The comments that "they have enough internal problems in their group" is a
joke. These are not different groups, they are composed of many of the same
companies that will need to implement BOTH schemes.
PROPOSAL: I propose that the protocol issues be handled by one of the
following:
- Jointly.
- By a separate group with which both groups would liaison. maybe the
return-receipt group is that group.
Regards,
-Raymond Lutz
/***********************************************************************
** Raymond Lutz Voice: 619-447-3246
** Director R & D, Cognisys, Inc. Fax: 619-447-6872
** MFPA EC Chair MFPA: 1-800-603-MFPA
** 1010 Old Chase Ave., Suite B EMail: raylutz at cognisys.com
** El Cajon (San Diego Co.), CA 92020 USA
** WWW: http://www.cognisys.comhttp://www.mfpa.org
***********************************************************************/