IPP Mail Archive: Re: IPP> Posted draft IPP Printer State Reasons Extensions (17 July 2006)

Re: IPP> Posted draft IPP Printer State Reasons Extensions (17 July 2006)

From: Ted Tronson (TTRONSON@novell.com)
Date: Tue Jul 18 2006 - 15:24:12 EDT

  • Next message: Bergman, Ron: "IPP> Printer State Reasons Teleconference, July 20, 2006, 11:00 AM EDT"

    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?
    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.
    McDonald, Ira wrote:
    > Hi folks, Monday (17 July
    > I've just posted the first draft of the PWG IPP Printer State
    > Extensions specification on the PWG FTP server at:
    > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm
    > This draft is technically complete (to the best of my ability)
    > for the summary conformance sections (individual sections already
    > detailed conformance requirements).
    > For immediate review, comment on the IPP WG mailing list
    > and discussion at an IPP WG Telecon as soon as possible.
    WRT section 5.1.1, CUPS implements the severity suffixes as required
    by RFC 2911. I don't think we can just do away with them, but
    defining a mapping from keyword-suffix to keyword would have the
    equivalent effect without requiring an update of RFC 2911... Also,
    I know I get "media-tray-empty-error" and other messages from HP
    printers via IPP, so we're not the only company implementing it...
    Also, overloading printer-state-message with non-localized alert
    object data is, IMHO, the wrong approach. Define a printer-alert
    1setOf collection that contains all of the prtAlert* objects. CUPS
    uses printer-state-message to hold the human-readable state message
    (as defined by RFC 2911), and it would be impossible for CUPS to
    conform to this spec if you use printer-state-message for this

    Michael Sweet, Easy Software Products           mike at easysw dot com
    Internet Printing and Publishing Software        http://www.easysw.com

    Ted Tronson Sr. Software Engineer iPrint Engineering ttronson@novell.com 801-861-3338

    This archive was generated by hypermail 2.1.4 : Tue Jul 18 2006 - 15:24:28 EDT