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

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

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

From: McDonald, Ira (IMcDonald@crt.xerox.com)
Date: Thu Aug 16 2001 - 12:09:52 EDT

  • Next message: Hastings, Tom N: "IFX> FW: Agenda IPPFAX telecon, Friday, Aug 17, 10-12 AM PDT (1-3 PM EDT )"

    Hi folks,

    Quite a different slant on the current IPR problems around TIFF-FX
    from James Rafferty (one of the co-authors of TIFF-FX, along with
    Steve Zilles of Adobe!!).

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: James Rafferty [mailto:jrafferty@humancomm.com]
    Sent: Tuesday, August 14, 2001 9:16 PM
    To: Ietf-Fax
    Subject: Re: FW: notes from the ietf FAX wg meeting at IETF 51

    To all -

    I have some comments on the TIFF-FX portion of the
    IETF minutes as reported by Claudio Allocchio.

    My comments are not regarding the accuracy of
    the meeting coverage, but rather on the portrayal of
    what took place when Adobe submitted its license
    letter for TIFF and the concurrent process which led
    to standardization of RFC 2301.

    I have serious concerns about what appears to
    be an effort by some to re-write history
    or to reverse decisions previous made witin the WG. My opinions
    here are my own, based on my experiences as
    WG co-chair and RFC 2301 contributor during the time in question.

    My advance apologies for the length of the message, but
    there were several issues raised and my comments
    are in response to them.
    > -----Original Message-----
    > > From: Claudio Allocchio [mailto:Claudio.Allocchio@garr.it]
    > > Sent: Thursday, August 09, 2001 12:26 PM
    > > To: ietf-fax@imc.org
    > > Cc: klensin@jck.com
    > > Subject: notes from the ietf FAX wg meeting at IETF 51
    > >

    <snip>

    > > Short notes of the ietf FAX WG meeting - IETF 51 London, UK
    > > ------------------------------------------------------
    > >
    <snip>

    > > 2.2 TIFF-FX
    > > draft-ietf-fax-tiff-fx-09.txt
    > > draft-ietf-fax-tiff-regbis-02.txt
    > >
    > > The documents approval is slowed down by a series of problems
    > > which were
    > > detected during the process. ITU-T also needs a quick
    > > resolution of there
    > > problems as stated in the communication letter from ITU-T
    > > SG16 meeting.
    > >
    > > The problem, detected at first as an IPR issue raised by
    > > Adobe in January
    > > 2001, was escalated to IESG and IAB which examined carefully
    > > all the aspects,
    > > and identified also some additional compatibility issues.
    > >
    > > John Klensin (IAB) reported to the WG.
    > >
    > > The TIFF Story, actually had many different steps and
    > > chapters. During the
    > > analysis of the problem there were many iterations between
    > > the IESG and
    > > the IAB which at the end pointed out two Separate Issues:
    > >
    > > - WG responsibility for interoperability
    > > - IPR questions
    > >
    > > At first the interoperability. This is the "Main IETF Goal" to be
    > > achieved, and its meaning should span forward and sideways. The main
    > > principles are that:
    > >
    > > - Implementations of one protocol must interoperate
    > > - Implementations of related protocols should interoperate
    > > - Deviations must make sense and have a clear rationale behind.
    > >
    > > In its original goals (and as stated in the charter) the fax wg had to
    > > create a Fax Model that should Interoperate with fax fabric and
    > > Interoperate with e-mail fabric. More over it should avoid having to
    > > choose between the two fabrics. For this reason TIFF was
    > > chosen because It
    > > was widely believed that it would be interoperable with
    > > existing viewers
    > > and editors, especially Viewers expected to be used with image/tiff in
    > > e-mail. This shoud also be the start of the "global messaging
    > > service".
    > >
    > > The question now is: can we meet all these constrains? Is
    > > TIFF the right
    > > choice to accomplish them?
    > >
    This is a gross oversimplification of the compatibility
    issues and ignores the substantial use of TIFF-F
    by the computer fax community, which uses
    products such as fax boards and fax modems in
    association with TIFF-F implementations. So,
    the interoperability issues which were being
    addressed when TIFF was considered by the WG and
    eventually chosen were to focus on the current
    uses of TIFF by both the fax community and the
    email community. This current use of TIFF
    had a great deal of influence on the drafting
    of the TIFF-F and later TIFF-S sections
    of what became RFC 2301. Steve Zilles
    of Adobe was actively involved in these
    discussions both on the list and in
    small editing groups.

    > > Basic TIFF does not support colors, and different
    > > resolutions, but is it
    > > compliant with the existing TIFF readers, and e-mail User
    > > Agents (MUAs).
    > > 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. These extensions were
    > > specified into TIFF-FX, and ITU-T decided to adopt and reference it.
    > > However TIFF-FX is already beyond Basic TIFF.
    > >
    I will note that TIFF-F is NOT the same as Baseline TIFF (since
    Baseline TIFF makes no use of compression and is therefore
    unsuitable for transport of facsimile). However, the TIFF 6.0
    spec also goes beyond baseline TIFF and DOES include
    tags that can represent the compressions used in pre-1996
    fax (i.e MH, MR and MMR). It was clear from our
    discussions with implementors when RFC 2301 was being
    drafted that many conventional TIFF viewers as implemented
    could typically handle both the Baseline TIFF and TIFF-F
    extensions.

    > > 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.
    Well, actually, at the direct request of Steve Zilles, the RFC 2301
    content shows exactly how TIFF-F is derived from TIFF 6.0
    and is therefore fully consistent with the Adobe license letter.
    So, its not merely "de facto" extensions, and yes, there
    are no substantive interoperability problems. In fact, some
    implementors told me after RFC 2301 was published that
    the text had gone a long way to resolve and reconcile some of the
    different interpretations that had been made of Joe Campbell's
    TIFF-F documents that were published in the early 90's.

    >However the extensions intriduced into TIFF-FX are
    > > a superset,
    > > and thus only some Ifax devices can correctly handle them.
    > >
    Well, yes, there are extensions. However, if Ifax devices
    and TIFF implementations follow the rules of TIFF 6.0 and RFC 2301, they
    will ignore
    tags they do not understand. If they do not do this,
    they have broken the rules, which we cannot prevent.

    > > 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)
    > > - hether the interoperability profile is right given these issues
    > > - and any other similar tradeoffs that might have been made
    > > without full
    > > evaluation.
    > >
    Well, excuse me, but we did a full evaluation of all of these
    options during the long, drawn out (1 year) standardization process
    for RFC 2301. All members of the WG had a chance
    to participate and Adobe and Xerox both
    had people who were among the RFC 2301 authors.
    The ITU-T also had substantial discussion of these issues
    prior to agreeing that they wanted to reference RFC 2301
    for T.37.

    > > The IAB believes now it is late in the game, so these reviews may not
    > > change anything, but they are important for learning, and context, and
    > > predicting problem areas and determining whether the
    > > meta-qualifications
    > > for Draft Standard are met.
    > >
    There was substantial additional work done on RFC 2301 interoperability
    at 2 public Fax Connect interop events and in other activities.
    The results of these activities have been reported to the WG
    and the IESG. Why is this now being questioned?

    > > John Klensin then reported on the IPR issues, which invove
    > > both Adobe and
    > > Xerox.
    > >
    > > 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.
    > >
    Briefly, when Adobe submitted their license letter to the IETF and
    the ITU-T, there was only 1 proposal on the table for standardization,
    the TIFF-FX draft which later became RFC 2301. Given
    that Steve Zilles was both a WG member and TIFF-FX
    co-author, my basic interpretation at that time as co-chair was
    that Adobe was giving the IETF the go-ahead to produce
    the TIFF extensions being addressed in RFC 2301. No
    mention was made of any dependencies on "TIFF 7",
    which IS NOT referenced in RFC 2301, since the
    document uses TIFF 6.0 and then clearly indicates
    which extensions go beyond fields defined in TIFF 6.0.

    I might add that Steve Zilles was a strong advocate
    in the WG for
    producing a TIFF-FX document which included
    both TIFF-F content AND the profiles which went
    beyond TIFF-F.

    > > 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.
    > >
    > > At last, we have the ITU issue, who is referencing our
    > > documents. But ITU
    > > approach to IPR is different, and a licence issued to the
    > > IETF might not
    > > fully apply also to ITU. There is a strict need to coordinate with ITU
    > > also on these IPR matters, to avoid future problems. It is in
    > > fact clear
    > > that what was released to IETF is not automatically released
    > > to ITU (and
    > > viceversa).
    > >
    This is a red herring IMHO. The ITU-T received a letter from
    Adobe which is basically identical to that received by
    the IETF; so the IPR issue was dealt with independently
    in accordance with the rules of both groups. ITU-T participants
    may recall that there was a great deal of attention paid
    to procedural matters during this unprecedented first direct
    collaboration of the IETF and the ITU-T, before RFC 2301
    and the other IETF RFCs were referenced by T.37. .

    > > The discussion of the problem and the WG conclusions.
    > > -------------------------------------------------
    > >
    > > The original reasons for using TIFF were lightweight,
    > > extensibility and
    > > its ITU compatibility, and it ability to be understood as a MIME type
    > > image/tiff by most of the MUAs.
    > >
    > > The extensions are actually needed to meet the new specification which
    > > ITU-T had done, but the new extensions also introduce
    > > impatibility and IPR
    > > possible clashes.
    > >
    > > Dave Crocker suggest as a first prroximation solution to skim down the
    > > core specification to a "safe" subset, and pursue the other issues
    > > separately, with a separate MIME type.
    > >
    Well, this solution was proposed several times during the RFC 2301
    standardization, but not supported by the WG, so RFC 2301
    went ahead with support for the 6 profiles. Is there
    now a consensus to reverse the previous direction???

    > > Scott Forshee suggested also that other focus has been on JPEG-2000
    > > specifications , and work is progressing on a different (planned) MIME
    > > type including MRC capabilities. However igher level features of
    > > JPEG-2000 are generally not widely deployed. He proposed the wg to
    > > reconsider JPEG-2000 as an alternate to TIFF-FX. Moreover, part of the
    > > reason for Adobe's objections are to keep the use of TIFF freely
    > > available.
    > >
    > > There were objections to this proposal, stating the JPEG-2000
    > > is not yet
    > > in good shape, has not yet a MIME type registered, too, and its wide
    > > deployment is not existing at the moment.
    > >
    Well, but of course. This is not an acceptable solution.

    > > A discussion followed, considering if one should simply use
    > > the version
    > > label into MIME typ definition to define which level of TIFF is being
    > > used, or just a totally new type.
    > >
    > > Claudio Allocchio suggested that image/tiff should be used
    > > onlyfor minimum
    > > interoperable features and anything else should have a
    > > different name and
    > > label; this will have to happen for TIFF-7 in any case.
    > >
    > > Lloyd McIntyre suggested as simple solution to revert to previously
    > > registered version of TIFF, i.e. TIFF 6.0, excluding also any widely
    > > deployed de facto extensions. There was a discussion on this,
    > > and Scott F.
    > > stated that TIFF 6.0 was issued in 1992, with updates via by technical
    > > notes, which are widely implemented. Thus RFC 2302 is OK with the way
    > > that Adobe and others use TIFF. We should focus on the
    > > TIFF-FX spec, to
    > > cut it back to non-controversial features.
    > >
    > > At this point Claudio A. asked the wg members present at the
    > > meeting if
    > > anyone strongly oppose the approach proposed by Dave C.?
    > >

    <snip>

    > >
    > > The wg expressed consensus on the above approach. This
    > > consensus need to be
    > > confirmed by the mailing list.
    > >
    I will look forward to the discussion of this proposal on the mailing
    list, where the decision needs to be made.

    > > Claudio A. summarised the conclusions to be reported into the
    > > minues, and to
    > > facilitate the understanding of the approach by anybody
    > > including those not
    > > present at the meeting:
    > >
    > > - we must consider for interoperability test of RFC2301
    > > also existing
    > > mail user agents (MUAs), and they should be able to read
    > > image/tiff
    > > bodyparts generated bu Ifax devices. Interoperability is
    > > the choice.
    > >
    If they are broken and cannot ignore tags that they do not
    understand, that is not the problem of the IETF.
    > > - we must also consider interoperability with existing tiff capable
    > > software, e.g. saving the image/tiff to a file and
    > > reading it with ...
    > > Photoshop, and other tiff files readers.
    > >
    I think the most relevant set is the readers used by the
    fax and email communities, since this is the focus
    of Internet fax. There are all kinds of other TIFF
    uses which are irrelevant to this discussion.

    > > - we should produce a new interoperability report, and based on this
    > > we should detail the revision of RFC2301, to fit any feature which
    > > proved to interoperate in all above cases, even if not included in
    > > basic TIFF 6.0 specification.
    > >
    > > - thus existing tiff-fx Ifax devices go beyond this, as they
    > > my generate
    > > extensions which do not interoperate correctly with the above
    > >
    We cannot turn back the clock and pretend that the many TIFF-F
    implementations of the past 10 years do not exist, nor is
    it acceptable to ignore the many Ifax implementations
    which use the TIFF-S subset of TIFF-F. The
    practical baseline for implementations is to support TIFF 6
    and at least up to the RFC 2301 TIFF-F profile. The
    existing interop work focused heavily on these areas,
    with a smaller number of implementors supporting
    the other RFC 2301 profiles which had additional extensions.
    BTW, those extensions did not materialize out of
    nowhere, but were precisely put together to provide
    interoperability with the huge G3 install base
    and the T.30 extensions approved during the 1990's which
    have added support for JBIG-1, JPEG and, more recently,
    MRC. The ITU-T work preceded the IETF work and
    was referenced by RFC 2301.

    > > - thus we should define how to create a NEW format (both for
    > > files and
    > > for MIME readers) with a different name which may be
    > > tiff-fx, or totally
    > > different, to make clear to implementers and devices that
    > > "this is an
    > > extended new format" (even if based on tiff in origin).
    > >
    > > - the reason for removing from RFC2301 revision some features is
    > > because they do not interoperate on the global service,
    > > even if they
    > > proved to interoperate among Ifax implementaions.
    > >
    Whoa! I have big problems with this. There is a broad community
    of TIFF implementors, including the Ifax implementors. If the
    Ifax implementations interoperate AND also interoperate
    with common fax community use of TIFF, this does meet
    the needs for interoperation within the IETF community IMO.

    > > - the "recuded set" specification will be submitted for
    > > Draft Standard
    > >
    > > - we should, at the same time, produce a new "extended specification"
    > > docuement, which includes the extensions existing in RFC2301 and
    > > dropped in the Draft Standard document, and might also include the
    > > further extensions proposed for "full mode". This
    > > document(s) should
    > > also define a different MIME type registration for this extended
    > > specification. This new specification should go as
    > > Proposed Standard
    > >
    > > - we need to investigate if it is possible to declare
    > > RFC1301 "Updated"
    > > by the new Draft Standard document, at least until the new
    > > "Proposed
    > > Standard" document obsoletes RFC2301. ADs suggestions are expected.
    > >
    > > - we should carefully inform ITU-T of the reasons of this choice.
    > >
    > > - the Draft Standard version of the specification would also not have
    > > (apparently) IPR issues related, and the extended mode one should
    > > carefully consider IPR problems while being specified.
    > >
    If there was an attempt to extract TIFF-F and TIFF-S from the
    RFC 2301, assuming that WG consensus on this action
    was demonstrated,
    I would see no reason why this subset would not go forward
    as a draft standard, based on now many years of implementation
    history, which has been documented at various interop events.

    <End of Comments>

    James Rafferty



    This archive was generated by hypermail 2b29 : Thu Aug 16 2001 - 12:10:06 EDT