Subject: notes from the ietf FAX wg meeting at IETF 51

From: Claudio Allocchio <[email-masked]>
Date: Thu, 9 Aug 2001 17:26:16 +0100

Hallo, 

here are the notes from the meeting we had on monday evening.  Sorry for
being late, but (apart from an "editing accident" which deleted the first
version of the notes) I tried to be as most precise as possible, as some
issues are very important to be understood also on the mailing list by
those who were not present at the meeting. 

Please drop comments and integrations to our ML. Thanks again o Graham 
Klyne who took the base notes.

Regards
Claudio Allocchio
----------------------------------

Short notes of the ietf FAX WG meeting - IETF 51 London, UK
------------------------------------------------------

At the meeting start the co-chair welcomed the participants, and asked for
eventual modifications to the proposed agenda. As ther were no specific
change requests, the agenda was approved. 

Tamura-san announced that Maeda-san was unfortunaely not present at the
meeting, thus we would add more time to the discussion of the TIFF issues. 

2. Status of Draft Standard consideration
  2.1 Addressing
       draft-ietf-fax-minaddr-v2-04.txt
       draft-ietf-fax-faxaddr-v2-04.txt

These two documents were approved by IESG on July 19th 2001 and now are in
the RFC editor queue for publication. In the Applications Open Area
meeting there was the suggestion to find a way to explicitly state that
the specification draft-ietf-fax-minaddr-v2-04.txt is a general
specification which is valid in ANY application encoding GSTN (telephone)
numbers into an e-mail address.  Also the FAX wg suggested to add such
note, possibly in the abstract. The editor will investigate with the ADs
if an IESG note in appropriate. 

The same need to emphasize the generality could apply also to other FAX wg
documents, like the draft-ietf-fax-content-negotiation-05.txt ones and the
wg suggested the editors to consider it, too. 

 2.2 TIFF-FX
      draft-ietf-fax-tiff-fx-09.txt
      draft-ietf-fax-tiff-regbis-02.txt

The documents approval is slowed down by a series of problems which were
detected during the process. ITU-T also needs a quick resolution of there
problems as stated in the communication letter from ITU-T SG16 meeting.

The problem, detected at first as an IPR issue raised by Adobe in January 
2001, was escalated to IESG and IAB which examined carefully all the aspects,
and identified also some additional compatibility issues. 

John Klensin (IAB) reported to the WG.

The TIFF Story, actually had many different steps and chapters. During the
analysis of the problem there were many iterations between the IESG and
the IAB which at the end pointed out two Separate Issues: 

 - WG responsibility for interoperability
 - IPR questions

At first the interoperability. This is the "Main IETF Goal" to be
achieved, and its meaning should span forward and sideways. The main
principles are that: 

 - Implementations of one protocol must interoperate
Ð- Implementations of related protocols should interoperate
Ð- Deviations must make sense and have a clear rationale behind.

In its original goals (and as stated in the charter) the fax wg had to
create a Fax Model that should Interoperate with fax fabric and
Interoperate with e-mail fabric. More over it should avoid having to
choose between the two fabrics. For this reason TIFF was chosen because It
was widely believed that it would be interoperable with existing viewers
and editors, especially Viewers expected to be used with image/tiff in
e-mail. This shoud also be the start of the "global messaging service". 

The question now is: can we meet all these constrains? Is TIFF the right
choice to accomplish them? 

Basic TIFF does not support colors, and different resolutions, but is it
compliant with the existing TIFF readers, and e-mail User Agents (MUAs).
However, if we want to cover also the "extensions" that ITU-T is
requesting for fax service (e.g. colors, resolutions, etc...) Basic TIFF
is not enough, and it will need extensions. These extensions were
specified into TIFF-FX, and ITU-T decided to adopt and reference it.
However TIFF-FX is already beyond Basic TIFF. 

Actually there are already de facto extensions to basic TIFF
specifications which are publicly available, and widely deployed within
both TIFF readers and MUAs. All there de facto extensions are currently
used in MIME type "image/tiff" and there are not interoperability
problems. However the extensions intriduced into TIFF-FX are a superset,
and thus only some Ifax devices can correctly handle them. 

So, the IESG and IAB would like the WG to review and document, as a condition
for advancing the TIFF specification to Draft Standard:

 - Whether the choice of "interoperation with e-mail" versus "interoperation
   with fax" is the right one
 - whether a mostly-fax-only TIFF variation is the right choice
 - Whether this should be image/tiff or image/tifffx (or equivalent)
 - hether the interoperability profile is right given these issues
 - and any other similar tradeoffs that might have been made without full
   evaluation.

