Subject: [IPP] Errata: PWG 5100.9: IPP Printer State Extensions v1.0

From: Michael Sweet <[email-masked]>
Date: Mon, 17 Mar 2014 14:07:36 -0400

All,

It was recently pointed out to me that PWG 5100.9 defines several "printer-state-reasons" keywords with the suffix "-error":

    subunit-recoverable-storage-error
    subunit-unrecoverable-storage-error
    bander-recoverable-storage-error
    bander-unrecoverable-storage-error
    binder-recoverable-storage-error
    binder-unrecoverable-storage-error
    die-cutter-recoverable-storage-error
    die-cutter-unrecoverable-storage-error
    folder-recoverable-storage-error
    folder-unrecoverable-storage-error
    imprinter-recoverable-storage-error
    imprinter-unrecoverable-storage-error
    inserter-recoverable-storage-error
    inserter-unrecoverable-storage-error
    make-envelope-recoverable-storage-error
    make-envelope-unrecoverable-storage-error
    perforater-recoverable-storage-error
    perforater-unrecoverable-storage-error
    puncher-recoverable-storage-error
    puncher-unrecoverable-storage-error
    separation-cutter-recoverable-storage-error
    separation-cutter-unrecoverable-storage-error
    sheet-rotator-recoverable-storage-error
    sheet-rotator-unrecoverable-storage-error
    slitter-recoverable-storage-error
    slitter-unrecoverable-storage-error
    stacker-recoverable-storage-error
    stacker-unrecoverable-storage-error
    stapler-recoverable-storage-error
    stapler-unrecoverable-storage-error
    stitcher-recoverable-storage-error
    stitcher-unrecoverable-storage-error
    trimmer-recoverable-storage-error
    trimmer-unrecoverable-storage-error
    wrapper-recoverable-storage-error
    wrapper-unrecoverable-storage-error

However, RFC 2911 reserves this suffix for indicating the severity of the reason:

   4.4.12 printer-state-reasons (1setOf type2 keyword)

   This REQUIRED Printer attribute supplies additional detail about the
   device's state.  Some of the these value definitions indicate
   conformance requirements; the rest are OPTIONAL.

   Each keyword value MAY have a suffix to indicate its level of
   severity.  The three levels are: report (least severe), warning, and
   error (most severe).

      - '-report':  This suffix indicates that the reason is a "report".
        An implementation may choose to omit some or all reports. Some
        reports specify finer granularity about the printer state;
        others serve as a precursor to a warning. A report MUST contain
        nothing that could affect the printed output.
      - '-warning': This suffix indicates that the reason is a
        "warning".  An implementation may choose to omit some or all
        warnings. Warnings serve as a precursor to an error. A warning
        MUST contain nothing that prevents a job from completing, though
        in some cases the output may be of lower quality.
      - '-error': This suffix indicates that the reason is an "error".
        An implementation MUST include all errors. If this attribute
        contains one or more errors, printer MUST be in the stopped
        state.

   If the implementation does not add any one of the three suffixes, all
   parties MUST assume that the reason is an "error".

Since an IPP Printer MAY report any of the above keywords when the Printer is not in the stopped state, I propose we add an informative note to table 5-2 saying something like the following:

    Note 1: Section 4.4.12 [RFC2911] requires that the Printer is in the
    stopped state when reporting "printer-state-reasons" values ending
    with "-error". Printers MUST append a suffix of "-report" or
    "warning" to this keyword when the Printer is not in the stopped
    state.

I'm not sure if we want to clarify that the "job-state-reasons" attribute only contains the registered values without added suffixes.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Mon, 17 Mar 2014 16:53:10 -0400

Hi Mike,

See my related reply about PWG 5107.3.

I suggest changing the IPP printer-state-reasons from "-error" to "-fault".

WARNING - all of the PWG 5100.9 extensions *were* registered in the
IANA Printer MIB and SMIv2 rules prevent our changing the names of
already assigned enumeration values, so the possible fix is different
from my suggested one for PWG 5107.3.

WARNING - vendors (printer and management systems) who have used
the previously assigned PWG 5107.3 or PWG 5100.9 names and values
in the Printer MIB will have breakage if we change these "Error" suffixes
in the IANA Printer MIB.

