Subject: TIFF-FX issue and progress

From: "Buckley, Robert R" <[email-masked]>
Date: Fri, 7 Dec 2001 12:44:37 -0500

As one of the "editors" of RFC 2301, the first time I heard anyone suggest
that TIFF-FX may be outside the scope of the 9/97 Adobe license was during
IETF Last Call late last year. This had not come up at all earlier during
the process and, in particular, did not come up when TIFF-FX went to
Proposed Standard, in spite of full participation in the WG by Adobe at that
time. Regardless, Xerox is willing to help move things forward from the
current impasse. Adobe has indicated that one way of addressing their
objection is to update the underlying TIFF specification so that they can
acknowledge that TIFF-FX is within the scope of the 9/97 license.  To help
achieve this end, Xerox is prepared to offer a royalty-free license with
customary terms and conditions, for the use of Xerox-owned IP in the
underlying TIFF specification in a way that is timely and compatible with
TIFF-FX. Removing a perceived barrier to making the TIFF-FX standard widely
available should make it possible for everyone--the IFax WG and those with
TIFF-FX products--to move on.

Rob Buckley

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 7 Dec 2001 23:27:36 -0800

I think there's been some misunderstanding of the IETF process.
At least at the IETF meeting, we should focus on what's necessary
to move forward in the IETF:

- The IETF doesn't evaluate intellectual property claims.
  (RFC 2026, section 10.3.2 (B))
- To move to "draft standard" you need:
   - multiple independent implementations of every feature
   - statements from the implementors that they
     "have taken adequate steps to comply with"
     any claimed intellectual property rights.
  (RFC 2026, section 10.3.2 (A) and section 4.1.2)

In the case of communication standards with two parties, "multiple
independent implementations" is taken to mean "two readers and
two writers" or "two clients and two servers".

It's nice to hear about Rob's offer to license intellectual
property rights, the main sticking point is that there are no current
implementations of most of the features, and no statements from
implementors about having taken adequate steps to comply with
any of the many intellectual property claims.  You don't need
license grants, you need statements from implementors.

The implementations listed in the interoperability
report for Internet Fax only demonstrated some (not even all) of
the features of profile S and F. There are no implementations
of profile L where there are statements of having done whatever
is needed about JBIG patents; there are no implementations of profile
M where there are statements of having obtained adequate licensed
technology to actually implement an encoder or decoder.

Even independent of statements about intellectual property claims,
there are no implementations of many of the "features". For example,
there are no implementations that use either image/tiff-fx or
image/tiff MIME type for any profiles other than S and F, because
the only implementations listed for other profiles did not use MIME
at all for the transfer. (The 'interoperability' FaxConnect
test consisted of writing out files onto a floppy on one machine
and reading it in on another). It isn't clear whether there are
any implementations that use the features in RFC 2301 that were
added to profile F (namely, the 'optional' GlobalParametersIFD),
or whether there was any testing of senders creating TIFF files that
had parameters in the GlobalParametersIFD that were not in the
individual image IFDs or where the GlobalParametersIFD differs
from and is overridden by the parameters in the invidual image.

The operational requirement for "draft standard" just says "sufficient
successful operational experience". However, it seems really a
stretch to claim that "no operational experience" is "sufficient
successful operational experience", since there are no successful
operational implementations of profiles other than S and F. 

I think the only way to move to "draft standard" is to restrict
the document to those features for which there are actual operational
implementations, where we can obtain statements from the implementors
that they have obtained all of the licenses they think are necessary
to build and use operational software. My belief is that will bring
us back to profiles S and F and most likely back to RFC 2306.

References:

RFC 2026 Section 4.1.2:

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.  If patented or otherwise controlled technology
   is required for implementation, the separate implementations must
   also have resulted from separate exercise of the licensing process.

and

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification. 

RFC 2026 section 10.3.2:

   (A)  Where any patents, patent applications, or other proprietary
      rights are known, or claimed, with respect to any specification on
      the standards track, and brought to the attention of the IESG, the
      IESG shall not advance the specification without including in the
      document a note indicating the existence of such rights, or
      claimed rights.  Where implementations are required before
      advancement of a specification, only implementations that have, by
      statement of the implementors, taken adequate steps to comply with
      any such rights, or claimed rights, shall be considered for the
      purpose of showing the adequacy of the specification.

   (B)  The IESG disclaims any responsibility for identifying the
      existence of or for evaluating the applicability of any claimed
      copyrights, patents, patent applications, or other rights in the
      fulfilling of the its obligations under (A), and will take no
      position on the validity or scope of any such rights.

---

From: Hiroshi Tamura <[email-masked]>
Date: Sat, 08 Dec 2001 17:13:26 +0900 (JST)

Larry,

Thanks for remiding everybody of the process of Draft Standard.

> two writers" or "two clients and two servers".

You are right.

With regard to the above,
the **NEW** implementation tests are necessary for the process.
Because the current I-D defines new MIME content type
for Profile J, C, L and M.
I'm sure the editors understand it.

To editors of TIFF-FX:
Please provide your plans for the implementation test at the SLC meeting.
I'm sure I requested it in October or November.

Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG
E-mail: [email-masked]

---

From: Hiroshi Tamura <[email-masked]>
Date: Sat, 08 Dec 2001 17:12:41 +0900 (JST)

Rob,

Thank you for your valuable comment.

> TIFF-FX products--to move on.

I cannot attend the SLC meeting. I hope the comment will help it go forward
at the meeting.
With regard to the process itself, please read the separate mail.

Regards,

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Sun, 9 Dec 2001 21:35:40 -0800

