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" <Lloyd.McIntyre@pahv.xerox.com>
>To: "'IETF - fax WG dl'" <ietf-fax@imc.org>,
> "'IETF - John Klensin (IAB Chair)'" <klensin@jck.com>
>Cc: "'PWG - IPPFax DL'" <ifx@pwg.org>
>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: owner-ifx@pwg.org
>
>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:Claudio.Allocchio@garr.it]
>> Sent: Thursday, August 09, 2001 9:26 AM
>> To: ietf-fax@imc.org
>> Cc: klensin@jck.com
>> 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."
>
>
This archive was generated by hypermail 2b29 : Tue Aug 14 2001 - 20:36:21 EDT