Here are some of the notes I had compiled with some additional assistance=
from
a report made by Jacob Palme.
If you have any notes from the meeting that I have forgotten to include f=
rom
the meeting ..please send me a note ASAP.
TKS.
######################
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.=20
A mailing list has been established to discuss issues related to the topi=
c.
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=
e
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=
x,
Internet Fax Technologies RFC 2305 (Simple Mode Store and Forward ) and R=
FC
2532 (Extended Mode Store and Forward), and the Internet Print Protocol [=
IPP].
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
modification.
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
Fax:
>Analog
>Low Quality
>Identity exchange Spoofed
>Color practically impossible
IFAX RFC2305 [T.37] EIFAX [RFC2532] E-Mail - Store and Forward Methodolog=
y:
>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 =
Pilot.
>Security
It was noted that current E-Mail security protocols were difficult to imp=
lement
(SMIME& PGP)
>Non-extensible
There was some discussion of whether it could be said that E-Mail based I=
FAX
was in fact non-extensible. In fact SMTP has been enhanced and extended o=
ver
time and could be extended in the future. There have been proposals in th=
e IETF
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=
vers
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 Servic=
es.=20
SLIDE- IPP 1.1 meets the test of a facsimile service as defined in RFC254=
2.
>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=
al
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=
ions
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=
ibute
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 =
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=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=
sm.
Suggestions were made that the proposed WG first engage in a "due diligen=
ce"
process to determine which protocols might be the most suitable for furth=
er
work.=20
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 w=
ith
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.=20
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=
ls
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=
w
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=
felt
that the ability to repudiate a DSN or MDN message request is holding bac=
k
market acceptance for internet fax services and that something different =
needs
to be devised that more closely approximates the "look and feel" of exist=
ing
fax and has the ability to be quickly extended in the future.
=20
It was noted that the IETF FAX WG work is very valuable ... especially it=
s
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 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=
CNDOCS
a possible name for WG.
A show of hands indicated strong consensus in developing this work group =
with
no dissension. A request for editors identified a number of individuals w=
illing
to participate.
The meeting concluded with the chair promising to quickly rework the prop=
osed
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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<