TIFF-FX: where are the implementor's statements of compliance?
"Larry Masinter" <[email protected]>
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <000201c17fb9$cf6a44d0$0b78bfd1@larrypad> |
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.