Fwd: IFX> FW: notes from the ietf FAX wg meeting at IETF 51

Greetings all....

Claudio and Tamura-san,

I concur with Lloyd that you and Graham did an excellent job of 
capturing the meeting notes in their origional form.

However, I must disagree with Lloyd's proposed revisions on numerous 
points.  I do not think it is in the best interests of the working 
group for us to re-hash the discussion under the guise of accurately 
capturing the meeting notes.  I recommend we go with Graham's and 
Claudio's original notes.  If this can not be supported, then I will 
need to offer comments and counter proposals to almost all of Lloyd's 
comments.  I do not feel his comments capture the neutral spirit of 
Graham's and Claudio's comments.

Please let me know how you wish to proceed on this.

Scott

(Also, please note that I have chosen to include the IEEE IPP group 
in the discussion prior to the Internet Fax committee publishing the 
minutes because Lloyd included them in the discussion.)



>From: "McIntyre, Lloyd" <[email protected]>
>To: "'IETF - fax WG dl'" <[email protected]>,
>    "'IETF - John Klensin (IAB Chair)'" <[email protected]>
>Cc: "'PWG - IPPFax DL'" <[email protected]>
>Subject: IFX> FW: notes from the ietf FAX wg meeting at IETF 51
>Date: Tue, 14 Aug 2001 16:14:51 -0700
>Importance: high
>X-Priority: 1
>X-Security: MIME headers sanitized on smtp-relay-2
>	See http://www.impsec.org/email-tools/procmail-security.html
>	for details. $Revision: 1.129 $Date: 2001-04-14 20:20:43-07
>Sender: [email protected]
>
>Claudio and Tamura-san
>My thanks to you and Graham for the excellent job in capturing the meeting
>proceedings and result.
>Please allow me to suggest a few clarifications below.
>
>Regards,
>Lloyd
>
>>  -----Original Message-----
>>  From: Claudio Allocchio [mailto:[email protected]]
>>  Sent: Thursday, August 09, 2001 9:26 AM
>>  To: [email protected]
>>  Cc: [email protected]
>>  Subject: notes from the ietf FAX wg meeting at IETF 51
>>
>>
>>
>---snip---
>>
>>   2.2 TIFF-FX
>>        draft-ietf-fax-tiff-fx-09.txt
>>        draft-ietf-fax-tiff-regbis-02.txt
>>
>---snip---
>>  The question now is: can we meet all these constrains? Is TIFF the right
>>  choice to accomplish them?
>The second sentence was not an issued raised by the IAB chair, in fact one
>individual raised this issue. Please consider deleting the second sentence
>or revising to read as follows:
>"The question now is: can we meet all these constrains? One individual asked
>whether TIFF was the right choice to accomplish them?"
>
>>  Basic TIFF does not support colors, and different resolutions, but is it
>>  compliant with the existing TIFF readers, and e-mail User Agents (MUAs).
>Reverse the order of "is it" to read "it is".
>
>>  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.
>Given that accommodation of ITU-T color and higher quality encodings was a
>component of the WG charter, this sentence may be reworded to convey less of
>an impression that it was an afterthought. Please consider the following
>revision:
>"Basic TIFF was not enough to accommodate color and higher quality ITU-T
>encodings, consequently extensions were needed."
>
>>                                                 These extensions were
>>  specified into TIFF-FX, and ITU-T decided to adopt and reference it.
>For completeness, please append "for their Internet Fax standard" to this
>sentence. It should now read:
>"These extensions were specified into TIFF-FX, and ITU-T decided to adopt
>and reference it for their Internet Fax standard."
>
>>  However TIFF-FX is already beyond Basic TIFF.
>>
>>  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.
>The statement of no interoperability problems with all the de facto
>extensions is inaccurate, since some deployed viewers will not read all the
>extensions. Please reword the second sentence similar to the following:
>"All the de facto extensions are currently used in MIME type "image/tiff"
>and some have no interoperability problems."
>
>>           However the extensions intriduced into TIFF-FX are a superset,
>>  and thus only some Ifax devices can correctly handle them.
>A correction and softening is warranted, given that it is not only Ifax
>devices that are capable of reading TIFF-FX files and the limited
>readability is not an unusual issue with new extensions in general. Consider
>the following:
>"The extensions introduced into TIFF-FX are a superset, which are viewable
>by a limited set of Ifax devices and software applications."
>
>It is important to convey the fact that the WG took deliberate steps to
>avoid incompatibility resulting from addition of new encodings by redefining
>the image/tiff MIME type (i.e. RFC2302) to include an application parameter.
>The results were not quite satisfactory, however, the issue was addressed
>and steps were taken. Accordingly, please consider insertion of the
>following paragraph:
>
>"To avoid interoperability issues arising from introduction of the extended
>color and high quality super set, the image/tiff MIME type was revised to
>add application parameters. The image/tiff application parameters serve to
>alert viewers to the presence of the TIFF-FX superset. Recent disclosures,
>however, indicate that many readers do not pay attention to MIME application
>parameters. It is the inconsistent usage of application parameters that is
>at the heart of TIFF-FX incompatibility with image/tiff viewers."
>
>>
>>  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)
>Clarify as follows:
>  "- Whether the MIME sub-type should be image/tiff or image/tifffx (or
>equivalent)"
>
>>   - hether the interoperability profile is right given these issues
>Please clarify, I do not understand what is being said?
>
>>   - and any other similar tradeoffs that might have been made
>>  without full
>>     evaluation.
>
>---snip---
>The paragraph below appears to be lacking context of what the IPR issue is,
>please prefix it with the following:
>"In December 2000 Adobe provided notification of its believe that the
>TIFF-FX specification exceeds the scope of its 1997 IETF license grant for
>TIFF-FX development <http://www.ietf.org/ietf/IPR/Adobe-TIFF>. Inclusion of
>the extended encodings within TIFF-FX was identified as reason for the claim
>of exceeded scope. The validity of this claim has been questioned, given
>that the grant contains no constraint on extensions within TIFF-FX. The fact
>that Abode co-authored both the TIFF-FX and the revised MIME image/tiff
>specifications makes it more difficult to understand the claim.
>Additionally, it may be said that the claim is somewhat late, given that
>TIFF-FX was issued as Proposed Standard in December 1998." 
>
>>  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.
>In light of the attached license statement, which clearly states that Xerox
>grants MRC license use within TIFF-FX and without any application space
>restrictions, please correct the 2nd sentence by inserting "MRC" between
>"the encoding" and changing "not just fax and Xerox (or maybe IETF) apply"
>to "not just TIFF-FX, and apply". The sentence should now read:
>"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 MRC encoding
>techniques for all uses of TIFF, not just TIFF-FX, and apply formally to
>Adobe to have the features and tags included."
>
>>
>>  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.
>>
>---snip---
>>
>>  The discussion of the problem and the WG conclusions.
>>  -------------------------------------------------
>>
>Consider constraining this section to only WG conclusions and procedures to
>be followed, removing the detailed he said/she said commentary. This
>translates to deleting all items prior to the paragraph that starts "Claudio
>A. summarised the conclusions to be reported into the minues,".
>The revised title might read as follows:
>"WG meeting conclusions and procedures to be followed"
>  ----------------------------------------------------
>
>This would be followed by a restructured, consolidated and clarified body as
>below.
>
>A summary of the meeting's rough consensus, along with the procedures to be
>followed, is provided below with "rc" identifying rough consensus items and
>"p" identifying procedure items:
>rc - Interoperability with email was considered the most important choice
>between email or fax interoperability.
>
>p  - Level of interoperability should be established by conducting a test of
>RFC2301 (more appropriately draft-ietf-fax-tiff-fx-09.txt) using existing
>mail user agents (MUAs) and tiff capable software applications such as
>PhotoShop and other tiff viewers. The software viewer test may be
>accommodated by saving the RFC2301 image/tiff stream to a file with .tif or
>other appropriate tiff extension.
>
>p  - An interoperability report should be generated and used to document the
>set of interoperable TIFF-FX encoding parameters, such as coder, resolution,
>paper size and color components.
>
>p  - One of the four options below should be selected for the
>specification(s) that will move forward through the standards tack process:
>      1. Full TIFF-FX: - retain the currently defined TIFF-FX draft without
>modification of the encoding set and define both a new MIME type (e.g.
>image/tifffx or image/tifx) and a new file extension (e.g. .tifx or .tfx).
>The new MIME type and extension circumvents interoperability issues with
>TIFF 6.0.
>         Advantages: i) Retention of color and high quality encodings, ii) no
>disruption of IFax products under deployment, and iii) a single integrated
>specification.
>         Disadvantages: i) Licensing issues to be resolved, and ii)
>unpredictable approval schedule due to license resolution.
>
>      2. Interoperable TIFF-FX: - use the new interoperability document to
>generate a TIFF-FX subset that is image/tiff interoperable, retaining the
>current image/tiff MIME type.
>         Advantages: i) No licensing issues, and ii) predictable approval
>schedule.
>         Disadvantages: i) Loss of color and high quality encodings, ii)
>disruption of IFax products under deployment.
>
>      3. Interoperable and non-Interoperable TIFF-FX: - use the new
>interoperability document to generate two subsets, a) Interoperable TIFF-FX,
>as per #2, and b) non-Interoperable TIFF-FX, which is composed of the
>remaining encoding subset. As with Full TIFF-FX, define both a new MIME type
>and a new file extension for the non-Interoperable TIFF-FX.
>         Advantages: i) Base-level black-and-white has no licensing issues,
>ii) predictable base-level approval schedule iii) retention of color and
>high quality encodings, iv) minimal disruption of IFax products under
>deployment.
>         Disadvantages: i) Licensing issues to be resolved for color & high
>quality, ii) unpredictable color & high quality approval schedule, iii) two
>disjoined specifications.
>
>      4. Interoperable and Full TIFF-FX: - this is a combination of options 1
>and 2.
>         Advantages: i) Base-level black-and-white has no licensing issues,
>ii) predictable base-level approval schedule iii) retention of color and
>high quality encodings, iv) no disruption of IFax products under deployment,
>and v) base-level specification may be phased out as viewers advance.
>         Disadvantages: i) Licensing issues to be resolved for color & high
>quality, ii) unpredictable color & high quality approval schedule.
>
>rc - Option 2, Interoperable TIFF-FX, was selected to move forward at this
>time.
>
>p  - Justification of the selection must be documented and communicated to
>the ITU.
>
>p  - Both the resulting specification and the Implementors Guide should
>contain explanation of the interoperability issues and countermeasures.
>
>p  - The resulting specification(s) may be resubmitted to the IESG for Draft
>Standard consideration if there are draft-ietf-fax-tiff-fx-09.txt
>function/feature deletions or no changes. This means that Full TIFF-FX, with
>no changes, and both the Interoperable TIFF-FX and non-Interoperable TIFF-FX
>subsets, without any additions, may be resubmitted to the IESG for Draft
>Standard consideration. Any required specification additions shall result in
>recycle as Proposed Standard.
>
>p  - Resolution of IPR issues associated with Full TIFF-FX and
>non-Interoperable TIFF-FX needs to progress in parallel with the above
>activates and the ITU should be kept informed.
>
>---snip---
>
>>  5.5 TIFF-FX extension issue
>>       draft-ietf-fax-tiff-fx-Extension-1-02.txt
>>       (drtyre-tiff-fx-extension1-02.txt)
>>      darft-mcintyre-feature-schema-extension1-00.txt
>
>>  After remembering that all the issues in these documents are related to
>>  the previous discussion about TIFF and TIFF-FX issue, and that IPR
>>problems should be clearly investigated also for these proposed
>>  extensions, the presentation (see slies) described the further JBIG2
>>  extensions.
>
>>  Larry M. asked how many in the room read the draft:  One person. As such
>>  the question was raised if we should continue the work, if there is
>>  interest in doing it or not, provided that at a certain point the
>>  specification will have to undego interoperability tests, and the lack of
>>  interest could lead to a lack of implementations.  There was at the moment
>>  no conclusion to ths question, as we need to check first the status of the
>>  TIFF issue evolution.
>The second paragraph should be depersonalized and clarified to note that
>there was confusion as to which specification was being addressed by the
>question of number of reviewers. The question was asked toward the end of
>the Schema, not the TIFF-FX Extension presentation. The respondent was a
>reviewer of the Schema extension, which is a very new draft with little time
>for review. Revise as follows:
>"Toward the end of the Schema extension presentation a member ask how many
>had read the draft, there was no clarifications as which draft was being
>referenced. There was acknowledgement from on member who had reviewed the
>Schema drat. The requestor then asked whether the work should be continued,
>without much response. No conclusions could be drawn."
>
>

