I think it would be useful to add some discussion to the implementer's guide.
Some combinations of "printer-state" and "printer-state-reasons" values are
nonsense. Some combinations of printer-state-reason and
printer-state-reason-suffix are nonsense. It would be worth pointing out those
pitfalls and recommending that Printers always include a suffix unless the
"printer-state-reasons"='none'.
-Carl
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 09/23/99 11:53:52 AM
To: Carl Kugler/Boulder/IBM@IBMUS, ipp@pwg.org
cc: "Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com>, Ira Mcdonald
<imcdonal@sdsp.mc.xerox.com>
Subject: RE: IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from toda y's
meeting
Carl,
Did the group consider either of these two alternatives that Ira and I had
sent out on Monday?:
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", and/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.
And an even simpler clarification would be:
Alternative 3:
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. A client can query the Printer's
"printer-state"
to determine whether the Printer is 'stopped', 'processing', or 'idle.
Then we could put the indication of which are reports, warnings, or errors
in
the Implementer's Guide along the lines of the mail we sent Wednesday.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, September 23, 1999 09:05
To: kugler@us.ibm.com; ipp@pwg.org
Cc: Hastings, Tom N; Manros, Carl-Uno B; Ira Mcdonald
Subject: RE: IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from
toda y's meeting
I certainly agree with the clarification that 'none' MUST NOT have a suffix.
Let me test my understanding about the other values though for which there
is no change from the assumption that with no suffix, client and Printer
assume that it is an 'error'. For example, for the case of the
Pause-Printer operation which REQUIRES that the printer add the 'paused'
value to the "printer-state-reasons", which suffix are implementations
adding, if any:
'paused'
'paused-report'
'paused-warning'
'paused-error'
Some people consider that when an operator pauses the printer with the
Pause-Printer operation that it is an error (because the printer is
stopped), some might consider it a warning because the printer can't print
until it is resumed but it isn't an error, and some might consider it a
report, since the system didn't detect any error. The easiest
implementation would be not to add a suffix at all ever (but that might
impact .
So are client implementers happy with the resolution that they had better be
able to accept all four keywords (or parse away the suffix)?
Same question for the 'moving-to-paused' value (which is only REQUIRED if
pausing takes a "significant amount of time"). Which suffix are
implementations adding, if any:
'moving-to-paused'
'moving-to-paused-report'
'moving-to-paused-warning'
'moving-to-paused-error'
Again, are client implementers happy with the resolution that they had
better be able to accept all four keywords (or parse away the suffix)?
The intent of our proposal was to reduce the number of keywords by 75% and
clarify which are reports, and which are warnings/errors.
Thanks,
Tom
-----Original Message-----
From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
Sent: Wednesday, September 22, 1999 20:32
To: ipp@pwg.org
Cc: Hastings, Tom N; Manros, Carl-Uno B; Ira Mcdonald
Subject: RE: IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from
today's meeting
After protracted debate at today's IPP WG meeting, we came to the conclusion
that this is really a minor issue, and that we'd prefer to resolve it with
minimal impact to existing implementations and minor editorial changes to
the
standard document. After some analysis, we concluded that the one really
problematic case is "printer-state-reasons"='none'. This is a special case
that
is an artifact of the requirement that an attribute with "1SetOf" syntax
MUST
contain at least one value. If we handle this case as an exception, we can
solve the problem with minimal effort.
Therefore, we propose the following change to MOD section 4.4.11,
printer-state-reasons (1setOf type2 keyword):
Change this sentence:
If the implementation does not add any one of the three suffixes, all
parties MUST assume that the reason is an "error".
to say this:
If the implementation does not add any one of the three suffixes, all
parties MUST assume that the reason is an "error", unless the keyword value
is
'none'. (The keyword value 'none' indicates that there is no particular
reason
for the current "printer-state", so a severity suffix on this value would be
superfluous.)
-Carl Kugler