This message raises to the IESG a new appeal of the decision of the working group chair of the FAX working group to progress the document draft-ietf-fax-tiff-fx-11.txt to Draft Standard. I am re-raising the appeal because, since my last appeal in March, the chair has offered a revised interoperability report. The new report http://www.imc.org/ietf-fax/mail-archive/msg07449.html still does not meet the requirements. Note that while I raised this issue publicly at the March 2002 IETF meeting, I had raised the issue privately with the working group chairs in 2000 and 2001. The reasons why the "TIFF-FX Implementation Report by CIAJ" combined with any previous report does not meet the requirements: (1) wrong document claimed to be implemented (2) actual interoperability wasn't claimed (3) implementations are not independent (4) implementations were not replaceable components (5) IPR licensing may be required, but no IPR licensing statements (6) many features have no implementation reported, many features have only one implementation reported. At the end, I suggest how to move forward. ======================================================= (1) The report does not describe implementation of draft-ietf-fax-tiff-fx-11.txt; it describes implementation of RFC 2301. There were some substantive as well as editorial changes in the 12 versions since RFC 2301. An example of substantive change: The section 2.2.4 New TIFF fields recommended for all fax profiles (including GlobalParametersIFD) is not part of profile F in RFC 2301; it is a part of profile F in draft-ietf-fax-tiff-fx-11.txt. This is a substantive change: with the new document, profile F files might have these parameters while before they would not. There is no evidence that any of the writers of profile F (or S) create a GlobalParametersIFD, or that any of the readers will operate correctly if given a GlobalParametersIFD. Since these fields aren't part of baseline TIFF and the tag values are not in the "private extensions area", using these fields in files labeled at "image/tiff" might have interoperability problems with existing TIFF readers. As another example, http://www.ietf.org/proceedings/99jul/45th-99jul-ietf-20.html notes that there are substantive changes to the JBIG compression profile between RFC 2301 and the internet draft. The implementations reported presumably implemented the old mechanism and not the new one. *** Only consider those implementations which implement the actual specification that is being progressed. ======================================================= 2) The new report does not actually claim there was interoperability. Perhaps this is an oversight, but it only reports implementations and the fact that testing took place. The previous FaxConnect events did not report complete interoperability: http://www.ietf.org/proceedings/99jul/45th-99jul-ietf-20.html "Most important parts of simple mode (RFC 2305) are well implemented, with good interworking" where it says "most" rather than "all", and does not say that anything other than simple mode interoperated well. *** Only consider as "interoperable implementations" those features that were actually tested and actually determined to be interoperable. ======================================================== 3) Some of the implementations in the previous implementation report http://www.ietf.org/IESG/Implementations/TIFF-FAX-implementation.txt are not independent of each other (using the same code library) and are not independent of the implementations in the current implementation report. For example, http://www.qualitylogic.com/genoa_test_tools/tiff/tiff_fx.html notes that the test cases were not produced independently from other implementations. Note that the 'implementation' in this case consists of only of test cases. *** Only consider "independent implementations", where the implementations are "original source code" or where the source of the implementations are clearly independent (not from same company or licensed). ======================================================== 4) Some of the listed implementations were not "functionally equivalent or interchangeable components" as "interoperable" is defined in RFC 2026 section 4.1.2; a separate software module that only writes "Profile L" not functionally equivalent or interchangeable with a "Internet Fax device". An implementation of a "File Format for Internet Fax" should be part of an implementation of "Internet Fax". An "Authentication Method for LDAP" should be implemented in the context of LDAP; an implementation that doesn't demonstrate the use of the method for LDAP but for some other protocol wouldn't qualify. It should not be sufficient that it is "easy to believe" that an implementation "is easy to create". There are many reasons why organizations might not bother creating independent implementations: insufficient interest in getting the document to progress, inability to get clarification of licensing of IPR, etc. Those implementations that do not actually participate in the overall protocol should not be considered "implementations". It's been the case that the IESG has considered independent implementation of features don't have to all be in the same implementation, but this has been applied to implementations of the actual standard, and not to individual components taken out of context. *** Only consider those implementations that actually accomplish "Internet Fax" (as defined by RFC 2542), and not just "file format writers". ========================================================= 5) IPR licensing: There are statements of IPR. Some technology involved in implementing the proposed document has been licensed in the past: http://www.microsoft.com/presspass/press/2000/Oct00/ScanSoftPR.asp 2nd para. and http://www.businesssolutionsmag.com/Articles/2001_02/010215.htm (search for TIFF-FX). The fact that the technology has been licensed, that the owner of the technology reports the licensing as a significant financial event, should lead one to believe that implementors of the format should state either that they have an independent exercise of the license agreement or that no licensing is required. In addition, there is 3rd party IPR which have been reported http://www1.ietf.org/mail-archive/working-groups/ipr-wg/current/msg00104 .html and http://www.cl.cam.ac.uk/~mgk25/jbigkit/patents.html for which there is no clarification about whether licensing is or isn't required. *** Only consider those implementations for which an 'independent exercise of the license agreement' is clear. ============================================================= 6) There are still many features for which there are not multiple independent interoperable implementations. Even disregarding (1)-(5) above: * There are no implementations writers or readers for 12 bit-per-sample profile C * There is only one reader for profile L with 1-bit RGB, 1-bit CMY, 1-bit CMYK. * It's not clear whether there are any implementations of optional TIFF fields (section 2.2.4) with profile F and S * There is only one independent writer for profile M Without access to the implementations, sample interoperable test files, or a clear list of which implementations are interoperable, independent, and separate exercise of licensing, it's impossible to produce a complete list of features that are NOT implemented. *** To move forward: a) Find someone without a beneficial relationship to the IPR holder(s) to write an interoperability report. b) determine independent implementations which meet the requirements for independent exercise of any licensing requirements the implementors deem necessary c) ask writers to test writing files and sending them (using Internet Fax) to at least two independent readers, and to validate interoperability (that the messages were received and interpreted correctly) d) obtain a complete list of features tested from each writer. e) remove all features for which there are not at least two writers, each of which interoperated with two readers. Include all "optional" features in the list of features to be removed if they are not implemented. Larry -- http://larry.masinter.net