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.50.4522.1800" name=GENERATOR></HEAD> <BODY> <DIV>On the second issue, I believe the original issue from the minutes was whether to use the IPP/1.1 terminology for IPPFAX Sender and IPPFAX Receiver, which would be IPPFAX Client and IPPFAX Printer, not IPPFAX Host.  To me the term Host is much too vague.  To me a Host could be a sender or a receiver.</DIV> <DIV> </DIV> <DIV>So I'm quite opposed to using the term "Host".  Whether to continue using the IPPFAX terms Sender and Receiver or go back to the IPP/1.1 terms of Client and Printer is harder to decide.  If we go back to the IPP Client and Printer terms we would make it clear that the term Printer means the software entity that accepts requests and returns responses, as in IPP, and need not actually have any hardware associated at all.  The advantage of the term Receiver, is that no hardware is suggested by the name.</DIV> <DIV> </DIV> <DIV>However, the problem with using the term "receiver" is that it affects the names of some of the attributes ("receiver" vs. "printer").  Also we are stuck with the IPP/1.1 terminology of Printer Description attributes and the 'printer-description' attribute group name used as a keyword in the Get-Printer-Attributes request.</DIV> <DIV> </DIV> <DIV>The attribute names affected are:</DIV> <DIV> </DIV> <DIV> <A href="outbind://6/#_Toc515389244">5.1            ippfax-sending-user-identity (text(MAX)) operation/Job Description attribute  9</A> <A href="outbind://6/#_Toc515389245">5.2            ippfax-receiving-user-identity (text(MAX)) operation/Job Description attribute  9</A> <A href="outbind://6/#_Toc515389246">5.3            ippfax-sender-identity (name(255)) operation/Job Description attribute  10</A> <A href="outbind://6/#_Toc515389247">5.4            ippfax-receiver-identity (name(255)) Printer Description attribute  10</A>   We should still keep the terms Sending User and Receiving User, but we could change the terms Sender to Client and Receiver to Printer. Then the attributes would be named:   <A href="outbind://6/#_Toc515389244">5.1            ippfax-sending-user-identity (text(MAX)) operation/Job Description attribute  9</A> <A href="outbind://6/#_Toc515389245">5.2            ippfax-receiving-user-identity (text(MAX)) operation/Job Description attribute  9</A> <A href="outbind://6/#_Toc515389246">5.3            ippfax-client-identity (name(255)) operation/Job Description attribute  10</A> <A href="outbind://6/#_Toc515389247">5.4            ippfax-printer-identity (name(255)) Printer Description attribute  10</A>   Comments? Tom</DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: John Pulera [mailto:jpulera@minolta-mil.com] Sent: Thursday, June 07, 2001 09:45 To: IPP-Fax Group Subject: IFX> some UIF issues...thoughts anyone? </DIV> <DIV>While revising the UIF spec, some issues have surfaced and it would be great if we can generate some discussion on them:</DIV> <DIV> </DIV> <DIV>1) The MIME type for UIF data.         From the IPPFAX teleconferences held on May 30 & June 6, there was consensus to use "image/tiff; application=faxbw" and "image/tiff; application=faxcolor". The primary argument for using these was that it is the same MIME type used for Internet Fax, and so there would be less of a conformance issue with an IPPFAX device serving as a gateway for Internet Fax documents.</DIV> <DIV>        However...If we are going to make UIF a protocol-independent data format (which was also agreed at the May 30 telecon), I do not think think we should directly associate it with Internet Fax. Perhaps "image/tiff; application=uif" would be a better compromise in that UIF would be made independent of Internet Fax while existing TIFF readers can still do something with the UIF data.</DIV> <DIV>        In addition, is it valid to use the same MIME type as Internet Fax if the data requirements for UIF and TIFF-FX are not identical?  (TIFF-FX is more strict with resolutions and allowed image widths)</DIV> <DIV> </DIV> <DIV>2) The use of the terms "Client" to mean the "Sender" and "Host" to mean the "Receiver".</DIV> <DIV>    Is "Client" interchangeable with "Sender" and "Host" with "Receiver"? Should we be using the more generic terms "Client" and "Host" instead of "Sender" and "Receiver" in the UIF spec since the UIF spec is NOT protocol-specific?</DIV> <DIV> </DIV> <DIV>Does anyone have any thoughts on these issues?</DIV> <DIV> </DIV> <DIV>Thanks,</DIV> <DIV> </DIV> <DIV>John</DIV></BLOCKQUOTE></BODY></HTML>