As far as faxing electronic documents is concenred, doesn't printing
over Internet provide a much better solution for the customers? All they
have to do is to upgrade their existing print servers with proper
software, then connect them to Interent via that flat-fee T1 link or
whatever, and start receiving high-quality docs. No need for dedicated
fax machines, or expensive long-distance phone calls; just a right
software solution. Their fax number becomes their print server URL.
Babak Jahromi,
WinNT Printing Dev
Microsoft
>----------
>From: raylutz at cognisys.com[SMTP:raylutz at cognisys.com]
>Sent: Tuesday, September 03, 1996 1:42 PM
>To: ietf-fax at imc.org>Cc: MFPA at mfpa.org; tr29-list at taux01.nsc.com; pwg at pwg.org>Subject: Internet and Fax Interoperabilty: Big Picture
>>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>***********************************************************************/
>>