Subject: [IETF-FAX] draft meeting minutes at Adelaide

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 27 Apr 2000 08:40:39 +0900 (JST)

Dear colleagues,

Sorry for being late. Our draft meeting minutes are below.

Would you please check, correct and modify it, as soon as possible ?
                                               ^^^^^^^^^^^^^^^^^^^

############ Begin #############

-------------------------------------------------------------------------
-------------------------------------------------------------------------
IETF FAX-Ext Group meeting was held at 15:30-17:50 on March 30.

------------------------------------------------------------------------
1 Opening
------------------------------------------------------------------------

New co-chairs(Mr. Allocchio and Mr. Tamura) introduced themselves.
They thanked the out-going chair, Mr. Rafferty and the achievements
of our working group.

The meeting agenda itself was introduced and accepted.

------------------------------------------------------------------------
2 Charter
------------------------------------------------------------------------

This is the first meeting since new charter was created. New charter
was discussed.

Concerning the phrase "full equivalence of T.30 service", a question
about the relation with T.38 was raised. T.38 describes the procedure
for Real-Time G3 fax over IP networks. It is NOT a service over
Internet mail, which Fax working group has been studying for years.
The group confirmed to continue the study of the specification
that is equivalent to T.30 service over Internet mail.

There was an opinion that the phrase "universal messaging issues"
should move and be included in the first sentence
in the first paragraph. The group agreed it.

[[[Allocchio-san will modify this part to the suitable ones.]]]

Concerning interconnecting the GSTN fax services, there are onramp
and offramp gateway related issues. But they have not been deeply
discussed so far in the group. The group confirmed there are things
to do for these issues.

The group confirmed the Implementers' Guide is useful for quality
of service.

The group confirmed FFPIM is a base for equivalence of T.30 service.
It includes capability negotiation, in which a sender can transmit
the "best" fax image the receiver indicates. There was an opinion
about the use of RESCAP protocol for negotiation.

A question about document authentication issue was raised. There are
PGP, S/MIME, digital signature, and so on. The group confirmed to study
the authentication under FFPIM.

Related to FFPIM, the group confirmed TIFF-FX extensions like JBIG2
should be included. The target date of initial drafts of the extensions
was modified as Jun 2000. Concerning the schema, it remains Sep 2000.

The group confirmed to continue the cooperation with ITU-T and
other IETF WGs such as VPIM.

The group agreed to the charter. Modified charter will be circulated.

------------------------------------------------------------------------
3 Status of internet drafts
------------------------------------------------------------------------

1) Internet drafts waiting for RFC

- draft-ietf-fax-feature-schema-v2-01.txt
- draft-ietf-fax-feature-T30-mapping-03.txt

The chair introduced these are in the queue by IESG review and
will be approved soon.

2) Internet drafts waiting for Draft Standard.

- draft-ietf-fax-tiff-fx-04.txt

The chair introduced the interworking report was circulated
and there are no problems. ADs will review it. Related to
this document, the status of draft-ietf-fax-tiff-regbis-00.txt
(Updated RFC2302)was introduced.

[After the meeting:
The out-going chair(Mr. Rafferty) told this draft is dependent
on RFC2302. He suggests draft-ietf-fax-tiff-regbis-00.txt should be BCP,
because it only contains the IANA registration information.]
 
- draft-ietf-fax-service-v2-01.txt

There are dependency problems(DSN, IMAP4 and Addressing).
Concerning DSN, there is one idea in order not to be dependent on DSN.
It was circulated in ML. For others, the group confirmed to wait for
being Draft standards. The right format of the results of Interworking
(FaxConnect2) is necessary. Mr. Ohno, who was responsible for
FaxConnect2 at Japan, will report it with other key people.

- draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt

Interworking is not enough, especially for /T33S issue.
T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress).
It is kind of an application profile. There are fax machines
that support T.30 SUB signal. But there are very few implementations
about T.33. A question was raised about how to validate
if two independent implementations interwork for addressing.
About this question, there was an opinion it is that gateways can
handle the specified address correctly.

------------------------------------------------------------------------
4 On-going Internet drafts
------------------------------------------------------------------------

1) draft-ietf-fax-ffpim-00.txt

Mr. Crocker introduced it.

FFPIM abbreviates Full-mode Fax Profile for Internet Mail.
This specification defines "full mode" carriage of facsimile data
over the Internet, building upon that previous work and adding
the remaining functionality necessary for achieving reliability,
timeliness and capability negotiation for Internet mail that is
on a par with classic T.30 facsimile.

About timeliness, it refers to draft-ietf-fax-timely-delivery-00.txt.
About capability negotiation,
it refers to draft-ietf-fax-content-negotiation-01.txt

2) draft-ietf-fax-timely-delivery-00.txt

Mr. Klyne mainly introduced it.

This specification defines a set of capabilities which permits
an originator to request that the email transport system give
a particular timeliness in delivery and then assures if the system
will report the success or failure of that request.

Specifically, it provides "while you wait" delivery of a message,
with overall end-to-end transmission times of similar order to those
for fax(seconds rather than minutes). It is also designed to operate
within the ESMTP extension framework, allowing the sender to decide
fallback to traditional e-mail if timely delivery service
is unavailable.

This can be achieved by the three ESMTP extensions(DSN, DELIVERBY,
CONFORMANCE-REQUIRED). DELIVERBY imposes a responsibility on MTAs
to complete delivery within a specified time. CONFORMANCE-REQUIRED
imposes responsibility on MTAs to complete delivery in conformance
with stated requirements, or not to deliver the message.

