2.1.15 Internet Print Protocol and Internet Fax (ipp2ifax) bof

Current Meeting Report

Minutes of IPP2IFAX BOF

IETF 43 Minneapolis, Minnesota
Monday March 16, 1999 9AM -10 AM

Richard Shockey, Chair

Reported by Richard Shockey.

Approximately 35-40 people attended the BOF to discuss issues related to High Quality Document Transmission and Reception.

A mailing list has been established to discuss issues related to the topic. Mail should be addressed to [ ifx@pwg.org ]. To subscribe to the list send mail to [ majordomo@pwg.org ] with the line [ ifx subscribe yourname @address.com ] in the body of the message. An archive of the list is available at
[ http://www.pwg.org/hypermail.ifx ]

The meeting began with a general introduction to the problem space and the desire to settle on a proper name for the proposed work group.

The discussion began with a general review of existing technologies and protocols that relate to the transmission of documents, including GSTN Fax, Internet Fax Technologies RFC 2305 (Simple Mode Store and Forward ) and RFC 2532 (Extended Mode Store and Forward), and the Internet Print Protocol [IPP].

It was said at the meeting that these standards aim at transmitting "non-alterable" documents, but clearly any digital file could be subject to modification.

The background to this BOF is the belief that the existing PSTN FAX service and the IETF FAX work RFC2305 have severe limitations that do not meet the expectation that end users have for a advanced document delivery service.

Limitations of Current Services SLIDE: Examples:

¬ Analog
¬ Low Quality
¬ Identity exchange Spoofed
¬ Color practically impossible

IFAX RFC2305 [T.37] EIFAX [RFC2532] E-Mail - Store and Forward Methodology:
¬ Not "point to point"
¬ Receipt Repudiation MDN-DSN can be refused
¬ Capabilities Exchange Difficult

Example was given of how does the sender know if the recipient is a Palm Pilot.
¬ Security

It was noted that current E-Mail security protocols were difficult to implement (SMIME& PGP)
¬ Non-extensible

There was some discussion of whether it could be said that E-Mail based IFAX was in fact non-extensible. In fact SMTP has been enhanced and extended over time and could be extended in the future. There have been proposals in the IETF FAX WG to extend SMTP to a SESSION mode. In this case sender and recipient are both essentially SMTP servers directly communicating with each other.

Limitations of Current Services (cont.) SLIDE - IPP [Internet Print Protocol]:
¬ Time not mandated
¬ Identity not required or trusted
¬ No Least common denominator file format required for all clients and servers to support.
¬ IPP Firewall issues remain for accepting inbound traffic.

Discussion proceeded to a more detailed analysis of IPP and its merits as a base line a new super set or profile for Quality Document Delivery Services.

SLIDE- IPP 1.1 meets the test of a facsimile service as defined in RFC2542.
¬ Creation (PDL Stream
¬ Addressing (URL)
¬ Negotiation (Get IPP Printer Values
¬ Transmission (HTTP 1.1 Post)
¬ Delivery Receipt (response on the HTTP POST and/or poll IPP Job Status)
¬ Security (HTTP Digest Auth / TLS)

Upon questioning, the chair indicated that this new work was to be a global service and not strictly enterprise. It has its own URL scheme, IPR:// and its own port number, 631.

SLIDE:- What needs to be done to IPP?
¬ Satisfy legal and "custom and practice" requirements (fax)
¬ Mandate currently optional IPP attributes: TIME/DATE logging of transactions by client and server receipt & acknowledgement
¬ Least Common Denominator support RFC2301 TIFF
¬ Sender Identity Exchange (CSID vs vCard)
¬ Gateway to GSTN-FAX and or RFC 2305-IFAX through the use of new IPP attribute definitions- Example GSTN or E-Mail addresses passed on the wire
¬ Digital Signatures probably optional
¬ Cover Pages

IPP was discussed in some detail. IPP was designed for printing and not "document Delivery". IPP was mapped on top of HTTP, in order to be able to pass firewalls, but most sites do not allow inbound HTTP, which IPP needs. One solution is to put the printer outside the firewall, but most offices do not allow printers outside firewalls. But firewalls can be reconfigured.

Suggestions were made to also emphasize privacy and authorization. It was noted that IPP already supports Digest Authorization.

SLIDE - What's really needed?
¬ Application examples that need reliable trusted Document Transmission
- Court Filings
- SEC Registrations
- Contract execution
- Billing
¬ Some similarities with EDIINT concepts.

Differences between printers and fax machines: Fax machines acknowledge messages and time-stamps them

IPP is in a advanced state of development with the ID documents soon to go to Standards Track and IPP has already held several interoperability forums. Additional discussion was made to a SMTP "session mode" delivery mechanism. Suggestions were made that the proposed WG first engage in a "due diligence" process to determine which protocols might be the most suitable for further work.

Comments were made that the existence of this work should be revealed to ITU Study Group 8 at the earliest possible date in accordance with IETF/ITU cooperation agreements outlined in RFC 2436 and avoid possible conflict with T.37 and T.38.

Chair noted T.38 does not have an addressing schema like the use of URLs in IPP. Chair indicated that given the nature of T.38 [use of H.323] in all probability T.38 would be limited to use as a gateway interoperability standard.

SLIDE - Goals and deliverables:
¬ Reliable Document mode of IPP
¬ IPP Gateway Services

During a discussion of milestones a proposal was made to merge new WG goals with RFC2542 (Terminology and Goals for Internet Fax).

It was suggested from the floor that a specific set of design goals needed to be debated. There was general consensus after much discussion that any new service must concentrate on several goals, specifically

A. Timely Delivery,
B. Security
C. Quality of Output
D. Legal Identity Exchange
E. Capabilities Exchange.
F. Proof of Delivery (Receipt).

In particular much market survey research that indicated that receipt or confirmation of delivery is the #1 thing that people like about Fax. Some felt that the ability to repudiate a DSN or MDN message request is holding back market acceptance for internet fax services and that something different needs to be devised that more closely approximates the "look and feel" of existing fax and has the ability to be quickly extended in the future.

It was noted that the IETF FAX WG work is very valuable ... especially its ability to integrate with Universal Messaging, but there needs to be a alternative, especially one that is more "point to point" and has a clear and unambiguous method of determining receipt.

The main difference between the proposed WG and IFAX is confirmation of delivery at the time of transmission, which IPP may be extended to provide and which e-mail, which IFAX is using, cannot provide. Some people call this "session" but many participants did not like that designation.

"While-you-wait" or Timely, Confirmed, Negotiable (TCN) were suggested. TCNDOCS a possible name for WG.

NOTE: Based on discussions after the meeting the new name of the proposes WG will be QUALDOCS.

A show of hands indicated strong consensus in developing this work group with no dissension. A request for editors identified a number of individuals willing to participate.

The meeting concluded with the chair promising to quickly rework the proposed charter for IESG approval.


None received.