Subject: Minutes at London

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 06 Sep 2001 07:19:06 +0900 (JST)

Folks,

Sorry for the delay. Attached is the draft minutes at London.

It is difficult to satisfy all of you.
Some people support one thing, but others may oppose it.
I hope all of you accept it as much as possible.

But, if there are **fatal mistakes**, please let me know soon.
We have to submit it within **this week**.

Anyway, thanks again, Graham and Claudio.

BTW, Regarding TIFF-FX issue, the description here is old.
As you already know, there are already other options.

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 06 Sep 2001 10:05:08 +0900 (JST)

Folks,

I collected IFAX implementation in Japan, regarding TIFF-FX.
I collected 8 company's information.

All support Profile F partially and
4 of them support Profile J (JBIG) partially.

Content type image/tiff should continue to be used
for Profile S and F, at least.

For Profile J, it is difficult from the current situation.
But, if you have comments, please say here.
Especially, implementers with Profile J, C, L and M.

Regarding the choice of option 1-5 for TIFF-FX,
there is one favor for option 4 and lots of favors for option 5.

We should decide it sooner or later. At London meeting, it is suggested
it is done by mid-September.

Any other comments are invited.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Sep 2001 15:58:32 -0700

>As you already know, there are already other options.

Tamura-san,

Perhaps it will help if the working group sees a list of the current 
alternatives.  If you believe there is strong working group feeling about a 
particular alternative -- strongly in favor, or strongly against -- it 
could also help for you to indicate that.

Perhaps we also should consider a schedule for resolving this?  We have 
been told that ifax product developers have a serious problem if this is 
not resolved quickly.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 07 Sep 2001 08:49:16 +0900 (JST)

Dave,

Thank you for your good comments.

> been told that ifax product developers have a serious problem if this is 

Yes.

I say it a little in separate thread, although it is just about consensus.

> it is done by mid-September.

We have to wait for at least one week.
We will choose option 5 if there are no strong favors for other options.

Anyway, any comments about the schedule is welcome.

Regards,

---

From: "MAEDA Toru" <[email-masked]>
Date: Fri, 07 Sep 2001 16:10:34 +0200

Hi, Dave.

Since ifax manufacturers sold many ifax products in market based on
TIFF-FX,
we will have a serious problem if TIFF-FX is changed.
Are there any discussion about compatibility issue for existing ifax
devices?

Regards.

Toru Maeda

-- 
***********************************
MAEDA TORU
Canon Research Centre France S.A.
***********************************

---

From: Hiroshi Tamura <[email-masked]>
Date: Sat, 08 Sep 2001 12:25:02 +0900 (JST)

MAEDA-san,

> Are there any discussion about compatibility issue for existing ifax

We did not have time to talk about it.
That's why I already mentioned it in our ML.
Also, We did it in our minutes.

> ***** Additional summary and next steps *****
> 
> A summary of identified TIFF-FX options and WG next steps follows:

<snip>

>   - Both the resulting specification and the Implementors Guide should
>     contain explanation of the interoperability issues and countermeasures.
>     Because, some manufacturers already have implementation that deal
>     with more than Profile S with image/tiff, such as Profile J and C,
>     according to RFC2301.

It is important how we describe it in a new document.

--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]

---

From: "Larry Masinter - [email-masked]" <[email-masked]>
Date: Sun, 9 Sep 2001 10:56:41 -0700

(resending from subscribed account)

> > TIFF-FX, we will have a serious problem if TIFF-FX is changed.

The interoperability report for RFC 2305 Internet Fax
lists (attachment in http://www.imc.org/ietf-fax/mail-archive/msg00733.html)
as http://www.imc.org/ietf-fax/mail-archive/bin00008.bin
lists only profile S and F:

# Content (TIFF)
# Simple mode requires the use of the very restricted, minimum set TIFF-FX
# profile "S", although it allows use of other profiles when the
capabilities
# of the recipient are known. The implementors now understand the difference
# between the "S" profile and the commonly used "F" profile. Most testing
was
# based on the S profile, but there were also several F profile
implementations.

The recent report "IFAX implementation in Japan and choice of option 1-5"
http://www.imc.org/ietf-fax/mail-archive/msg03320.html also indicates
that few of the profiles are supported completely (S, F, J) in the
implementations surveyed.

Note also that "profile F" is ambiguous, because profile F
in RFC 2301 and profile F in RFC 2306 are different in a few
details (for example, the introduction of GlobalParametersIFD).

To move to Draft Standard, there needs to be multiple independent
interoperable implementations of every feature of the standard
This means two writers and two readers.

Is it possible to make available test files from current ifax
implementations so that interoperability with typical
email clients can be examined and tested?

For example, Kodak Imaging for Windows seems to be
installed with many versions of Windows as the default
display program for image/tiff. Are the TIFF files produced
by the ifax implementations compatible with this program?

We should also test interoperability with other
TIFF reading and writing programs too, of course.

Since there are many ifax products, it should not be
too hard to come up with some test files for email
interoperability testing, should it? It would be especially
useful to have samples from other profiles and with
different combinations of options (resolution, fillorder,
endian, etc.)

Larry
--
http://larry.masinter.net