attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD> <BODY> <DIV>John,</DIV> <DIV> </DIV> <DIV>A great piece of work!  This really advances IPP FAX, simplifies content negotiation, and relates it to Internet FAX and CONNEG without requiring either the Sender or the Receiver to support conneg, if they don't want to.  In addition, it also allows the Sender and Receiver to use CONNEG if they want to.  </DIV> <DIV> </DIV> <DIV>I have a few comments which I have down loaded to:</DIV> <DIV> </DIV> <DIV><A href="ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc-th-comments.pdf">ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc-th-comments.pdf</A></DIV> <DIV><A href="ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc-th-comments.doc">ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc-th-comments.doc</A></DIV> <DIV> </DIV> <DIV> I added line numbers and page numbers.  I've made some revisions to the document after talking with John using revisions marks.</DIV> <DIV> </DIV> <DIV>I think this definitely should go into the UIF spec (but see also issue 02).</DIV> <DIV> </DIV> <DIV>Here are my issues (also embedded in the document):</DIV> ISSUE 01:  Or is it so easy for a Receiver to support the “uif-conneg” Printer attribute (its just a canned constant string) that the UIF spec should REQUIRE an IPP FAX Receiver to support the “uif-conneg” Printer attribute? ISSUE 02 : Should the UIF spec be made independent of IPP FAX by moving the discussion about an IPP attributes to the IFX spec?  Then UIF could be used with any protocol.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p> ISSUE 03:  The last sentence is a requirement for an IPP FAX Receiver to support CONNEG, if it has a paper size that is not one of the standard  (presumably the Internet FAX small set of standard sizes) paper sizes.  However, if IPP FAX were to use the Media Size Self Describing Name values for the “media”, “media-supported”, and “media-ready” attributes from the PWG Media Standardized Names, then the dimensions would be explicitly included for every media size, even custom sizes.  Should IPP FAX:<o:p></o:p> (1) REQUIRE exclusive support of, <o:p></o:p> (2) REQUIRE support plus current IPP/1.1 media size keywords, <o:p></o:p> (3) RECOMMEND, or <o:p></o:p> (4) list as an OPTION, <o:p></o:p> for an IPP FAX Sender and an IPP FAX Receiver to use the Media Size Self Describing Name keyword values for the “media”, “media-supported”, and “media-ready” attributes from the PWG Media Standardized Names?  Then this would be one more opportunity for a Receiver and a Sender to avoid having to use CONNEG, because of an unrecognized media size.<o:p></o:p>  <o:p></o:p> ISSUE 04:  Even if we don’t use the PWG Media Standardized Names, should IPP FAX:<o:p></o:p> (1) REQUIRE IPP media name keywords, e.g., ‘iso-a4-white’, ‘na-letter-white’<o:p></o:p> (2) REQUIRE IPP media size keywords, e.g., ‘iso-a4’, ‘na-letter’<o:p></o:p> (3) REQUIRE support of both<o:p></o:p> (4) REQUIRE support of (1), and RECOMMEND support of (2)<o:p></o:p> (5) REQUIRE support of (2), and RECOMMEND support of (1)<o:p></o:p> ISSUE 05:  Should IPP FAX REQUIRE support of 300dpi as well for Profile S and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 06:  Should IPP FAX REQUIRE support of 200dpi as well for Profile S and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 07:  Should IPP FAX REQUIRE support of 300dpi as well for Profile F and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 08:  Should IPP FAX REQUIRE support of 200dpi as well for Profile F and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 09:  Should IPP FAX REQUIRE support of 300dpi as well for Profile J and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 10:  Should IPP FAX REQUIRE support of 200dpi as well for Profile J and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p> ISSUE 11:  Should IPP FAX REQUIRE support of 200dpi as well for Profile C and indicate that the Sender MUST send at 300dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p> ISSUE 12:  Should IPP FAX REQUIRE support of 200dpi as well for Profile L and indicate that the Sender MUST send at 300dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p> ISSUE 13:  Should IPP FAX REQUIRE support of 300dpi as well for Profile M with the bi-level mask layer and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 14:  Should IPP FAX REQUIRE support of 200dpi as well for Profile M with the bi-level mask layer and indicate that the Sender MUST send at 600dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p>  <o:p></o:p> ISSUE 15:  Should IPP FAX REQUIRE support of 200dpi as well for Profile M with the foreground and background layers and indicate that the Sender MUST send at 300dpi or higher, unless the Sending User has explicitly indicated that a degraded mode is satisfactory?<o:p></o:p> <o:p>Thanks,</o:p> <o:p>Tom</o:p> <BLOCKQUOTE style="MARGIN-RIGHT: 0px"> <DIV align=left class=OutlookMessageHeader dir=ltr>-----Original Message----- From: John Pulera [mailto:jpulera@minolta-mil.com] Sent: Wednesday, May 16, 2001 19:36 To: IPP-Fax Group Subject: IFX> default conneg & more detailed UIF profile summary </DIV> <DIV> <DIV>Per my action item from the Portland meeting, I've put together a document that</DIV> <DIV>    1) Proposes a simplified means of content negotiation whereby the transfer of Conneg would be optional</DIV> <DIV>    2) Provides a detailed summary of UIF Profile requirements and how they differ from TIFF-FX profiles</DIV> <DIV> </DIV> <DIV>I propose that we add the contents of this document to the UIF specification.</DIV> <DIV> </DIV> <DIV>Please take a moment to review:</DIV> <DIV> </DIV> <DIV><A href="ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc.doc">ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc.doc</A></DIV> <DIV><A href="ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc.pdf">ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc.pdf</A></DIV> <DIV> </DIV> <DIV> </DIV> <DIV>John Pulera</DIV> <DIV> </DIV> <DIV> <DIV>-----------------------------------------</DIV> <DIV>John Pulera</DIV> <DIV>Minolta Systems Laboratory</DIV> <DIV><A href="mailto:jpulera@minolta-mil.com">jpulera@minolta-mil.com</A></DIV> <DIV>(949)737-4520 x348</DIV> <DIV> </DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>