attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE></TITLE> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD> <BODY> Dear IPP-Fax group: The following is in response to my action item from 4th IPP Fax meeting in Maui: How should we reconcile the TIFF-FX specification's notion of a "profile" with  Conneg? The IPP-Fax group has decided to use TIFF-FX, formally described in "draft-ietf-fax-tiff-fx-main.txt" [TIFF-FX], as the data format for IPP-Fax (UIF). [TIFF-FX], however, is too restrictive to satisfy IPP-Fax requirments. [TIFF-FX] describes a set of six "profiles" which impose limitations on the range of image attributes. This limiting set of profiles is more suited for Internet-Fax, where synchronous determination of receiver capabilities is not possible. With IPP-Fax, then, the usefulness of a "profile" is diminished. Should we do away with the idea of a "profile"? It seems to me that Conneg, as it is described in [RFC 2879], (or equivalent) is all that is needed to negotiate an image to the liking of a receiver. All parameters that distinguish one TIFF-FX profile from another can be separately negotiated with Conneg (or equivalent) to the point where image characteristics are more finely tuned than they would be with a simple "profile" label. For example, with Conneg, a receiver can specify that it can accept binary-color JBIG-encoded image data but *only* with the limitiations of the placement of Image File Descriptors (IFDs) indicated in section 4.4.6 of [TIFF-FX], and only if JBIG stripe size is fixed at 128 lines per stripe. But this strength also has an inherant weakness. Namely, Conneg feature tags may lead to a condition where an IPP-Fax sender and receiver can find no common ground with one another. So, perhaps the best solution would be to have the UIF data specification  maintain the notion of  a 'profile', and mandate a base set of image attributes for each profile that are slightly different than those found in [TIFF-FX]. Like the TIFF-FX profile, the envisioned UIF profiles would be distinguished from one another primarily on the coding method used (e.g., MH, MMR, JPEG, etc.). The minimal requirements for each UIF profile should also take into account existing / proposed UIF requirements that clash with [TIFF-FX], which include the following:         -- UIF uses ImageWidth tag to represent actual imaging area with no implied enumeration. [TIFF-FX] uses it as an indication of paper size; therefore, only a fixed set of allowed values are possible in [TIFF-FX].         -- (Proposed from earlier meeting) UIF treats English system X- and YResolution values and those derived from the metric system as unique. [TIFF-FX] treats certain pairs of English and metric-derived resolutions as the same (e.g., ResolutionUnit=inches and XResolution=200dpi same as ResolutionUnit=cm and XResolution=80cm in [TIFF-FX]) So I leave it to the IPP-Fax group. Would it be worthwhile for me to make a table of base requirements for each UIF profile for discussion at the meeting in Tampa?  I know the original idea was to stay as close to [TIFF-FX] as possible, but there are already a few key differences in UIF requirements that make strict adherance to [TIFF-FX] impossible. References: [TIFF-FX]  - draft-ietf-fax-tiff-fx-09.txt - File Format for Internet Fax .(previously called RFC2301).  November 17, 2000. [RFC 2879] - Content Schema for Internet Fax (V2). August, 2000. Regards, John Pulera <A href="mailto:jpulera@minolta-mil.com">jpulera@minolta-mil.com</A> Minolta Systems Laboratory </BODY></HTML>