short notes from the FAX meeting

Short notes from the Internet Fax WG meeting

Hallo,

here are my usual quick short notes about our meeting which was held
jointly with the Voice Profile for Internet Mail WG, last Tuesday, July 16
2002. Please drop in your comments/updates.

After wecoming the partecipats to his home town Yokohama, Tamura-san
proposed to change slightly the order of the agenda discussion, moving the
CONNEG and FFPIM topics at the end of the Fax part of the meeting. The
change was approved unanimously, in order to allow more space to these
topics without compressing the other ones. We also received apologises
from Ned Freed who could not be with us, but Patrick Falstrom is here
replacing him.

Tamura0san reported that the following documents are already in the
RFC editor's queue:

- draft-ietf-fax-implementers-guide-08.txt
- draft-ietf-fax-content-negotiation-05.txt
- draft-ietf-fax-tiff-regbis-05.txt
- draft-ietf-fax-tiff-fx-reg-01.txt

and assured the WG that the chairs are taking action with the RFC Editor
in order to have the RFC number assigned ASAP (i.e. prior to publication)
to the TIFF-FX/TIFF couple of documents. It is needed for reference in
oter documents, and by the ITU, too.

Following, Tamura-san presented the list of documents whose IETF last call
was completed without significative comments:

- draft-ietf-fax-gateway-protocol-08.txt
- draft-ietf-fax-gateway-options-05.txt
- draft-ietf-fax-service-v2-05.txt

These ones refer to DSN (RFC1894 update) and to TIFF-FX
(draft-ietf-fax-tiff-fx-11.txt). Greg Vaudreuil reported about the status
of DSN: after IANA questions were answered in April, and an extended
implementation report submitted in early June, the document is
currently on IESG table, without any apparent outstanding issue. The
AD will check its status, too (see slides).

The ID draft-ietf-fax-tiff-fx-11.txt is waitig for the supplementary
implementation report to be published (see later on).

On the IESG queue (Area Director review stage) we also have
draft-ietf-fax-timely-delivery-05.txt. There were no comments and
modification since the last meetings, thus we just wait for the AD review
and for the reference to draft-vaudreuil-1983ext-01.txt to be solved. The
latter status was also updated by Greg: very similar situation than DNS,
no outstanding issues, and waiting for AD review before going to the IESG
table.

The discussion then moved to the TIFF-FX implementation report.
The original report and the additional (new) report to be submitted.
Tamura-san explained (see slides) that the CIAJ (Communications and
Information network Association of Japan), whose members practically
contain all the fax manufactures, agreed to perform an extended further
IFax and TIFF-FX implementation test, to supplement the original report
already submitted in 2001 for Profile S, F and J. In the TIFF-FX and IFax
test are taking part Oki Data, Canon, Kyocera Mita, Sharp, Toshiba-Tec,
NEC, Fuji-Xerox, Brother, Matsushita, Minolta, Murata and Ricoh. The
testing for Profile C, L and M is planned. Some testing for Profile C was
done successfully last month, and the remains will be done by the end of
August. The supplementary report will include Specified product name,
Supported tag information, License validation for some profiles, and will
be submitted by the end of September. Patrik explicitly reminded that the
license statement should specify that the company has exercised also the
proof of "independend licensing" in implementing their products.

Claudio then made a short report About the addressing
(draft-allocchio-gstn-03.txt) documents. After the last meeting and the
suggestions from the WG, version 03 was published in March.  The only
difference from version 02 was that the "implementer's note"  regarding
'pause' and 'tonewait' was turned into a reccommended (SHOULD, MAY)
implementation specification. As there were not further comments, and a
numver of IDs are starting to use the docuement as a reference, the ADs
decided to issue the IETF last call: the request was submitted on July
15th.

Toyoda-san reported on the ID in preparation to register IFax service in
ENUM with IANA. The returned DNS NAPTR record will specify an email
address that is to be used for reaching the target system fax mailbox. The
email address is then used in accordance with “Simple Mode” RFC2305,
“Extended Mode” RFC2532 or FF Patrik Faltstrom, as editor of the
current ENUM NAPTR record specification reported the discussion of the
preceding day at the ENUM wg, where the final syntax was again discussed,
and now the final decsion will be taken on the mailing list. Thus the Ifax
ENUM ID will have to follow the discussion, and conform with it. However
this is not a problem for the IFax case, as we do not require specific
hyerarchical syntax for the resource record data fields. Patrik and the WG
asked the editor now to submit the text of the ID, and discuss it within
the FAX WG, with CC to the ENUM mailing list. Toyoda-san will do it within
a short time.

The next ITU-T SG16 meeting is planned for October 2002. Tamura-san will
report there about our activities. As a WG the documents which are
referenced by ITU-T documents and need some processing are:

  “image/tiff” MIME Sub-type Registra
  “image/tiff-fx” MIME Sub-type Registration
  Implementers Guide

