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

From: "McIntyre, Lloyd" <[email-masked]>
Date: Tue, 14 Aug 2001 16:14:51 -0700

Claudio and Tamura-san
My thanks to you and Graham for the excellent job in capturing the meeting
proceedings and result.
Please allow me to suggest a few clarifications below.

Regards,
Lloyd 

> -----Original Message-----
> From: Claudio Allocchio [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 9:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: notes from the ietf FAX wg meeting at IETF 51
> 
> 
> 
---snip---
> 
>  2.2 TIFF-FX
>       draft-ietf-fax-tiff-fx-09.txt
>       draft-ietf-fax-tiff-regbis-02.txt
> 
---snip---
> The question now is: can we meet all these constrains? Is TIFF the right
> choice to accomplish them? 
The second sentence was not an issued raised by the IAB chair, in fact one
individual raised this issue. Please consider deleting the second sentence
or revising to read as follows:
"The question now is: can we meet all these constrains? One individual asked
whether TIFF was 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).
Reverse the order of "is it" to read "it is".

> 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. 
Given that accommodation of ITU-T color and higher quality encodings was a
component of the WG charter, this sentence may be reworded to convey less of
an impression that it was an afterthought. Please consider the following
revision:
"Basic TIFF was not enough to accommodate color and higher quality ITU-T
encodings, consequently extensions were needed."

>                                                These extensions were
> specified into TIFF-FX, and ITU-T decided to adopt and reference it.
For completeness, please append "for their Internet Fax standard" to this
sentence. It should now read:
"These extensions were specified into TIFF-FX, and ITU-T decided to adopt
and reference it for their Internet Fax standard."

> 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. 
The statement of no interoperability problems with all the de facto
extensions is inaccurate, since some deployed viewers will not read all the
extensions. Please reword the second sentence similar to the following:
"All the de facto extensions are currently used in MIME type "image/tiff"
and some have no interoperability problems."

>          However the extensions intriduced into TIFF-FX are a superset,
> and thus only some Ifax devices can correctly handle them. 
A correction and softening is warranted, given that it is not only Ifax
devices that are capable of reading TIFF-FX files and the limited
readability is not an unusual issue with new extensions in general. Consider
the following:
"The extensions introduced into TIFF-FX are a superset, which are viewable
by a limited set of Ifax devices and software applications."

It is important to convey the fact that the WG took deliberate steps to
avoid incompatibility resulting from addition of new encodings by redefining
the image/tiff MIME type (i.e. RFC2302) to include an application parameter.
The results were not quite satisfactory, however, the issue was addressed
and steps were taken. Accordingly, please consider insertion of the
following paragraph: 

"To avoid interoperability issues arising from introduction of the extended
color and high quality super set, the image/tiff MIME type was revised to
add application parameters. The image/tiff application parameters serve to
alert viewers to the presence of the TIFF-FX superset. Recent disclosures,
however, indicate that many readers do not pay attention to MIME application
parameters. It is the inconsistent usage of application parameters that is
at the heart of TIFF-FX incompatibility with image/tiff viewers."

> 
> 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)
Clarify as follows:
 "- Whether the MIME sub-type should be image/tiff or image/tifffx (or
equivalent)"

>  - hether the interoperability profile is right given these issues
Please clarify, I do not understand what is being said?

>  - and any other similar tradeoffs that might have been made 
> without full
>    evaluation.

---snip---
The paragraph below appears to be lacking context of what the IPR issue is,
please prefix it with the following:
"In December 2000 Adobe provided notification of its believe that the
TIFF-FX specification exceeds the scope of its 1997 IETF license grant for
TIFF-FX development <http://www.ietf.org/ietf/IPR/Adobe-TIFF>. Inclusion of
the extended encodings within TIFF-FX was identified as reason for the claim
of exceeded scope. The validity of this claim has been questioned, given
that the grant contains no constraint on extensions within TIFF-FX. The fact
that Abode co-authored both the TIFF-FX and the revised MIME image/tiff
specifications makes it more difficult to understand the claim.
Additionally, it may be said that the claim is somewhat late, given that
TIFF-FX was issued as Proposed Standard in December 1998."  

> 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. 
In light of the attached license statement, which clearly states that Xerox
grants MRC license use within TIFF-FX and without any application space
restrictions, please correct the 2nd sentence by inserting "MRC" between
"the encoding" and changing "not just fax and Xerox (or maybe IETF) apply"
to "not just TIFF-FX, and apply". The sentence should now read:
"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 MRC encoding
techniques for all uses of TIFF, not just TIFF-FX, and apply formally to
Adobe to have the features and tags included."

