quick notes from the Internet Fax meeting.

Hello,

here are my quick notes on the Internet Fax meeting of last Wednesday.
More detailed minutes will follow. Your comments, suggestions, corrections
are welcome. I'll also mail you the slides which were presented at the
meeting in a later message.

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

1 Agenda bashing
 The agenda was approved without changes.

2 The I-Ds which IESG approved and are in RFC editor's queue

2.1 draft-ietf-fax-service-v2-05.txt (Draft Standard for RFC 2305)
  Reference issue of DSN (RFC1894) and TIFF-FX

The above document is now in the RFC Editor queue, this the reference
issue is solved, as soon as it is published.

(draft-ietf-fax-tiff-fx-11.txt)
This is still outstanding. thus we postponed the discussion in its
specific point, later on.

3 The I-Ds for which IETF Last Call was finished
3.1 draft-ietf-fax-gateway-protocol-08.txt

The document is currently being discussed at the IESG, and Ned as AD is
contacting the editor for some changes which the IESG discussion pointed
out.

3.2 draft-ietf-fax-gateway-options-05.txt

This informational document is still on ISEG table. It will move forward
jointly with the gateway-protocol one. No issues raised (did I got this
correctly Ned?)

4 The I-D which IESG is reviewing (Before IETF Last Call)
4.1 draft-ietf-fax-timely-delivery-05.txt

The Editors (dave and Graham) reported back that after the discussion
about the possible complexity of the current proposed method they're
investigating a possible alternate method, much simpler to implement and
keep under control. Dave proposed thus to withdraw the current
specification as it is, and re-draft a new one with substantial
modifications. The editors will define if they keep the draft name, or
remove the current one and start from a new -00 one. There was rough
consensus on this proposal from the people present in the room. See the
slide presented at the meeting by Dave and his accompanying message for
details on the newly proposed approach.

4.2 draft-allocchio-gstn-04.txt
Claudio reported that after the IETF LC was over, only 1 further comment
was received. He and the AD (Patrik) reviewed this comment, and agreed it
is totally an off topic comment. They just decided not to make any further
modification to the current draft. Patrik will prepare the AD writeup for
the IESG and send it for approval.

5 IFAX service of ENUM (draft-toyoda-enum-faxservice-00.txt)

Toyoda-san is not present at the meeting. however Claudio presented his
slides. The topic was also presented at the ENUM WG meeting 2 days before.
Claudio reported that at the ENUM meeting the suggestion was to keep this
specification as a "fax WG" document, and thus to discuss it in our
meetings/list. At the ENUM we the generic syntax was again discussed, and
modified, and they hoe it is now "stable". As soon as this proves true
alto the fax in enum draft will reflect this final format. However the
important action now is to discuss the implication of the proposal, and the
information to convey into the ENUM fax record, in our WG. Claudio thus
solicited the WG for input to the editor. The slides also present the
proposed road-map. As the document does not belong to our milestones, the
WG agreed to include it into our list, accepting the ENUM wg
reccomendation.

6 FFPIM (draft-ietf-fax-ffpim-01.txt)

Tamura-san checked the discussion report in Yokohama, and noted that a
couple of suggested changed to the document were not yet done. Dave
apologized for having forgotten to do this and took up the action again.
There were no other major actions/suggestions.

7 Confirmation of dropping "Fax Status Information" in our milestone

The chairs formally asked the WG for consensus to drop these documents
from our list of "to-do" things. The people in the room agreed on this, and
the final question will be posed again on the mailing list.

 8 ITU issue

Tamura-san reported on the meeting held in October 2002. The ITU-T
accepted the amendment  to T.37, reflecting the split of image/tiff and
ingae/tiff-fx MIME types ("approve for Consent"). The formal approvmente
of the amendment will occur "as a Reccomendation" when their last call
expires, on November 28th.

9 Draft Standard Consideration

as it was faster, 9.2 was handled first.