The IAB believes now it is late in the game, so these reviews may not
change anything, but they are important for learning, and context, and
predicting problem areas and determining whether the meta-qualifications
for Draft Standard are met. 

John Klensin then reported on the IPR issues, which invove both Adobe and 
Xerox.

Adobe:  the solution appears to be to have Adobe include the new TIFF-FX
encodings in TIFF-7, but Adobe has not committed to produce TIFF-7 and It
is not clear what produces that commitment. Moreover, even if they do
TIFF-7, they will not commit to including the TIFF-FX features until at
least Xerox releases rights to the encoding techniques for all uses of
TIFF, not just fax and Xerox (or maybe IETF) apply formally to Adobe to
have the features and tags included. At last, but not the least, no one at
this IETF can commit Adobe. 

Xerox: Xerox is willing to release rights for all uses in TIFF if Adobe
will adopt them and include them in TIFF-7. But no one here can commit
Xerox either. 

Thus it seems a viable solution currently in a deadlock waiting for
somebody to make the first move. 

At last, we have the ITU issue, who is referencing our documents. But ITU
approach to IPR is different, and a licence issued to the IETF might not
fully apply also to ITU. There is a strict need to coordinate with ITU
also on these IPR matters, to avoid future problems. It is in fact clear
that what was released to IETF is not automatically released to ITU (and
viceversa). 

The discussion of the problem and the WG conclusions.
-------------------------------------------------

The original reasons for using TIFF were lightweight, extensibility and
its ITU compatibility, and it ability to be understood as a MIME type
image/tiff by most of the MUAs. 

The extensions are actually needed to meet the new specification which
ITU-T had done, but the new extensions also introduce impatibility and IPR
possible clashes. 

Dave Crocker suggest as a first prroximation solution to skim down the
core specification to a "safe" subset, and pursue the other issues
separately, with a separate MIME type. 

Scott Forshee suggested also that other focus has been on JPEG-2000
specifications , and work is progressing on a different (planned) MIME
type including MRC capabilities.  However igher level features of
JPEG-2000 are generally not widely deployed. He proposed the wg to
reconsider JPEG-2000 as an alternate to TIFF-FX. Moreover, part of the
reason for Adobe's objections are to keep the use of TIFF freely
available. 

There were objections to this proposal, stating the JPEG-2000 is not yet
in good shape, has not yet a MIME type registered, too, and its wide
deployment is not existing at the moment. 

A discussion followed, considering if one should simply use the version
label into MIME typ definition to define which level of TIFF is being
used, or just a totally new type. 

Claudio Allocchio suggested that image/tiff should be used onlyfor minimum
interoperable features and anything else should have a different name and
label; this will have to happen for TIFF-7 in any case. 

Lloyd McIntyre suggested as simple solution to revert to previously
registered version of TIFF, i.e. TIFF 6.0, excluding also any widely
deployed de facto extensions. There was a discussion on this, and Scott F.
stated that TIFF 6.0 was issued in 1992, with updates via by technical
notes, which are widely implemented.  Thus RFC 2302 is OK with the way
that Adobe and others use TIFF. We should focus on the TIFF-FX spec, to
cut it back to non-controversial features. 

At this point Claudio A. asked the wg members present at the meeting if
anyone strongly oppose the approach proposed by Dave C.? 

Larry Masinter and Johm Klensin suggested that to be concerned with what
is practised is more important than compatibility with what is registered.
"The Right Thing to do is look at reality and try to get it right". 

The wg expressed consensus on the above approach. This consensus need to be
confirmed by the mailing list.