> 
> 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. 
> 
---snip---
> 
> The discussion of the problem and the WG conclusions.
> -------------------------------------------------
> 
Consider constraining this section to only WG conclusions and procedures to
be followed, removing the detailed he said/she said commentary. This
translates to deleting all items prior to the paragraph that starts "Claudio
A. summarised the conclusions to be reported into the minues,". 
The revised title might read as follows:
"WG meeting conclusions and procedures to be followed"
 ----------------------------------------------------

This would be followed by a restructured, consolidated and clarified body as
below.

A summary of the meeting's rough consensus, along with the procedures to be
followed, is provided below with "rc" identifying rough consensus items and
"p" identifying procedure items:
rc - Interoperability with email was considered the most important choice
between email or fax interoperability.

p  - Level of interoperability should be established by conducting a test of
RFC2301 (more appropriately draft-ietf-fax-tiff-fx-09.txt) using existing
mail user agents (MUAs) and tiff capable software applications such as
PhotoShop and other tiff viewers. The software viewer test may be
accommodated by saving the RFC2301 image/tiff stream to a file with .tif or
other appropriate tiff extension.

p  - An interoperability report should be generated and used to document the
set of interoperable TIFF-FX encoding parameters, such as coder, resolution,
paper size and color components.

p  - One of the four options below should be selected for the
specification(s) that will move forward through the standards tack process:
     1. Full TIFF-FX: - retain the currently defined TIFF-FX draft without
modification of the encoding set and define both a new MIME type (e.g.
image/tifffx or image/tifx) and a new file extension (e.g. .tifx or .tfx).
The new MIME type and extension circumvents interoperability issues with
TIFF 6.0. 
        Advantages: i) Retention of color and high quality encodings, ii) no
disruption of IFax products under deployment, and iii) a single integrated
specification.
        Disadvantages: i) Licensing issues to be resolved, and ii)
unpredictable approval schedule due to license resolution. 

     2. Interoperable TIFF-FX: - use the new interoperability document to
generate a TIFF-FX subset that is image/tiff interoperable, retaining the
current image/tiff MIME type. 
        Advantages: i) No licensing issues, and ii) predictable approval
schedule.
        Disadvantages: i) Loss of color and high quality encodings, ii)
disruption of IFax products under deployment.

     3. Interoperable and non-Interoperable TIFF-FX: - use the new
interoperability document to generate two subsets, a) Interoperable TIFF-FX,
as per #2, and b) non-Interoperable TIFF-FX, which is composed of the
remaining encoding subset. As with Full TIFF-FX, define both a new MIME type
and a new file extension for the non-Interoperable TIFF-FX.
        Advantages: i) Base-level black-and-white has no licensing issues,
ii) predictable base-level approval schedule iii) retention of color and
high quality encodings, iv) minimal disruption of IFax products under
deployment.
        Disadvantages: i) Licensing issues to be resolved for color & high
quality, ii) unpredictable color & high quality approval schedule, iii) two
disjoined specifications.

     4. Interoperable and Full TIFF-FX: - this is a combination of options 1
and 2.
        Advantages: i) Base-level black-and-white has no licensing issues,
ii) predictable base-level approval schedule iii) retention of color and
high quality encodings, iv) no disruption of IFax products under deployment,
and v) base-level specification may be phased out as viewers advance.
        Disadvantages: i) Licensing issues to be resolved for color & high
quality, ii) unpredictable color & high quality approval schedule.

rc - Option 2, Interoperable TIFF-FX, was selected to move forward at this
time.

p  - Justification of the selection must be documented and communicated to
the ITU.

p  - Both the resulting specification and the Implementors Guide should
contain explanation of the interoperability issues and countermeasures.

p  - The resulting specification(s) may be resubmitted to the IESG for Draft
Standard consideration if there are draft-ietf-fax-tiff-fx-09.txt
function/feature deletions or no changes. This means that Full TIFF-FX, with
no changes, and both the Interoperable TIFF-FX and non-Interoperable TIFF-FX
subsets, without any additions, may be resubmitted to the IESG for Draft
Standard consideration. Any required specification additions shall result in
recycle as Proposed Standard. 

p  - Resolution of IPR issues associated with Full TIFF-FX and
non-Interoperable TIFF-FX needs to progress in parallel with the above
activates and the ITU should be kept informed. 

---snip---

> 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.
The second paragraph should be depersonalized and clarified to note that
there was confusion as to which specification was being addressed by the
question of number of reviewers. The question was asked toward the end of
the Schema, not the TIFF-FX Extension presentation. The respondent was a
reviewer of the Schema extension, which is a very new draft with little time
for review. Revise as follows:
"Toward the end of the Schema extension presentation a member ask how many
had read the draft, there was no clarifications as which draft was being
referenced. There was acknowledgement from on member who had reviewed the
Schema drat. The requestor then asked whether the work should be continued,
without much response. No conclusions could be drawn."