9.2 RFC 3250 ("image/tiff-fx")
the publication of image/tiff-fx and its companion update of image/tiff
registration RFCs was done. It was noted that image/tiff is now a Proposed
Standard (used to be a BCP) as the IESG strongly suggested to put it on
standard track during its revision.

9.1 TIFF-FX (draft-ietf-fax-tiff-fx-11.txt)
    interoperability report(s)

Claudio reported that a formal appeal to the IESG has been submitted by
Larry Masinter about the problems he sees inside the currently available
interoperability, licensing reports and the tiff-fx file format
specification. Before going to details about these concerns, Claudio
reminded the WG that at the London IETF, after a consultation between the
TIFF-FX editors, the WG (present and past) Chairs and the IAB, it was
decided that a single image/tiff MIME type was inappropriate, and thus we
should correct this error, registering two separate type. This also should
be considered when reading the early documents about interoperability and
file format, as they were referring to image/tiff also when the format was
actually image/tiff-fx. Larry noted that this is anyhow a possible source
of confusion; comments were however made by people who took part into that
event that, even if the name was image/tiff, they were actually testing
image/tiff-fx features. Larry objected again that some of the inside
specification were meanwhile changed, but it was noted that this might
eventually require some testing about these specific features, and not
invalidate the whole results.

After this, Rob Buckley presented (see slides) (hoping you get the content
of the tables!!! I had some problems with reading them!) a compendium
summary driven out from the 2 available interop tests performed. He
reported that is all cases listed as "one implementation" this means "one
reader and one writer". The tables reveal that there are a very limited
number of cases (2 only) where there is only support by one implementer.
Thus he proposed that these features are dropped from the tiff-fx
specification (unless meanwhile it is reported that an additional
implementation is available for them). The WG expressed consensus on this
removal from the specification. Larry then presented (see his slides) the
objections which he is moving to the current reports. The WG asked if it
is possible to have the original appeal Larry sent to the IESG, but he
replied that the process does not require the WG to be involved in this,
as it regards the IESG and WG chairs only. However Claudio reported that
what's presented in Larry's slides reflect what's in the submitted
complaint. During the presentation Ned, Dave and others objected about
some points. In particular about the request that it should be an Internet
Fax specific product/implementation which is used to test the file format,
while it seems that in some cases a file reader/write was used, externally
from an i-fax implementation. As it is a "file format" we should test the
file format, and this can be done with specific file tools like readers and
writers, no matter if these are then the same being implemented inside
i-fax implementation. Larry objected that also the files used are not
available, to see what was actually tested. James Rafferty reminded that
the tiff-fx files for all the profiles are available since (1998?) at the
ITU repository, and those were the files being used, as official
benchmarks. Larry objected also that the implementation shown are not
indipendent one, and they might derive from the same public domain or
licensed source code. There were again counter-objections that this is not
to be proven by the WG, but it enough for us to trust the declaration of
the participants in the interop tests, where they report indipendent
implementations. Ned also reminded that the current tiff-fx specification
is not YET on the IESG table, thus we are still considering updates to it,
especially after we agreed some features should be removed. As last rework
Larry reported that in his opinion the exercise of unrestricted licensing
was not described appropriately. Tamura-san replied that he is currently
collecting the declaration/statement and this will be made available as
soon as it is ready.

As final point Claudio suggested that the WG chairs prepare an additional
accompanying document for the interop document set, including the matrix
of supported and test features etc. The WG supported the proposal. Back
again on the ML.

Ned then presented the road-map to progress the work (see his message on
the mailing list) and the WG agreed on it.

10 SMTP Service Extension for Content Negotiation
(draft-ietf-fax-esmtp-conneg-03.txt)              25  75

Dave presented (see slide and his e-mail) a different approach which could
respond to the objections raised last summer on the mailing list. There was
quite some discussion in order to clarify the presented solution, which are
now again summirised in Dave e-mail, and the WG agreed (rough consensus)
that. We will ask again on the ML. Dave will submit promptly the updated
draft document.

after running about 45 minutes late, we handled over to VPIM.

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