Subject: draft minutes at Yokohama meeting

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 01 Aug 2002 19:09:59 +0900 (JST)

Folks,

Sorry for my slow action. Attached is the draft minutes.
I modified and added a little for Claudio's "short notes".
Please let me know soon if there are comments.

Claudio,
Thanks again for the detailed notes.
By the way, are the following numbers correct,
regarding ESMTP CONNEG issue?

" 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
...."

"2 hands" and "3 hands".

As the other mails, it seems that they are "1 hand" and "2 hands".
Anyway, there were few hands for both at the meeting.
We can modify like that.

Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG
[email-masked]

---------------------------------------------------------------------

TUESDAY, July 16 at 0900-1130
==============================

CHAIRS:	Claudio Allocchio <[email-masked]>
	Hiroshi Tamura <[email-masked]>

---------------------------------------------------------------------
Opening
---------------------------------------------------------------------
FAX WG meeting was held jointly with VPIM WG, on July 16 2002.
Hiroshi Tamura, co-chair of FAX WG, welcomed the participants at his
home town Yokohama and started the meeting.

---------------------------------------------------------------------
Agenda Bashing and etc.
---------------------------------------------------------------------
Hiroshi Tamura proposed to change slightly the order of the agenda
discussion, moving the ESMTP-CONNEG and FFPIM topics at the end of
the Fax part of the meeting, in order to allow more time to these
topics without compressing the other ones. The change was approved
unanimously. We also received apology from Ned Freed, an Area
Director of Application Area, who could not be with us, but
Patrik Faltstrom, another Area Director, was here replacing him.

---------------------------------------------------------------------
The I-Ds which IESG approved and are in RFC editor's queue
---------------------------------------------------------------------
Hiroshi Tamura 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

He assured the WG that the chairs should take action with RFC editors
and IANA administrators, in order to have the RFC number
assigned ASAP (i.e. prior to publication) to the tiff-regbis and
tiff-fx-reg I-Ds. It is needed for Draft Standard process of
TIFF-FX (RFC 2301) itself as well as the reference in
implementers-guide I-D and ITU-T T.37.

After the meeting, Hiroshi Tamura asked RFC editors and IANA
administrators for their action. Also, content-negotiation I-D
was assigned RFC number and was published. It is RFC 3297.

---------------------------------------------------------------------
The I-Ds for which IETF Last Call was finished
---------------------------------------------------------------------
Hiroshi Tamura 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

Regarding service-v2-05 I-D, it refer DSN (RFC 1894 update) and
TIFF-FX (draft-ietf-fax-tiff-fx-11.txt).

Greg Vaudreuil reported the status of DSN (see slides). After IANA
questions were answered in April, and an extended implementation
report was submitted in early June, the document is currently on IESG
table, without any apparent outstanding issues.
The ADs will check its status, too.

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

We confirmed, even if the targeted I-D refers other I-Ds,
it may finish IETF Last Call and move to RFC-editors' queue.
In that case, it will be published as RFC after all the reference
I-Ds become RFC. In fact, service-v2-05 I-D will finish IETF Last Call
sooner or later, while it refers DSN and TIFF-FX.

---------------------------------------------------------------------
The I-D which IESG is reviewing (Before IETF Last Call)
---------------------------------------------------------------------
Hiroshi Tamura presented one I-D on the IESG queue (Area Directors
review stage):
- draft-ietf-fax-timely-delivery-05.txt

There were no comments and modifications since the last meetings.
The WG Last Call was already finished. Thus, we just wait for the ADs
review and for the reference to draft-vaudreuil-1983ext-01.txt
to be solved.

The 1983ext I-D status was also updated by Greg Vaudreuil.
The situation is very similar to DNS. There are no outstanding issues.
After the meeting, Greg Vaudreuil and Hiroshi Tamura agreed that
FAX WG will do the WG Last Call after it is reposted, as it is
already expired.

---------------------------------------------------------------------
TIFF-FX implementation report
---------------------------------------------------------------------
Hiroshi Tamura introduced it. There is already the original report
in IETF site. This was for the additional (new) report to be submitted.

He explained (see slides) that the CIAJ (Communications and
Information network Association of Japan), whose members practically
contain all the fax manufactures in Japan, agreed to perform an
extended further TIFF-FX implementation test, to supplement the
original report. CIAJ already succeeded IFax and TIFF-FX testing in
1999 and 2001 for Profile S, F and J. The participats are 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 testings for
Profile C was done successfully last month, and the remains will be
done by the end of August.

