IFX Mail Archive: IFX> RE: notes from the ietf FAX wg meetin

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

From: John Pulera (jpulera@minolta-mil.com)
Date: Tue Aug 21 2001 - 20:46:51 EDT

  • Next message: Hiroshi Tamura: "IFX> 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
    jpulera@minolta-mil.com <mailto:jpulera@minolta-mil.com>

    -----Original Message-----
    From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]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: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 21 2001 - 20:44:49 EDT