Larry,
There are a number of inaccuracies or misunderstandings in your message that
deserver clarification.
- your statement that there are no statements from implementors is
incorrect: please check the IETF IPR statements web site.
- your statement with regard to no current implementations of most of the
features makes no mention of the RFC2301 implementation report, completed in
March 1999. Until your Adobe colleagues raised licensing issues, there have
been no negative comments on this report by anyone in the WG. 
- there are currently product implementations of all RFC 2301 profiles,
except one (L). So there is successful operational experience, and L was
included in the interoperability testing. 
- the WG agreed that the means by which the files were interchanged between
writers and readers was irrelevant to the interop test since TIFF-FX is a
file format. 
- it was also agreed that no JBIG statement was required since there were a
significant number of JBIG2 fax products in the market, which obviously
executed necessary licenses.

In regard to your RFC 2306 proposal, the WG concurred in 1998 to keep
TIFF-FX as a single document and recently reaffirmed its position with the
Option 5 consensus.

Lloyd

> -----Original Message-----
> From: Larry Masinter [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 11:28 PM
> To: 'Buckley, Robert R'; [email-masked]
> Cc: [email-masked]
> Subject: TIFF-FX: where are the implementor's statements of 
> compliance?
> 
> 
>

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 10 Dec 2001 16:31:06 +0900 (JST)

Folks,

> been no negative comments on this report by anyone in the WG. 

Yes. I would like to emphasize the above things that Lloyd said.
There were no comments where the report was submitted to IESG.
Also, there were no negative comments when RFC2301 had come out.
Adobe was one of the contributors.

> > two writers" or "two clients and two servers".

This is the fact. Regading it, I searched the editors' comment in ML.

From: "McIntyre, Lloyd" <[email-masked]>
Subject: RE: option 5 for TIFF-FX
Date: Wed, 10 Oct 2001 14:19:29 -0700

<snip>

>   TIMELINES

<snip>

> - A test plan draft for draft-ietf-fax-tiffx-reg-xx interoperability testing
> and verification of that current viewers can successfully read Profile S & F
> should be available for the WG meeting.
> - End of January 2002 is the target for completion of the test plan and
> sign-up of participants.
> - End of February 2002 may then be a reasonable target for completion of
> draft-ietf-fax-tiffx-reg-xx interoperability testing, along with Profile S &
> F viewing confirmation.

So, the editors understand the situation.
Also, I would like follow a little.

> for Profile J, C, L and M.

There is only the change for the content-type.
I believe TIFF-FX test itself is covered by the report that
the editors already submitted.
Therefore, only the test for the content-type is necessary, I think.
"Two readers and two writers" or "two clients and two servers".

Again, I'm very sorry that I cannot attend SLC meeting.
I hope my comment help the discussion.

BTW, unfortunately, Claudio does not have his PC at SLC.
I think he can read the related messages from the terminal-room,
before our meeting starts.
Could you please someone contact Claudio and ask him to read them
for confirmation?

Regards,

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 10 Dec 2001 15:56:30 +0100

I read them... and I'll print them

:-)

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                        Project Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

     PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 10 Dec 2001 09:53:09 -0800

> Also, there were no negative comments when RFC2301 had come out.

The interoperability test made in March 1999 was made at the
point of moving the document to "Proposed Standard". Proposed
standard does not require independent interoperable implementations
with intellectual property license statements from the
implementors. No comment about the lack of implementations
or the lack of statements from the implementors was appropriate
at that time.

"Proposed Standard" does not require implementations
at all. All "Proposed Standard" requires is that implementations are
believed to be possible. So comments on the adequacy of implementations
 were not appropriate.

"Proposed Standard" does not require licensing. In any case,
some of the notification about intellectual property claims
were made AFTER RFC 2301 was issued; please compare the date
of the IPR statements to the date of the RFC. So no comments
about licensing or IPR statements would have been appropriate
at the time RFC 2301 had come out.

We are now at a different point in the standards process,
trying to move to "Draft Standard". The requirements for
"Draft Standard" are different than the requirements for
"Proposed Standard". 

It is only when one proposes moving to "Draft Standard" that
additional requirements are placed, and when objections
about not meeting those requirements are appropriate.
"Draft Standard" requires implementations and statements
from the implementors.

One might have expected that in the two years since the
release of the "Proposed Standard" documents that there would be
Internet Fax implementations that actually did use these features;
perhaps this was the hope when RFC 2301 was written. But this
has not happened.

There do not seem to be any more implementations, and many of the
implementations that existed in March 1999 are no longer
listed on the web sites of their implementors and the test files
listed are no longer available.  The old interoperability statement
is outdated, some of the implementations were from the
IPR holders or their subsidiaries (and thus could not be
considered 'independent exercise of the license agreement'),
some of the implementations were test suites that did not
need licensing of technology for encoders or decoders, 
and none of the implementations in that document for profiles
other than S and F were "Internet Fax" implementations.

I have raised the comments about the lack of operational
implementations since the proposal to advance the document to "Draft
Standard" was raised. Raising these comments at any previous
time would be inappropriate, because independent interoperable
implementations and "operational experience" were not
required before, and we should give implementors time to
step forward.

But no implementors have stepped forward. Instead we are
given the same old March 1999 interoperability report.

Since at least some level of new interoperability testing
for profiles using "image/tiff-fx" MIME type will be done,
let's make sure that this testing also meets the actual
requirements for "Draft Standard". That way, we can determine
what implementations exist now and determine which features
are actually operational and licensed.

Larry
-- 
http://larry.masinter.net