Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/fax/fax-minutes-97apr.txt

Text File | 1997-05-29 | 13KB | 307 lines

Editor's Note:  These minutes have not been edited.



Minutes for IETF working group on FAX, April 10, 1997

Dave Crocker, James Rafferty, co-chairs.

Reported by:  Larry Masinter and James Rafferty

Topic:  Related Activities

James Rafferty reported on related activities in other standards bodies
and consortia:

1.  Study group 8 of the ITU has established a set of objectives which
include the intent to work on a session-based mode of fax over
Internet and a store & forward mode.

2.  The "voice over IP" group of the International Multimedia
Teleconferencing Consortium is not actively working on fax over the
Internet, according to consortium President Neal Starkey.


The agenda included a review of several topics which related to the
potential components of messaging based Internet Fax.

Topic: Confirmation

A feature that's important for fax is the ability to get a
confirmation. It is viewed by many as a fundamental
requirement.

Internet mail has two kinds of activity with respect to confirmation:
Delivery Status Notificaiton (DSN) and Receipt.

DSN is delivery time confirmation, as fully specified in RFCs
1891-1894. You know when the message has been delivered, but not when
it is read, processed, printed.  The question was raised on whether
this is sufficient for Internet Fax.

Receipt acknowledgement is at least 1-3 months from "proposed
standard".  It is a notification that the recipient has 'handled' or
processed the message. It has more semantics. There is less
operational history. A Message Disposition Notification (MDN) says
how the message was processed.

Most people in the room think that DSN is adequate to emulate what a
fax machine does today. DSN is interesting from the point of a service
provider, and receipt may provide added value.

A straw poll taken on the following question:

Question: should we mandate support for DSN (when requested
by sender), explore (not make a decision now) support for
MDN?

The consensus of the group present was to mandate support for DSN
in messaging based Internet Fax.   There was some interest in
exploring MDN for later use.

Topic: Data Content

The group reviewed the alternatives for data formats:
  Tiff-F, Tiff-Plus, PDF

* Tiff-F Draft 01 Review

There was an overview of draft issued 4/2/97, by James Rafferty & Glen
Parsons. (The draft missed Internet-Drafts deadline, but was sent to
list).  James presented slides that summarized the key changes from
previous draft.

TIFF-F was originally the product of an informal working group in the
fax community to produce a document file format that could be
implemented by them, and then has been in use for 5 years. The goal of
the TIFF-F draftocument has been to document TIFF-F with some minor content
adjustments in the areas of paper sizes and resolutions to provide
consistency with ITU fax recommendations up to the 1993 level.

James also responded to some of the comments from the ietf fax list
regarding the 01 level draft:
 - Intent to phase out "class" and use "application"
 - There were some difficulties with the term "default" in
   the TIFF-F draft vs "baseline" in TIFF. They need to
   do some editorial work to fix that up.
 - There were some differences between typical TIFF-F values
   and baseline TIFF defaults, and they need to make those
   clear.
 - Byte alignment: confirmed that TIFF-F historically has
been byte aligned

Question: is it intended that legacy TIFF-F readers will work?

It was confirmed later in the meeting that it is highly desirable to have
compatibility with
existing TIFF-F readers.

Lloyd McIntyre presented the slides on the Tiff-FX format:

Current practice in fax MH/MR (T.4) MMR (T.6), JBIG (T.82) plus color
representations: T.42 JPEG (T.81), JBIG (T.43), and T.44 Mixed Raster
Content.

TIFF-FX addresses all of image formats specified to date by the ITU-T
for facsimile.   Part of the goal is to enable the
migration of black & white fax to full color by taking advantage of
the Internet.

The primary idea is to create one Internet Fax TIFF spec, with
conformance documents to capture practices. The goal is to separate
out the application needs.

Q: Can we have two formats? A: Yes.

Steve Zilles presented slides on the concept of PDF as a fax file format.
TIFF is great, but
it is a raster format. While fax today is raster, tomorrow fax may be
more: layering, annotations, recognition. Not raster data. He suggested that
It doesn't make sense to create another compound document format out of
tiff. PDF representation alternatives include: PDF image only,
PDF with original image and hidden text.

Advantages of PDF:
 - published format, multiple implementations
 - rasters + text and graphics
 - cross platform support
 - most relevant compression algorithms (not JBIG)
 - device independent color
 - efficient access/display of pages
 - hyperlinks

There was some discussion on whether PDF could be as freely available as TIFF
and with tools from multiple vendors.  Zilles indicated that there were
no obstacles to this.


Dave Crocker summarized the data content alternatives:
TIFF-F is 'fax today', TIFF-FX is 'fax in the near future', and PDF is
'fax using object oriented data representations".

Questions: What is the relationship between Internet fax, VPIM, WIDE,
legacy? What's the difference in practice between having two specs for
tiff vs a single spec & multiple profiles? There was a long discussion
of the alternatives.

Glen Parsons noted that the VPIM work is nearing completion and would
like to be able to reference TIFF-F to support exchange of fax
attachments.

Question: what are the Intellectual Property Rights issues?

Steve Zilles of Adobe will send this in a mail message to the list:
"Basically, Adobe is in the position of trying to facilitate
the exchange of information. Postscript, PDF, and TIFF, there
will be a printed license to implement to the specification
with no charge. Ghostscript has a PDF rasterizer ("free" software),
Adobe is reserving the copyright on the specification itself.
TIFF has full implementations. PDF references technology that
is proprietary by others. Perhaps there are some compression
mechanisms and encryption mechanisms that might be part of
the 'profile' for PDF. There is no problem referencing PDF publishing
information."