Claudio A. summarised the conclusions to be reported into the minues, and to
facilitate the understanding of the approach by anybody including those not
present at the meeting:
 
  - we must consider for interoperability test of RFC2301 also existing 
    mail user agents (MUAs), and they should be able to read image/tiff 
    bodyparts generated bu Ifax devices. Interoperability is the choice.

  - we must also consider interoperability with existing tiff capable
    software, e.g. saving the image/tiff to a file and reading it with ...
    Photoshop, and other tiff files readers.

 - we should produce a new interoperability report, and based on this
   we should detail the revision of RFC2301, to fit any feature which
   proved to interoperate in all above cases, even if not included in
   basic TIFF 6.0 specification.

 - thus existing tiff-fx Ifax devices go beyond this, as they my generate
   extensions which do not interoperate correctly with the above

 - thus we should define how to create a NEW format (both for files and 
   for MIME readers) with a different name which may be tiff-fx, or totally
   different, to make clear to implementers and devices that "this is an
   extended new format" (even if based on tiff in origin).

 - the reason for removing from RFC2301 revision some features is
   because they do not interoperate on the global service, even if they
   proved to interoperate among Ifax implementaions.

 - the "recuded set" specification will be submitted for Draft Standard

 - we should, at the same time, produce a new "extended specification"
   docuement, which includes the extensions existing in RFC2301 and
   dropped in the Draft Standard document, and might also include the
   further extensions proposed for "full mode". This document(s) should
   also define a different MIME type registration for this extended
   specification. This new specification should go as Proposed Standard

 - we need to investigate if it is possible to declare RFC1301 "Updated" 
   by the new Draft Standard document, at least until the new "Proposed
   Standard" document obsoletes RFC2301. ADs suggestions are expected.

 - we should carefully inform ITU-T of the reasons of this choice.

 - the Draft Standard version of the specification would also not have
   (apparently) IPR issues related, and the extended mode one should 
   carefully consider IPR problems while being specified.

Furthermore, we should explain, probably in the new extended document, and
probably into the implementers guide, the compatibility reasons which led
us to this choice. In fact some manufactures already have more than
profile S(simple mode) implementations with MIME type image/tiff, for
example, Profile C(color) with image/tiff, according to existing RFC2301
and RFC2302. 

After more than one hour, we closed the topic and moved forward.

3 Targeted for Draft Standard
  3.1 Service
       draft-ietf-fax-service-v2-03.txt

The document was sent to IESG on June 23rd with Interworking report
(published on June 18th); We added the request to wait for publication
until all normative dependencies are elevated to Draft Standard. We also
received AD comments which led to a new version circulated on our Mailing
List only. 

In particular, there is the reference to RFC1984 (DSN), and a reference to
RFC2301. We should thus solve TIFF issues, too.

4 Targeted for Informational 1 min (25min)
 4.1 Implementers Guide		
      draft-ietf-fax-implementers-guide-07.txt

The document was sent to IESG on Apr 10th and we had the letter from
ITU confirming that T.37 would refer the Implementer's guide.  The IETF
Last Call on July 26th until August 26th. 

