IFX Mail Archive: IFX> BOF Meeting minutes ... corrections?

IFX Mail Archive: IFX> BOF Meeting minutes ... corrections?

IFX> BOF Meeting minutes ... corrections?

Richard Shockey (rshockey@ix.netcom.com)
Mon, 05 Apr 1999 15:27:44 -0500

I almost forgot I needed to get the formal meeting notes submitted by Apr=
il 7.

Here are some of the notes I had compiled with some additional assistance=
a report made by Jacob Palme.

If you have any notes from the meeting that I have forgotten to include f=
the meeting ..please send me a note ASAP.



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 =
Quality Document Transmission and Reception.=20

A mailing list has been established to discuss issues related to the topi=
Mail should be addressed to [ ifx@pwg.org ]. To subscribe to the list sen=
d 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=20
[ http://www.pwg.org/hypermail.ifx ]

The meeting began with a general introduction to the problem space and th=
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 Fa=
Internet Fax Technologies RFC 2305 (Simple Mode Store and Forward ) and R=
2532 (Extended Mode Store and Forward), and the Internet Print Protocol [=

It was said at the meeting that these standards aim at transmitting
=93non-alterable=94 documents, but clearly any digital file could be subj=
ect to

The background to this BOF is the belief that the existing PSTN FAX servi=
ce 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:=20

>Low Quality
>Identity exchange Spoofed
>Color practically impossible

IFAX RFC2305 [T.37] EIFAX [RFC2532] E-Mail - Store and Forward Methodolog=
>Not =93point to point=94
>Receipt Repudiation MDN-DSN can be refused
>Capabilities Exchange Difficult=20
Example was given of how does the sender know if the recipient is a Palm =
It was noted that current E-Mail security protocols were difficult to imp=

There was some discussion of whether it could be said that E-Mail based I=
was in fact non-extensible. In fact SMTP has been enhanced and extended o=
time and could be extended in the future. There have been proposals in th=
FAX WG to extend SMTP to a SESSION mode. In this case sender and recipien=
t 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 ser=
to support.
>IPP Firewall issues remain for accepting inbound traffic.

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

SLIDE- IPP 1.1 meets the test of a facsimile service as defined in RFC254=

>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 glob=
service and not strictly enterprise. It has its own URL scheme, IPR:// a=
nd its
own port number, 631.

SLIDE:- What needs to be done to IPP?
>Satisfy legal and =93custom and practice=94 requirements (fax)
>Mandate currently optional IPP attributes: TIME/DATE logging of transact=
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 attr=
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
=93document Delivery=94. IPP was mapped on top of HTTP, in order to be ab=
le 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 =
allow printers outside firewalls. But firewalls can be reconfigured.

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

SLIDE - What=92s really needed?
>Application examples that need reliable trusted Document Transmission =20
- Court Filings=20
- SEC Registrations=20
- Contract execution=20
- Billing=20
>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 g=
o to
Standards Track and IPP has already held several interoperability forums.
Additional discussion was made to a SMTP "session mode" delivery mechani=
Suggestions were made that the proposed WG first engage in a "due diligen=
process to determine which protocols might be the most suitable for furth=

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

Chair noted T.38 does not have an addressing schema like the use of URLs =
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

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 goa=
with RFC2542 (Terminology and Goals for Internet Fax).

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

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

In particular much market survey research that indicated that receipt or
confirmation of delivery is the #1 thing that people like about Fax. Some=
that the ability to repudiate a DSN or MDN message request is holding bac=
market acceptance for internet fax services and that something different =
to be devised that more closely approximates the "look and feel" of exist=
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 it=
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=
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 provi=
de and
which e-mail, which IFAX is using, cannot provide. Some people call this
"session" but many participants did not like that designation.=20

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

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

The meeting concluded with the chair promising to quickly rework the prop=
charter for IESG approval.=20

Richard Shockey
Shockey Consulting LLC =20
8045 Big Bend Blvd. Suite 110 =20
St. Louis, MO 63119
Voice 314.918.9020
Fax 314.918.9015
INTERNET Mail & IFAX : rshockey@ix.netcom.com
eFAX 815.333.1237 =20