Hi:
I am glad to see this ietf group forming to discuss the technical details of
internet and fax interoperability. I have been involved in the formation of
the Multifunction Peripheral Association (MFPA: <http://www.mfpa.org> and am
currently the executive council chair. Also, I am serving as Vice Chair of
the TR29.2 Facsimile Digital Interfaces committee.
I know that the MFPA and TIA-TR29 would appreciate close ties with this group.
I have reviewed the discussions to date (see <http://www.imc.org> and
appreciate the nice work that Mike Lake and others are doing to reveal some
of the issues. However, I think it would be worthwhile to back up from these
details for a moment and attempt to look at the "big picture" so that we
might make some progress in forming concrete targets for the group to work
on. There are existing committees and groups (such as TIA and ITU) that will
want to have some say in certain aspects of this work, I imagine, and
certainly, we may decide that some parts of the work can be "delegated" to
those groups.
I see three (or if counted differently, perhaps four) main areas where there
is work that can be done for "Internet Fax":
1a) Allowing a group-3 fax machine to send a fax which is transported by the
Internet.
1b) Allowing a group-3 fax machine to receive and print a fax image or other
"print job" which was transported by the internet.
2) Changing the PSTN protocol used by a fax machine so that instead of using
the protocols as defined by T.30, it will use protocols defined by ietf and
therefore immediately interoperable with the internet infrastructure.
3) Establish communication with a local area device, such as a Multifunction
device, such that that device may make t.30 facsimile PSTN transmissions, or
to transmit via the protocol as defined by (2).
Let's briefly discuss each:
1a) Group-3 machine sending a fax into the internet.
----------------------------------------------------
- would require some sort of gateway device to negotiate with the
sending device, and provide t.30 compliant signaling.
- The notion of using the internet as a transport mechanism for t.30
doesn't make a great deal of sense to me, but this should be explored
non-the-less, for the case where a group-3 machine communicates directly
with a group-3 receiver.
- We would need a final confirmation that the message was received
to be (optionally) returned since knowing that the gateway received it
correctly provides little assurance that it makes it to the final destination.
- The final destination of such a transmission would be
unrestricted. It is likely that many people would prefer to receive these as
email with g3fax MIME attachment.
- Would therefore require some extension or enhancement to T.30 to
allow an arbitrary email address to be added. This brings up the issues
mentioned by Mike Lake, although I presume that use of the subaddress (SUB)
frame would be the best solution, all patent claims aside.
- Changes and method for using T.30 for this purpose would involve
TR29.1
1b) Group 3 fax machine "receiving" and (probably) printing
-----------------------------------------------------------
a fax image (or "Print Job") from the internet.
-----------------------------------------------
- would require some sort of gateway device to negotiate with the
receiving device, and provide T.30 compliant signaling.
- Most group-3 fax machines will provide a variety of capabilities,
where the lowest common denominator is OK as a last resort, but most users
will prefer improved resolutions and rendering capabilities. T.30 has
provided a negotiating method which allows these options to be resolved to
the descretion of the sender (within the capabilities of the receiver). The
"Gateway" device would need to be able to convert formats or select an
appropriate one within some policies of the service provider.
- The status of the fax transmission (ok, error, etc.) is then
communicated back to the original source by the gateway. Some issues
regarding bogus calls and "blacklists" come into play here. If you send
faxes frequently, you know that determining the cause of a failure sometimes
requires listening to the results on the line.
- The origination of the fax would be unrestricted.
- It is likely that conversion of other formats to that needed by a
group-3 device could be performed by the "gateway" service provider. This
includes conversion from various MIME media-types, such as text/plain and
application/postscript. If the target device has these printing
capabilities, then such conversion may be handled by the target device.
- Changes and method for using T.30 for this purpose would involve
TR29.1
2) Changing the Protocol on the PSTN from T.30 to internet-based protocols.
---------------------------------------------------------------------------
- Some thinking on this issues is presented in
<ftp://ftp.cts.com/pub/MFPA/t30layer.w> (Winword 2.0 format),
as presented to the TIA TR29.1 committee. The referenced paper
describes some ideas about lower-layers of the protocol and how it would
coexist with the existing T.30 protocol (using V.8bis to switch between),
however the details of the interaction at higher layers (http, vs. smtp,
etc.) are TBD.
- When used, this would allow a machine with these enhancements to
become a limited "node" on the internet for the purpose of interacting with
a sending entity as a receiver (or printer), or initiating an image
transmission from the scanner (or attached computer).
- Other neat things that have been "issues" in the facsimile
community could then be handled "cleanly", such as determining the correct
mailbox (i.e subaddress) for a given user on the destination network.
3) Establish communication to a Local-Area device using Internet compatible
protocols.
---------------------------------------------------------------------------
----------
- A key focus for the MFPA has been improving the connectivity of
"fax machine"-like devices, commonly known as MFPs, multifunction peripherals.
- Using PPP on a given local connection and then layering other
protocols withing this framework (such as TCP/IP and others) will allow the
local device to serve as a gateway to the internet, or to communication with
conventional Group 3 T.30 devices. When used as a gateway to the internet,
the final destination may be a printer or other terminal device that would
fall into cases (1b) or (2) above.
- This device tends to look alot like the gateway device of (1b) if
indeed the device exists as a internet node, at least for the purpose of
sending to group-3 devices. It also looks like device (1a) for the purpose
of receiving faxes from group-3 devices.
- Therefore, if we solve cases (1a) and (1b) above, we go a long way
toward providing a flexible and internet-aware solution to the operation of
such MFP devices. The solutions to (1a&b) is necessary but not sufficient
for the operation of these devices. Therefore, additional capabilities would
also probably be warranted.
================
OK, I guess that is a long enough message to get started. I propose that the
work that is done (whether in this group or in others) primarily be focused
on alternative 1. There is related work that we should be aware of:
- A proposal has been made to include the printer interpreter
languages as documented MIME media-types. When treating the (1b) gateway as
a "printer" or if the final terminal is capable of providing printer-like
rendering, these media-types may be handy. The printer working group
<http://www.pwg.org> has done significant work in this direction, especially
in the generation of the printer MIB
<http://ds.internic.net/rfc/rfc1759.txt>. I will be generating a "profile"
for mapping the printer MIB's prtInterpreterLangFamily and ...Version to
acceptable MIME media-types.
- Recently, the Document Printing Application (ISO-10175 "DPA") has
been used as a source of information to generate a number of printer-control
languages by a number of companies, such as Novell, Xerox, and IBM. These
control schemes are based on Internet protocols and RPC and XDR-style
information transfers or ASN.1. Such a control paradigm may be important for
controlling the (1b) gateway, or controlling a final printer device,
(possibly in an MFP) such as in (3). I think MFPA may be championing this
effort in the future.
- The printer working group (http://www/pwg.org) has been working on
a "Job Monitoring MIB". I don't believe this is IETF sanctioned yet as a
working group in this regard.
I'm sure there is other work, and if anyone knows of any, I certainly would
like to know of it to make sure that we aren't reinventing the wheel.
-Raymond
/***********************************************************************
** Raymond Lutz Voice: 619-447-3246
** Director R & D, Cognisys, Inc. Fax: 619-447-6872
** MFPA EC Chair BBS: 619-447-2223
** 1010 Old Chase Ave., Suite B EMail: raylutz at cognisys.com
** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA
** WWW: http://www.cognisys.comhttp://www.mfpa.org
***********************************************************************/