---

From: Scott Foshee <[email-masked]>
Date: Tue, 14 Aug 2001 17:25:03 -0700

Greetings all....

Claudio and Tamura-san,

I concur with Lloyd that you and Graham did an excellent job of 
capturing the meeting notes in their origional form.

However, I must disagree with Lloyd's proposed revisions on numerous 
points.  I do not think it is in the best interests of the working 
group for us to re-hash the discussion under the guise of accurately 
capturing the meeting notes.  I recommend we go with Graham's and 
Claudio's original notes.  If this can not be supported, then I will 
need to offer comments and counter proposals to almost all of Lloyd's 
comments.  I do not feel his comments capture the neutral spirit of 
Graham's and Claudio's comments.

Please let me know how you wish to proceed on this.

Scott

(Also, please note that I have chosen to include the IEEE IPP group 
in the discussion prior to the Internet Fax committee publishing the 
minutes because Lloyd included them in the discussion.)

>From: "McIntyre, Lloyd" <[email-masked]>
>To: "'IETF - fax WG dl'" <[email-masked]>,
>    "'IETF - John Klensin (IAB Chair)'" <[email-masked]>
>Cc: "'PWG - IPPFax DL'" <[email-masked]>
>Subject: IFX> FW: notes from the ietf FAX wg meeting at IETF 51
>Date: Tue, 14 Aug 2001 16:14:51 -0700
>Importance: high
>X-Priority: 1
>X-Security: MIME headers sanitized on smtp-relay-2
>	See http://www.impsec.org/email-tools/procmail-security.html
>	for details. $Revision: 1.129 $Date: 2001-04-14 20:20:43-07
>Sender: [email-masked]
>
>Claudio and Tamura-san

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 16 Aug 2001 18:23:13 +0900 (JST)

Hello everyone,

I checked some of the mails.

Regarding IETF-FAX WG minutes, it seems that we need to modify it.
I would like to say, "easy to understand" and "simple".

Especially, regarding TIFF-FX issue, I would like to shrink it
as the most important parts are kept. For example, the things that
do not relate to our conclusion at the meeting might be deleted.
Also, what was not discussed at the meeting might be deleted.
Just my idea.

Of course, at first, I need the agreement by Claudio.

Anyway, I would like to confirm our conclusion at the meeting.

1. Safe subset for Draft Standard Consideration
2. Final agreement will be made in this ML.

But, it is lack of information for the people that did not attend
our meeting. Because other choices are not written in the draft minutes.
Fortunately, in the meeting, they were shown, although they were not accepted.
At least, they have to be shown in this ML.

But, please wait for the others. I do not check all the related mails.

Also, please wait for the next version of our draft minutes.

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 20 Aug 2001 07:47:41 +0900 (JST)

To all:

I checked Lloyd's suggestions.

I think some of corrections are reasonable because of ambiguity.
Others are not discussed at the meeting. They are considerable options
for TIFF-FX. This should be done from now on.

Claudio and I cannot make our mintues that is completely satisfactory
to both of you. Therefore, please accept it even if there are something
that you have complaint.

I repeat my policy.
> I would like to say, "easy to understand" and "simple".

Anyway, until Claudio comes back, please wait.

The next, I would like to introduce the background.

Some slides at the meeting:
-------------------------------------------------------------------------------

- TIFF extension beyond basic black-and-white induces incompatibility
  with existing base tiff applications
    Should we retreat to only base set black-and-white, retaining full
    compatibility with existing tiff base or continue to embrace the defined
    path that introduces new encodings for both black-and-white and color that
    are consistent with ITU-T fax encodings?

    1 If decision is to retain extended encodings then compatibility must be
      addressed, two options are:
        Different MIME type and file extension
	or
	Different MIME type and file extension  together with a new Adobe
        issued TIFF version that encompass the TIFF-FX encodings

    2 If decision is to retreat to only base black-and-white then we must:
        Delete all TIFF-FX profiles other than S and F with constraints as follows:
        encodings MH, MR and MMR resolutions of 200x100 and 200x200 paper size A4/letter

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

These are just descriptions. Some of the above may not be appropriate.

> 2. Final agreement will be made in this ML.

But, we do not decide precisely what is safe subset.

> quality, ii) unpredictable color & high quality approval schedule.

These are just ideas. Some of them may NOT be appropriate.
Also, there may be other options.

Anyway, we must have our conclusion, considering there are RFC2301 products
on the market.

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Tue, 21 Aug 2001 18:54:56 +0900

Tamura-san,

I comment below.

>Some slides at the meeting:

I think that we need clarify what is a safe subset. 
Is the below correct?

- all TIFF-FX profiles other than S and F with constraints as follows:
- encodings MH, MR and MMR resolutions of 200x100 and 200x200 paper size A4/letter

