attachment

<HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-15"> <META content="MSHTML 6.00.2900.2912" name=GENERATOR></HEAD> <BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>We also rely upon the severity suffixes and make use them in our iPrint print system as required by RFC 2911.  So deprecating them would be bad for us and our installed base.  What is wrong with just using the report suffix on these values?</DIV> <DIV> </DIV> <DIV>We currently don't use the printer-state-message attribute, but it was meant for human readable strings.  We would not be inclined to use a collection mechanism for the prtAlert objects.  There must be a better way to do this.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>McDonald, Ira wrote:<BR>> Hi folks,                                          Monday (17 July 2006)<BR>> <BR>> I've just posted the first draft of the PWG IPP Printer State Reasons<BR>> Extensions specification on the PWG FTP server at:<BR>> <BR>>     <A href="ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm">ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm</A> <BR>> <BR>> This draft is technically complete (to the best of my ability) except<BR>> for the summary conformance sections (individual sections already have<BR>> detailed conformance requirements).<BR>> <BR>> For immediate review, comment on the IPP WG mailing list (<A href="mailto:ipp@pwg.org">ipp@pwg.org</A>),<BR>> and discussion at an IPP WG Telecon as soon as possible.</DIV> <DIV> </DIV> <DIV>WRT section 5.1.1, CUPS implements the severity suffixes as required<BR>by RFC 2911.  I don't think we can just do away with them, but<BR>defining a mapping from keyword-suffix to keyword would have the<BR>equivalent effect without requiring an update of RFC 2911...  Also,<BR>I know I get "media-tray-empty-error" and other messages from HP<BR>printers via IPP, so we're not the only company implementing it...</DIV> <DIV> </DIV> <DIV>Also, overloading printer-state-message with non-localized alert<BR>object data is, IMHO, the wrong approach.  Define a printer-alert<BR>1setOf collection that contains all of the prtAlert* objects.  CUPS<BR>uses printer-state-message to hold the human-readable state message<BR>(as defined by RFC 2911), and it would be impossible for CUPS to<BR>conform to this spec if you use printer-state-message for this<BR>purpose.</DIV> <DIV> </DIV> <DIV>-- <BR>______________________________________________________________________<BR>Michael Sweet, Easy Software Products           mike at easysw dot com<BR>Internet Printing and Publishing Software        <A href="http://www.easysw.com">http://www.easysw.com</A></DIV> <DIV> </DIV> <DIV> </DIV>Ted Tronson<BR>Sr. Software Engineer<BR>iPrint Engineering<BR>ttronson@novell.com<BR>801-861-3338</BODY></HTML>