>From http://www.ietf.org/ietf/IPR/XEROX-RFC2301

The following was conveyed via email on September 9, 1999 by Clarke Wixon
Patent Attorney, Xerox


Mr. Stephen Coya
Executive Director
Internet Engineering Task Force
c/o Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, Virginia 20191-5434

Re:     IETF RFC 2301 (TIFF-FX) IPR Statement

Dear Mr. Coya:

Xerox is currently aware of two U.S. Patents which may relate to implementations of
the IETF RFC 2301 (TIFF-FX) standard. U.S. Patent No. Re35,657 is owned by Xerox
Corporation. U.S. Patent No. 5,778,092 is owned by ScanSoft, Inc., but Xerox has
rights to sublicense the technology for these purposes.

To the extent that Xerox's existing intellectual property rights under the above two
patents may cover the implementation of a product compliant with the TIFF-FX
standard, Xerox agrees to provide, upon request, a royalty-free, world-wide,
non-exclusive license under certain claims of the above two patents (not including
the segmentation technology described in the specification and set forth in claims
2-4, 7, 8, or 12-14 of U.S. Patent No. 5,778,092, which is not considered to be an
essential technology for the implementation of the TIFF-FX standard) for the purpose
of making, having made, using, selling, offering for sale, or otherwise disposing of
a product implementing the TIFF-FX standard, and only to the limited extent
necessary for the product to comply with the TIFF-FX standard.

Any license granted by Xerox under this Statement shall be subject to the following
condition: any party receiving such a grant from Xerox must agree to grant Xerox
Corporation, Xerox Ltd., Fuji Xerox Co. Ltd., Modi Xerox Limited and any
corporation, firm, partnership, individual, or other form of business organization
at least forty percent (40%) owned or controlled, directly or indirectly, by Xerox
Corporation, Xerox Ltd., Fuji Xerox Ltd. or Modi Xerox Limited, upon request, a
license under that party's patents relating to the TIFF-FX standard, on terms and
conditions no less favorable than those granted by Xerox to that party.

Parties interested in obtaining a license may contact:

Xerox Intellectual Property Operations (XIPO)
ATTN: MRC License Inquiries
100 Willowbrook Office Park, Bldg. 832-01A
Fairport, New York 14450  U.S.A.

Very truly yours,

/s/

Dr. Jan Jaferian
Vice President

c:      James Rafferty (IFax WG Chair) <[email protected]>
        Keith Moore (IETF Area Director) <[email protected]>
        Patrik Faltstrom (IETF Area Director) <[email protected]>


Clarke Wixon
Patent Attorney
Xerox Corporation