-----Original Message-----
From: Hiroshi Tamura [mailto:tamura@toda.ricoh.co.jp]
Sent: Wednesday, August 07, 2002 1:58 AM
To: minutes@ietf.org
Cc: ned.freed@mrochek.com; paf@cisco.com; ietf-fax@imc.org
Subject: IETF-FAX WG minutes at Yokohama meeting
Attached is the FAX WG minutes at Yokohama meeting.
Regards,
-- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp---------------------------------------------------------------------
TUESDAY, July 16 at 0900-1130 ==============================
CHAIRS: Claudio Allocchio <Claudio.Allocchio@garr.it> Hiroshi Tamura <tamura@toda.ricoh.co.jp>
--------------------------------------------------------------------- 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 1 hand in favour of a simple command (current specification), 2 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.
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 17:10:43 EDT