There was the following comments about timelines.
Page-by-page confirmation like T.30 cannot be done.
Those kinds of confirmation are not necessary over Internet-mail.

There was an comment that all MTAs should be changed to configure it.

Mr. Klyne also commented the reverse(DSN return) path is not
considered now and it should be done for complete timeliness.

3) draft-ietf-fax-content-negotiation-01.txt

Mr. Klyne mainly introduced it.

This specification uses a post-hoc technique that permits an originator
to send the best version known by the originator to be supported
by the recipient and then sending a better version
the recipient requests it.

There are the following goals.
- Normal behavior with ordinary e-mail
- No "administrative non-messages"
- Work with current simple- and extended-mode fax systems
- Recovery from stale cached capability information
- Possible low-memory device implementation

Sender specifies MDN option "Alternative-available" and alternative
features in "Content-alternative". Receiver indicates "alternative-
preferred" disposition-modifier-extension and its capabilities in MDN.
Sender selects alternative format based on receiver's capabilities.
Negotiation case example and optimized one were introduced.

A question was raised about negotiation mechanism. Mr. Klyne emphasized
it is sender who judges the capabilities indicated by receiver and
selects the format. He also notified the Receiver's state issue.

4) draft-ietf-fax-implementers-guide-01.txt

Ms. Cancio introduced it.

This guide addresses implementations of the followings.
- RFCs 2305, 2532, 2301
- RFC 2298 in connection with RFC 2532 
- Others related as needed

Users want to know if returned MDN indicates Main body text or 
TIFF attachments. There are no suitable disposition-types. This draft
describes guides on how to express, using the existing definitions.
It also describes TIFF interoperability issue, including the issue of
low-end limited memory embedded recipients.

There are controversies that how many TIFF problems should be included
and if examples should reflect desired best practice to
accomplish model or not.

There were suggestions on Subject field and first part text of MDN
as follows.
- Subject
"Return Receipt:", followed by original subject field text
"Disposition Notification:" followed by original subject field text
- First part text
"This is a Return Receipt for the mail that you sent to  … etc.
The message and attached file may have been printed or saved.
This is no guarantee that the message has been read or understood."

There was an indication as open issues that MDN new disposition-types
(e.g. "telephone line busy" etc.) and MDN message part identification
(main body vs. attachment etc.) should be addressed as standard track
(other internet drafts). There were the following comments. In other
mail applications, there are similar issues. MDN extension is considered
in other WGs. 

The group confirmed to refine this draft.

------------------------------------------------------------------------
5 TIFF-FX extensions
------------------------------------------------------------------------

Mr. McIntyre introduced Tiff-fx extensions.
There are the following two extensions.

1) New field values and/or relaxed constraints

- higher resolutions
300x600, 600x600, 400x800, 600x1200 and 1200x1200 are introduced.

- MRC (more than 3 MRC layers)
Arranged in mask and foreground pairs.
It is beneficial to synthetic images.

- MRC (multi-strip background and foreground layers)
It is to reduce overhead of IFDs when there is no change
in coding parameters between strips (i.e. cases where multiple IFDs
are not needed and a single IFD will do) by removing
constraint requiring separate IFD for each TIFF strip 

2) New fields and/or profiles

- More than one profile within document
. allow use of more than one profiles within a document
. add new MultiFaxProfile field to the GlobalParameters IFD
. use of the MultiFaxProfile field is signaled
by a FaxProfile field value of X'FF'

- JBIG2 (T.88) (Black and White, Color)
JBIG2 boosts compression of text-like documents by 3x or more
by retaining similar shapes across multiple images. There are 3 ways
in which JBIG2 may be used in TIFF-FX. One is in B&W case and two
are in Color case. Two new profiles, 3 new fields and a new value
for an existing field may be required to accommodate the three usage

- Annotation
It brings life to raster images by accommodating a limited level
of editability. The result is increased desktop citizenship and
a significant step towards realization of integrated messaging.
There are 3 forms(information annotation, quality annotation and
tag annotation) of annotation to be considered. New fields and
new values for existing fields may be required to accommodate
the three forms.

He will submit the internet-drafts.

------------------------------------------------------------------------
6 Fax Gateway issue
------------------------------------------------------------------------

Mr. Kitagawa explained new proposal with the use of HTTP and CGI,
concerning Fax Offramp issues.

In his ideas, users put only a telephone number into a device which is
connected to Internet. The device accesses to a directory server and
resolves the addressing information for the number by getting it from
the directory server. He emphasized the gateway local policy.

This issue may possibly be solved in ENUM WG. The group confirmed
the discussion should take place in both Fax WG and Enum WG.
No internet draft exists. Therefore, he will submit the internet-draft
about it.

------------------------------------------------------------------------
7 ITU-T issue
------------------------------------------------------------------------

There was no time to introduce ITU related matter, as scheduled.
Therefore, the chair promised to circulate this issue in ML soon.

[After the meeting:
The chair circulated the report of February SG8 meeting and
the information of re-organizing ITU-T in ML. Q4/SG8 confirmed to
continue cooperation between IETF Fax WG and them. They will
be merged into new SGs and continue to study. Plan for T.37 extension
such as support for Full-mode enhancements, new image compression method,
and T.37 gateway functionaliy was introduced. The group agreed to
send a letter and Implementer's Guide draft to Q4/SG8.]

------------------------------------------------------------------------
8 Closing
------------------------------------------------------------------------

The meeting finished.

############ End #############

--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-46-228-1743  Fax: +81-46-228-7500 (SUB/F-code 5727)