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).
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
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Tue, Mar 18, 2014 at 3:23 PM, Michael Sweet <msweet at apple.com> wrote:
>> 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...)
>>> On Mar 17, 2014, at 4:53 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> 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.
> - 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: blueroofmusic at gmail.com> 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 <msweet at apple.com> wrote:
>>>> It was recently pointed out to me that PWG 5100.9 defines several
>> "printer-state-reasons" keywords with the suffix "-error":
>>>> However, RFC 2911 reserves this suffix for indicating the severity of the
>>>> 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
>>>> 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
>>>> 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
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>>>>>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>-------------- next part --------------
An HTML attachment was scrubbed...