CIAJ requires the new report should be supplementary to the orignal
report. It will include specified product name, supported tag
information, license validation for some profiles
It will be submitted by the end of September.

Patrik Faltstrom, Area Director, explicitly reminded that the
license statement should specify that the company has exercised
the proof of "independent licensing" in implementing their products.
The chairs should be careful for it.

---------------------------------------------------------------------
Addressing
---------------------------------------------------------------------
-draft-allocchio-gstn-03.txt

Claudio Allocchio made a short report about the addressing 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 recommended (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.

---------------------------------------------------------------------
FAX in ENUM
---------------------------------------------------------------------
Kiyoshi Toyoda reported on the I-D in preparation to register IFax
service in ENUM with IANA. The IFax functional specification is
different from the normal email service, PSTN-fax service and T.38
fax service.

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 used in accordance with "Simple Mode" RFC 2305, "Extended
Mode" RFC 2532 or FFPIM.
 Service name:   "ifax"
 Protocol:       smtp
 URI scheme:     "mailto"
 Intended Usage: COMMON

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. Now the
final decision will be taken on the mailing list. Thus, the Ifax
ENUM I-D, which Kiyoshi Toyoda prepare, 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 hierarchical syntax for the resource record data
fields. Patrik and the WG asked Kiyoshi Toyoda now to submit the
text of the I-D, and discuss it within the FAX WG, with CC to
the ENUM mailing list, although Patrik commented it should be
mainly discussed and solved in FAX WG. He promised he will submit it
within a short time.

---------------------------------------------------------------------
ITU issues
---------------------------------------------------------------------
Hiroshi Tamura introduced. The next ITU-T SG16 meeting is held in
October 2002. He will report our activities there. Also, As a WG
the documents which are referenced by ITU-T documents and need some
processing are:
  "image/tiff" MIME Sub-type Registration
  "image/tiff-fx" MIME Sub-type Registration
  Implementers Guide

FAX WG are now asking the RFC editors 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. The inputed information will be
decided on the mailing list.

---------------------------------------------------------------------
SMTP Service Extension for Content Negotiation (ESMTP CONNEG)
---------------------------------------------------------------------
Claudio Allocchio summarized 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. The new version is at
http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt.
It is 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 layering 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 Claudio's
introduction, Dave Crocker, one of the authors of the I-D, 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 might not be the case in all possible circumstances, but it will
quite well fit the model. Furthermore, most of the Ifax traffic would
be point to point, without relaying. There were comments reminding that
in most of the corporate cases, this might be false, as firewalls
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 behaviours 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 purposes, incliding VPIM,
MIME etc. Solving the basic philosophical problem thus requires the
involvement of the whole SMTP area expertise people, and not only the
FAX WG people.

There was a comment that the debate on this should 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 (LEMONAGEe).

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 issue first another command, and then when
capabilities of 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 single command (RCPT TO) is used to ask and
discover capabilities of the recipient MUA, while Greg Vaudreuil
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, approach. Patrik Faltstrom reminded that Ned Freed
commented a lot on this topic, and at the end asked the WG to come to
a conclusion on this two alternates. Harald Alvestrand, 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 would 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 think the SMTP world is
mostly "one recipient per MTA" when there is not a firewall or similar
security measures 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 mind 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.

---------------------------------------------------------------------
FFPIM
---------------------------------------------------------------------
Dave Crocker 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?
 - FFPIM conformance require RFC2305 and RFC2532 conformance?

We decided to vote by a show of hands. The result was "SHOULD" and
"require". After the meeting, Hiroshi Tamura again asked them in the
mailing list. But, there were no comments. Thus, those are the results.

Moreover, the document refers ESMTP CONNEG specification. It was agreed
that the CONNEG text should be more detailed in ESMTP CONNEG I-D,
and that we should of course adapt it to the output of the dicussion
about it.

---------------------------------------------------------------------
Closing
---------------------------------------------------------------------
FAX WG handed over to VPIM agenda points, and Glenn Parsons, chair of
VPIM WG, chaired the rest of the meeting. Note that the FAX and VPIM
WGs confirmed they will continue joint meetings until all their work
is finished. Thus, we will meet again together in Atlanta,
in November 2002.

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 1 Aug 2002 12:55:59 +0100

> As the other mails, it seems that they are "1 hand" and "2 hands".

Yes the other mails ARE correct: "1 hand and 2 hands" is exact. My notes 
were wrong.

:-)

> We can modify like that.

yes, please do it.

Regards,
Claudio

PS: Ok for the rest for me!