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