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

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 protected] <mailto:[email protected]>


-----Original Message-----
From: [email protected] [mailto:[email protected]]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
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 protected]]
> Sent: Thursday, August 09, 2001 9:26 AM
> To: [email protected]
> Cc: [email protected]
> 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."