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 at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Wednesday, September 22, 1999 20:32
To: ipp at 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