I'll put this topic on the next IPP WG agenda for 31 March.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Mar 17, 2014 at 2:07 PM, Michael Sweet <[email-masked]> wrote:

> All,
>
> It was recently pointed out to me that PWG 5100.9 defines several
> "printer-state-reasons" keywords with the suffix "-error":
>
> Since an IPP Printer MAY report any of the above keywords when the Printer
> is not in the stopped state, I propose we add an informative note to table
> 5-2 saying something like the following:
>
> I'm not sure if we want to clarify that the "job-state-reasons" attribute
> only contains the registered values without added suffixes.
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 18 Mar 2014 15:23:09 -0400

Ira,

I'm not sure about adoption on these keywords (I've never seen them in the wild), but I'm not keen on changing already-registered values.

Upon further review/thought, it seems to me that the xxx-recoverable-storage-error keywords could all have the -error, -report, or -warning (as appropriate) suffixes, while the xxx-unrecoverable-storage-error keywords all seem to require user interaction and should stop the printer.  So as an alternative to my original proposal we could:

- Register all xxx-recoverable-storage-error keywords as xxx-recoverable-storage and note that implementations must choose the correct suffix (-error, -report, -warning) as appropriate.
- Keep the xxx-unrecoverable-storage-error keywords and note that the printer must be in the stopped state when reporting them.

The advantage is that existing implementations are unaffected, the mapping from the MIBs to IPP remains "clean", and we set precedent for printer-state-reasnos keywords: when registering a keyword with an -error, -report, or -warning suffix, that is the only allowed suffix for the keyword (no -error-error, -error-warning, etc.)

(I'm not super happy about the resulting registered names, but once you add a suffix the xxx-recoverable-storage-bla name sort of makes sense...)

---

From: Ira McDonald <[email-masked]>
Date: Tue, 18 Mar 2014 16:15:07 -0400

Hi Mike,

I like your revised proposal better.

For the future, we should always use the suffix "Fault" in IANA Printer MIB
and "-fault" in IPP when new alerts need it for clarity (so that the IPP and
Printer MIB equivalents for severity can be used).

The "Error" suffix in PWG 5100.9 in IANA Printer MIB was a mistake (now
5 years old, sadly), because the separate prtAlertSeverityLevel object must
always distinguish between and "critical" and "warning" (there is no such
thing as "report" in the Printer MIB, which is an original RFC 1759 bug).

Cheers,
- Ira

On Tue, Mar 18, 2014 at 3:23 PM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> I'm not sure about adoption on these keywords (I've never seen them in the
> wild), but I'm not keen on changing already-registered values.
>
> Upon further review/thought, it seems to me that the
> xxx-recoverable-storage-error keywords could all have the -error, -report,
> or -warning (as appropriate) suffixes, while the
> xxx-unrecoverable-storage-error keywords all seem to require user
> interaction and should stop the printer.  So as an alternative to my
> original proposal we could:
>
> - Register all xxx-recoverable-storage-error keywords as
> xxx-recoverable-storage and note that implementations must choose the
> correct suffix (-error, -report, -warning) as appropriate.
> - Keep the xxx-unrecoverable-storage-error keywords and note that the
> printer must be in the stopped state when reporting them.
>
> The advantage is that existing implementations are unaffected, the mapping
> from the MIBs to IPP remains "clean", and we set precedent for
> printer-state-reasnos keywords: when registering a keyword with an -error,
> -report, or -warning suffix, that is the only allowed suffix for the
> keyword (no -error-error, -error-warning, etc.)
>
> (I'm not super happy about the resulting registered names, but once you
> add a suffix the xxx-recoverable-storage-bla name sort of makes sense...)
>
>
>> Since an IPP Printer MAY report any of the above keywords when the
>> Printer is not in the stopped state, I propose we add an informative note
>> to table 5-2 saying something like the following:
>>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 20 Mar 2014 15:09:47 -0400

OK, I have updated the pending registrations at:

    http://www.pwg.org/ipp/ipp-registrations.xml

with the proposed changes.