This printer-state-reasons suffix (and that no suffix means "-error") is an
important issue to resolve. Please put it on the agenda for the upcoming
IPP meeting. We can fix this in the IPP/1.1 RFC when the RFC Editor asks
for final review, provided we have agreement on how to fix the document.
The current text says:
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".
If a Printer object controls more than one output device, each value of this
attribute MAY apply to one or more of the output devices. An error on one
output device that does not stop the Printer object as a whole MAY appear as
a warning in the Printer's "printer-state-reasons attribute". If the
"printer-state" for such a Printer has a value of 'stopped', then there MUST
be an error reason among the values in the "printer-state-reasons"
attribute.
The following standard keyword values are defined:
Assuming that we cannot remove the concept of suffix from the document,
there seem to be at least two alternatives to resolving the issue as to what
the meaning is when there is no suffix:
Alternative 1:
Replace the paragraph:
If the implementation does not add any one of the three suffixes,
all parties MUST assume that the reason is an "error".
with:
If the implementation does not add any one of the three suffixes,
all parties MUST assume that the reason is a "report", "warning", or
"error" as indicated in the description of the reason. Thus the suffix
MUST be used when the implementation has a different interpretation for
the reason than that given in the description of the reason.
And indicate in the description of each reason whether it is an error,
warning. or report. For example, the 'paused' state reason definition would
indicate that it is a "report" and the "media-needed" state reason
definition would indicate that it is an "error".
Alternative 2:
Replace the paragraph:
If the implementation does not add any one of the three suffixes,
all parties MUST assume that the reason is an "error".
with:
If the implementation does not add any one of the three suffixes,
whether the reason is a "report", "warning", or "error" is
implementation-dependent. Therefore, implementations SHOULD always
append
one of the suffixes: "-report", "-warning", or "-error" in order to
remove the ambiguity for a state reason.
Comments?
Thanks,
Tom
-----Original Message-----
From: Ira Mcdonald [mailto:imcdonal@sdsp.mc.xerox.com]
Sent: Friday, September 17, 1999 07:52
To: ipp@pwg.org; kugler@us.ibm.com
Subject: Re: IPP> MOD> printer-state-reasons
Hi Carl and Tom, Friday (17 September 1999)
This suffix nonsense on 'printer-state-reasons' keywords was a mistake.
And the MUST interpretation of 'error' when a suffix is not present is
EXACTLY wrong. There are important printer state reasons that do NOT
indicate warning or error events - sub-states like 'moving-to-paused',
'paused', 'shutdown', 'connecting-to-device'.
And as Carl observed (below) 'none-error' is obviously broken.
It's never an error for a printer to be 'paused'. It's a neutral report
of a condition. No program error or resource problem has occurred. The
printer is in a sub-state at the request of an authorized human user or
operator.
MOD should be corrected to say that a missing suffix SHALL mean that
the specified state reason is of '-report' severity (or better yet,
abandon suffixes entirely, but prior art won't really let us do that).
Cheers,
- Ira McDonald
High North Inc
906-494-2697/2434
> ----------------------------------------------------------------------
> From: kugler@us.ibm.com
> To: ipp@pwg.org
> Date: Thu, 16 Sep 1999 14:00:13 -0600
> Subject: IPP> MOD> printer-state-reasons
>
> MOD says:
>
> 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).
>
> ...
>
> - '-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".
>
> Does this mean to say that the REQUIRED "printer-state-reasons" attribute
> value must always have a -report or -warning suffix unless the printer is
> in the 'stopped' state? For example, if the printer is idle, MUST I
> have "printer-state" = 'idle' and "printer-state-reasons" = 'none-report'?
> (Can't have "printer-state-reasons" = 'none' since that would be
> semantically equivalent to "printer-state-reasons" = 'none-error' which
> implies that the printer MUST be in the stopped state, not the idle
state.)
>
> - Carl
>
> ----------------------------------------------------------------------