I would like the safe subset to cover more wide range if possible
because many manufacture already have implement Internet Fax
according to RFC2301.

>Anyway, we must have our conclusion, considering there are RFC2301 products

I prefer No. 4.  It seems less disadvantage to us. It is also suggested
by Dave-san in the meeting. 

Regards,

Kiyoshi Toyoda

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 22 Aug 2001 08:31:46 +0900 (JST)

Thanks for your comment.

(I change the subject)

> - encodings MH, MR and MMR resolutions of 200x100 and 200x200 paper size A4/letter

Unfortunately, I am not the right person to answer it.
As my personal opinion, considering the implementation report and
the license issue, we should decide it.

We may need the comment from the editors.

> because many manufacture already have implement Internet Fax

Right. We already have products int the market. I believe most implementers
have at least Profile F.
Now, I am collecting the implementation information of Japanese IFAX products.
I think one of our issues is color. I know Xerox has all profiles.

Is there anyone that support Color profile?

Regards,

---

From: "John Pulera" <[email-masked]>
Date: Tue, 21 Aug 2001 17:46:51 -0700

I am a developer working for Minolta.

I have read about proposals to split the TIFF-FX into two documents, one
with TIFF 6.0 compatible profiles (S and F) that would be published soon and
one with the other profiles that would await resolution of IP issues.

I believe it would be better and faster to resolve the IP issues quickly and
publish TIFF-FX as a single revised document.   The revised document should
restrict the use of the existing image/tiff MIME type and .tif (or .tiff)
file name extensions to profiles S and F, and assign a new MIME type and
file name extension for the profiles J, C, L, and M (perhaps image/tifx and
.tfx (or .tifx)). By restricting image/tiff to profiles S and F, TIFF-FX
keeps compatibility with TIFF-6. By allowing image/tiff and .tif (or .tiff)
for the S and F profiles, TIFF-FX reflects what exists in many deployed
TIFF-FX devices.

Let’s call this solution option 5. It’s a variant of options 1 and 4.

If the document is split, the publishing of the document containing profiles
that are of interest to Minolta may be delayed a very long time. Also, it
will take several months to split the document and gain approval of the one
with the S and F Profiles.

If the document remains as one, we avoid spending the time to edit and gain
acceptance of the new documents. In addition, with a single document there
are more people to pressure Adobe and Xerox to agree quickly on the IP
issues.

Regards,

John Pulera
-----------------------------------------
John Pulera
Software Engineer
Minolta Systems Laboratory
[email-masked] <mailto:[email-masked]>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of McIntyre, Lloyd
Sent: Tuesday, August 14, 2001 4:15 PM
To: 'IETF - fax WG dl'; 'IETF - John Klensin (IAB Chair)'
Cc: 'PWG - IPPFax DL'
Subject: FW: notes from the ietf FAX wg meeting at IETF 51
Importance: High

Claudio and Tamura-san

Regards,
Lloyd

---snip---

Clarify as follows:

---

From: "Ryuji Iwazaki" <[email-masked]>
Date: Wed, 22 Aug 2001 14:32:22 +0900

TOSHIBA TEC has products which implement profileS, F and J.
If a new MIME type (eg. image/tifffx) is defined for TIFF-FX,
there is an interoperability issue between existing products and new
products which
deploy the new MIME type.
It is very difficult to update the firmware of existing products in order to
handle the new MIME type, because users can not update the firmware,
service people of dealers or manufacturers have to update in users' site.

We can distinguish between TIFF V6 and TIFF-FX using RFC2302.
IFAX products use the sub-type as follows.

Content-type: image/tiff; application=faxbw

That's my idea.

Regards,

Ryuji Iwazaki
TOSHIBA TEC Corporation

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 22 Aug 2001 19:39:42 +0900 (JST)

John,

> Let’s call this solution option 5. It’s a variant of options 1 and 4.

Yes, a good idea. One document is better for all implementers, I think.
But, how do we separate is the discussion issue.

<snip>

> are more people to pressure Adobe and Xerox to agree quickly on the IP

Right. We need to avoid spending time for our market.
Thanks for your comment.

Regards,

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 22 Aug 2001 19:51:45 +0900 (JST)

Iwazaki-san,

> Content-type: image/tiff; application=faxbw

After the meeting, I talked and mailed more with lots of people.
I understand the situation.

Yes. You are right. RFC2302 intension is what you are suggesting.
But, unfortunately, it seems that the application parameter is not
handled by most viewers or something. This is one of the reason for
compatibility issue.

Even if Profile J will not be included in the safe subset,
it is better to address that some previous machines use image/tiff
for all Profiles in the new document. 

Any other implementation information is welcome.

Regards