There was a discussion on the relationship between data content and
capabilities negotiation.   One approach is to specify a minimum format
that is required and possibly use negotiations to go beyond the baseline.
There was no clear outcome on the matter of negotiations at this time.

The discussion concluded as Dave Crocker surveyed to room to check for
consensus.

There was a consensus among those present that the baseline values of
TIFF-F should constitute the minimum mandatory level of data content
support for messaging based Internet fax.   The intent was that Internet
Fax applications would support at least the baseline values for TIFF-F
that are compatible with historical TIFF-F applications.

There was some interest in raising the baseline to include a range
of resolutions and paper sizes (for example, these are optional values
in the TIFF-F 01 draft to support these additional resolutions and paper
sizes).   It was suggested that ideas on an enhanced baseline and on
related use of negotiations be pursued on the list.

There was some additional discussion about whether it was best to support
the two TIFF formats (TIFF-F and TIFF-FX) in a single or multiple
documents.

Most people in the room had a strong opinion about image
formats; after some reminders from the chair about IETF 'voting' (that
final decisions get made on the list) and several different
attempts to poll the room for opinion, the consensus from most (but not
all) present was to create a single TIFF document which merged the
content of the two TIFF drafts (TIFF-F and TIFF-FX), where TIFF-F
would be the baseline as agreed previously.

There was also a suggestion that it be possible to support alternatives in
format
choices and multiple formats as input; this discussion was deferred to the
list.

Addressing: (25 minutes)

There was a discussion of the C. Allochio draft, resubmitted to the list
shortly before the meeting.  This offers an addressing mechanism for
interworking between telephone numbers
and email-based address, such that on the left hand side of the
address, the telephone number plus subaddress, and some pieces that
provide compatibility with Mixer & X.400 world.

There was interest in having a simple form for 'internet fax' addresses,
without too many quoted expressions and keyword value forms.  The question
on the need for
mixer compatiability was raised.   Claude argued that we should not break
the Mixer compatibility. Some of the
draft was based on a survey of actual practice in X.400
community. Claude asked for opinion of the group for how we should
work.  James points out that there are 80 million fax terminals, none
of which have alpha keyboards but only have numeric keyboards. The
address must handle the telephone number case, and that it was argued
that at least we should handle telephone number addressing and maybe
subaddressing.

Analogies were made between the Internet and the phone system: the phone
 system has a universal address space and allows designation of service
providers.
The phone system considers the location of the switches and gateways as
private
information.  Phone addresses consist of digits.

A question was raised on where to put 'relay' information in an Internet fax
address. The tpc.int approach puts the relay information in the DNS.
The second approach puts the phone number on the left hand side & the
 relay on the right hand side.

Keith Moore noted that putting the relay name in the address has had a lot of
problems in mail relays. The phone number is a
universal address space that is shared by everyone, but you're allowed
to specify a service provider. Keith proposed that there be
be two possibilities, one of which is a provider-less address, and one
of which specifies a provider.

This portion of the addressing discussion was inconclusive, so further
discussion on Internet Fax addressing requirements was deferred to the list.

Topic: URLs for Fax

Dan Zigmond presented a proposal for Fax URLs, which is found in Internet
Draft "draft-zigmond-media-url-00". These are not
meant to be a way to address faxes, but offer a way that
a web browser could provide a link to a fax device.

The proposal is:
  fax://country-code/region-code/fax-number, e.g.,
  fax://1/510/3372950

This syntax is designed to be compatible with the URL syntax for absolute
and relative addressing.

There was some discussion.   There were a number of suggestions for looking
up other standards
that might provide an extended syntax for telephone numbers. James
suggested that the syntax should read
"fax-address", rather than fax-number, allowing for a subaddress.  There
are some issues with defining a telephone number in a way that actually is
"uniform" no matter where you are calling from.

Within the room, many people thought that syntax for a fax URL would be
useful. There wasn't consensus on this syntax. However, the main interest
seemed to be in monitoring and commenting
on the work, rather than pursuing it within the working group at this time.

Transport: (15 min)

Neil Joffe presented some information on a draft that is about to be
submitted (hardcopy was passed out at the meeting).  It specifies some
extensions to ESMTP for session-based capabilities, which could include in
what is
fall-back to store and forward, with facilities that include capability
negotiation, delivery notification, etc.

The draft proposes extending MAIL FROM with an annotation that real
time fax is requested.  It adds capability exchange within that for
negotiation in advance of capabilities for MMR, MR, etc.

Real-time capabilities negotiation is taken into account and the
gateway into the PSTN has the capability of doing format conversion
and fax conversion, where the power can be in the gateway, which
allows the delivery of real-time fax to multiple recipients.

Since this is a new topic, it will discussed further on the list.

There was no time left in the meeting to discuss the remaining item on
the agenda, regarding the development of an Internet Fax Messaging
draft.

*------------------------------------------------*
James Rafferty
President, Human Communications
12 Kevin Drive
Danbury, CT  06811-2901
USA
Voice/Fax:  [phone]
Email:  [e-mail]
     [e-mail]
*---------------------------------------------------