IFX Mail Archive: Fwd: IFX> FW: notes from the ietf FAX wg m

IFX Mail Archive: Fwd: IFX> FW: notes from the ietf FAX wg m

Fwd: IFX> FW: notes from the ietf FAX wg meeting at IETF 51

From: Scott Foshee (sfoshee@adobe.com)
Date: Tue Aug 14 2001 - 20:25:03 EDT

  • Next message: Hastings, Tom N: "IFX> Notes from IPPFAX telecon, Tuesday, Aug 14, 8-10 AM PDT (11-1 PM EDT )"

    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