It was clearly noted that also in this case we should quickly check if
there are specific references to RFC2301 which might be an issue (if
specifically refer to TIFF-FX features which could be dropped into the
Draft Standard skimmed version. 

This very same revision and check is needed for the whole set of other
documents.

5 On-going Internet-Drafts
 5.1 Gateway issue
      draft-ietf-fax-gateway-protocol-05.txt
      draft-ietf-fax-gateway-options-03.txt

Mimura-san described the main differences in the final version of gateway
documents: draft-ietf-fax-gateway-protocol-05.txt defines the minimum
requirements for Internet FAX Gateway. It defines a basic Function for the
Internet FAX Gateway, whereas draft-ietf-fax-gateway-options-03.txt
provides Information for Guideline of optional services. (See slides for
detailed differences)

Larry M. objected that the security recommendations are unclear.  It is
not explicit if the document suggest S/MIME as a MUST solution, or just a
possibility. Claudio A. reminded that also the traditional problem of
"credentials" (Sender's or Gateway's) needs to be clarified, or at least
clearly stated. Maybe it's just fine if the wording is softened - "could
be"  instead of "is". The WG agreed to issue a wg Last Call, considering
the above points as the first comment into the Last Call. 

 5.2 FFPIM
      draft-ietf-fax-ffpim-01.txt

The specification has been updated today, and mailed to the wg ML; the
main actions were to remove all editor comments, to add citation and
pointer to draft-ietf-fax-esmtp-conneg-00.txt, to add an appendix
explaining the Direct Mode and to focus on need for ÒdirectÓ
configuration, including the use of ESMTP Timely and ESMTP Conneg

Apparently no further substantial work need to be done. In particular
about direct mode, some text was added to clarify that it needs some
unusual e-mail configuration to work properly. A short discussion if all
goals were met did not discovered any missing item. The question is to be
repeated to the ML before progressing to wg LC. The only question raised
was if this document should reference the "terminal mode" documents or not
at all. Dave and some other believe that there should not be any
reference, provided the fact that there is still no consensus if the
terminal mode documents should go forward. 

      draft-ietf-fax-content-negotiation-05.txt

The WG last call ended without comments, thus we sent the request for IETF
last call to IESG on July 21st. 2001. There were no further comments from
the WG at the meeting. 

      draft-ietf-fax-esmtp-conneg-00.txt

This specification allows content negotiation to take place at the SMTP
level (i.e. between MTAs).  In particualr, this service extension is
intended for direct SMTP transfers and It can be used within an
enterprise's internal network. 

A new keyword ("CONNEG") is added to the possible EHLO values, and the
server responds with a report of the content capabilities of the device or
system that embodies the target RCPT-TO address. 

A revised version is expected by  November 2001, aiming to the WG Last Call.

      draft-ietf-fax-timely-delivery-03.txt

After some discussion with the ADs, Graham Klyne produced a new version. 
In it the feature of allowing a message to be immediately rejected for
timely delivery will be dropped.  Past experience with this kind of
feature is poor (X.400), and the use cases will generally not represent an
exacerbation of the congestion. As soon as the document is published, we
aggreed to go for the WG Last Call. 

 5.3 Terminal mode issue
      draft-maeda-faxwg-terminal-mode-goals-00.txt
      draft-maeda-faxwg-terminal-mode-protocol-00.txt
      draft-maeda-faxwg-fax-processing-status-00.txt

There were wuite a number of comments on the list about this topic. As the
author is not here we will defer further discussion to the ML. However
Claudio A. asked for some opinion of the presents. We added to our
milestones the documents in the last Minneapolis meeting. 

Larry M.objected that RFC2542 already discusses goals, so the new goals
document is largely redundant (apart from comments which are more like a
protocol specification), and asked if there is an intention to be more
specific about *requirements*? He also asked if anybody would object if we
did not pursue this document. As the author was not present, we deferred
further discussion to the ML. 

 5.4 PWG IPP Fax status report

Lloyd reported on behalf of the PWG IPP group. (see slides for a detailed
description of documents and status). Is was made clear that the activity
presetnte is carried on within the IEEE unbrella, and also that the IESG
did not accepted this activity as a possible IETF one, answering that
these activities were already covered by our wg. There was consensus from
the wg that there must be a better coordination with these external
efforts, in order to avoid any possible incomaptible products to be
developed. 

 5.5 TIFF-FX extension issue
      draft-ietf-fax-tiff-fx-Extension-1-02.txt
      (drtyre-tiff-fx-extension1-02.txt)
     darft-mcintyre-feature-schema-extension1-00.txt

After remembering that all the issues in these documents are related to
the previous discussion about TIFF and TIFF-FX issue, and that IPR
problems should be clearly investigated also for these proposed
extensions, the presentation (see slies) described the further JBIG2
extensions. 

Larry M. asked how many in the room read the draft:  One person. As such
the question was raised if we should continue the work, if there is
interest in doing it or not, provided that at a certain point the
specification will have to undego interoperability tests, and the lack of
interest could lead to a lack of implementations.  There was at the moment
no conclusion to ths question, as we need to check first the status of the
TIFF issue evolution. 

6 Miscellaneous

Finally the fax charter was updated on the IETF web pages. (July 26th 2001).
An applause came from the audience.

7 Confirmation of milestone

Here is the updated list of milestones *** (please double check it !!!) ***

Apr 2001	Submit final draft of Implementers Guide for 
		Simple and Extended mode to IESG for publication as 
		Informational.
		Done (see draft-ietf-fax-implementers-guide-07.txt sent to
		IESG on June 2001)

Jun 2001	Submit final draft for content negotiaton to IESG 
		for publication as Proposed Standard
		Done (see draft-ietf-fax-content-negotiation-05.txt sent
		to IESG on July 21st 2001)

Sep  2001	Submit final draft for timely delivery to IESG for publication
		as Proposed Standard

Sep 2001	Submit final draft for FFPIM to IESG for publication

Sep 2001	Submit final draft of gateway requirements

Nov 2001	Submit final draft of TIFF-FX extensions
Nov 2001	Submit final draft of schema for TIFF-FX extensions
These two need further work - see discussion

Jul 2001	Submit second draft of Fax status information
??? 2001	Submit second draft of Goal for Terminal Mode
??? 2001	Submit second draft of Protocol for Terminal Mode
Dec 2001	Submit final draft of Fax status information
??? 2001	Submit final draft of Goal for Terminal Mode
??? 2001	Submit Final draft of Protocol for Terminal Mode

The meeting ended at 22:04

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                        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

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 10 Aug 2001 05:52:44 +0900 (JST)

Hallo Claudio,
(and Folks)

Lots of thanks for very, very detailed ****summary****.
(Normally, one paragraph is enough within the meeting period).

There are few things that I can do for our formal minutes!!

Claudio,
may I use most of them as they are, for our formal minutes,
except for some items, which I comment below?

Folks,
As the formal minutes, I can rewrite what Claudio wrote here,
although they will be almost the same. THerefore, please confirm and check
the formal one again.

> Klyne who took the base notes.

I also very much thank Graham.

I comment and add below.

TIFF-FX issue:

<snip>

Claudio,
Thank you for your thoughtful summary, regarding this issue.
I would like to remove the following Claudio's comments from the formal minutes,
because this is not mentioned at all in our meeting.

Claudio, is it acceptable to remove?

Please reply to me.

But, this is the starting point at which we have to solve TIFF-FX issue here.
Therefore, I encourage all of the IFAX implementers to read them carefully.

>    Standard" document obsoletes RFC2301. ADs suggestions are expected.

I would like to add,
Among small talks, the new Proposed Standard (or recycle standard)
includes *all* features of the existing RFC2301 and the possiblity of
compatility issues with the use of image/tiff for more than Profile S.
The recycle one(the same number) is better.

But, this is not decided. It depends on our future discussion.

> example, Profile C(color) with image/tiff, according to existing RFC2301

That's right. Therefore, please take them carefully.

> RFC2301. We should thus solve TIFF issues, too.

I think Ned commented the editors of DSN is now preparing the new I-D.
1984 -> 1894

>       draft-ietf-fax-gateway-options-03.txt

<snip>

> the above points as the first comment into the Last Call. 

I remember that there was a comment about it.
If my understanding is correct, updating the new ones are not necessary
at that time for the WG LCs. Am I right?

But, the modification is easy: "could be" instead of "is".

>      darft-mcintyre-feature-schema-extension1-00.txt

<snip>

> no conclusion to ths question, as we need to check first the status of the

At the meeting, personally, I commented the extension of resolution are
at least important for IFAX implenters. Because RFC2301 only supports up to
400x400dpi.

> Sep 2001	Submit final draft of gateway requirements

Mimura-san,
Do you modify your I-D as the above suggestion?

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

---

From: Scott Foshee <[email-masked]>
Date: Thu, 9 Aug 2001 15:27:48 -0700

Hiroshi,

I thought Claudio's summary was reasonably ok and I believe I 
followed his comments.  However, I am having some trouble with the 
items below.

>Claudio, is it acceptable to remove?

What is to be removed?

>The recycle one(the same number) is better.

This paragraph was not clear to me.  I do not recall your comments as 
part of the WG discussion.  Can you clarify?

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 10 Aug 2001 15:03:18 +0900 (JST)

Scott,

> What is to be removed?

From the next line,

> example, Profile C(color) with image/tiff, according to existing RFC2301

By the above line.

These explain our current situation very well.
It comes from the mail and the talk between Cluadio and me, AFTER the meeting.
But, it is not discussed in the meeting.
Therefore, I propose to remove them in our minutes.

Claudio,
Please comment it.

> part of the WG discussion.  Can you clarify?

This is just my comment to the Claudio's summary(the mail).
I did not comment there.
So, I do NOT put my comment in our minutes.
It is only one idea in small talks between Claudio and me AFTER our meeting.

Scott,
Please keep trying to solve this issue.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
[email-masked]

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 10 Aug 2001 09:56:05 +0100

> except for some items, which I comment below?

Sure ! 

> Claudio, is it acceptable to remove?

Yes. I added it to ther note in order too have the mailing list know 
which is the possible solution we planned also in the further discussions 
about the problem. Thus consider it a "message to the mailing list"

> The recycle one(the same number) is better.

Ok, for the minutes can be fine: we already have the details on the ML.

 Any other correction is fine, too!

Regards
Claudio Allocchio

PS: I'll be off line for 2 weeks now. Thus no e-mail answers during this 
period!

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 10 Aug 2001 17:23:39 +0900 (JST)

Hallo Claudio,

> Sure ! 

Thanks. It will take only few hours to complete the formal one.

> about the problem. Thus consider it a "message to the mailing list"

Completely right.

To all:
Please read it carefully and if you have comments, please say it!

> PS: I'll be off line for 2 weeks now. Thus no e-mail answers during this 

Enjoy your holiday!

Regards,

---

From: Katsuhiko Mimura <[email-masked]>
Date: Wed, 15 Aug 2001 09:54:18 +0900

Tamura-san,

<snip>
> Do you modify your I-D as the above suggestion?
 
Yes, we would like to use "could be" instead of "is".
and we will update the I-Ds soon.

/Mimura