RE: TIFF-FX: where are the implementor's statements of compliance ?

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 protected]]
> Sent: Friday, December 07, 2001 11:28 PM
> To: 'Buckley, Robert R'; [email protected]
> Cc: [email protected]
> Subject: TIFF-FX: where are the implementor's statements of 
> compliance?
> 
> 
> 
> 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.
>