where we are asking the RFC Editor at least for the assignement of the RFC
number. He will also report on the status of the TIFF-FX issue, which
should progress after the supplementary implementation report is submitted
in September.

Claudio passed then to summarize the status of the discussion which
started on the mailig lists after the IETF last call was issued for the
Service Extension for Content Negotiation (please note the new version at
http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt
not yet available at ID repository).

On the mailing lists (including the IETF general one), we saw discussion
which mainly can be grouped under these three major topics:

 - is the proposal doing layreing violations of the model MTA-MUA?
 - how the proposal handles the multi relays case?
 - which is the most efficient/more elegant specification approach,
   i.e. use RCPT TO or another sepcific command and then RCPT TO?

On the mailing list the dabate did not show yet a clear direction, and
the WG discussion should help in clarifying ideas. After this introduction
Dave started the debate, thanking Claudio for his very neutral
introduction of the topics, and explained the reasons why he is convinced
that the current approach taken into the document should be the one to go
for. On the layering violations (i.e. the MTA knowing the MUA capabilities
and keeping information about it to report back to the sender MUA), Dave
suggested that we should be pragmatic, and consider that for most of the
cases where Internet Fax is involved, the final MTA and MUA are on the
same host, and very often are the same piece of software. This mihgt not
be the case in all possible circumstances, but it will quite well fit the
model. Furthermore, most of the Ifax traffic whould be point to point,
without relaying. There were comment reminding that in most of the
corporate cases, this might turne false, as filrewalls and single
entrance SMTP relay are in common use, and this might introduce
complications into the paradigm. After a discussion about the general
model, which showed that there is not a common behavihours expected from
the current SMTP messaging system, the WG pointed out that this is not a
situation specific to Ifax, but it applies in general to all messaging
purpouses, incliding VPIM, MIME etc... Solving the basic philosophycal
problem thus requires the involvement of the whole SMTP area epxertise
people, and not only the FAX WG. The debate on this should this continue
either on the general IETF list, or considered to be moved to the area
covered by the proposed WG on "unified messaging" having a BOF later
during the week (lemonade). The discussion then focused on the
implementation methods, i.e.should we use an option into the RCPT TO
command, and thus use a single command, or should be issue first another
command, and then when capabolities fo the recipient(s) are discovered,
only then issue the set of RCPT TO commands? The aim should be the
efficiency of the interaction in the transport system between MTAs, and
also some MUAs. Dave defended the current specification, where a singl
command (RCPT TO) is used to ask and discover capabilities of the
recipient MUA, while Greg prefered the idea of another command to be
issued before the RCPT TO sequence is started, in order to sort first
recipients depending on capabilities. Claudio, removing momentarily his
chair hat, also supported the single command, in favour of a more
practical, even if probably less elegant, approch. Patrik reminded that
Ned commented a lot on this topic, and at the end asked the WG to come to
a conclusion on this two alternates. Harald, as a member of the IESG, also
reminded that this is the fundamental topic where the IESG should be
convinced of the best solution, and also removing his IESG hat for a
moment, he instead suggested that two separate commands whould do an
easier job for implementors. Claudio reminded that there is no apparent
prevalent opinion on how the current SMTP system behaves, and reminded
that some implementers this the SMTP world is mostly "one recipient per
MTA" when there is not a firewall or similar security measires in effect,
and "many users per relay MTA" where these measueres are in effect. A
query to the ones present in the room showed 2 hands in favour of a simple
command (current specification), 3 hands in favour of using 2 separate
commands and the vast majority of the WG which did not make its ming on
it, yet (the FAX WG is not so good in humming, we use hands). Keeping in
mind that also many other people not present in the room have opinions on
this topic, the further discussion and decision was moved to the mailing
lists involved, including the general IETF list.

After more that 45 minutes of debate we moved to the next topic, FFPIM.
Dave reported the the newest version of the document contained some minor
edits (upon suggestions from Dan Wing), and asked to those presents some
questions:

 - Use of ESMTP options as MAY or SHOULD?
 - FPIM conformance require RFC2305 and RFC2532 conformance?

as there was no clear opinion of those presents, there questions are now
taken to the mailing list for final decsion.

More over, the document refers to CONNEG specification. It was agreed that
the CONNEG text should be more detailed, and that we should of course
adapt it to the output of the dicussion about it.

At this point we handed over to VPIM agenda points, and Glenn Parsons
chaired the rest of the meeting. Note that the FAX and VPIM WGs confirmed
their will to continue with joint meetings until all their work is
finished, and thus will meet agin together in Atlanta, in November 2002.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email protected]
                        Project Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

     PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09