Thanks for writing this up. This is exactly how I would like to see the
issue resolved as well.
We can add a "health warning" note in the IPP/1.1 model document and provide
some more detail in the IIG if we want.
Carl-Uno
> -----Original Message-----
> From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
> Sent: Friday, September 24, 1999 8:41 AM
> To: Hastings, Tom N
> Cc: ipp@pwg.org; Manros, Carl-Uno B; Ira Mcdonald
> Subject: RE: IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from
> toda y's meeting
>
>
>
>
> Unfortunately, we received your input after the discussion.
> However, we did
> discuss similar concepts at the meeting. The problem with
> all the alternatives
> is that too many existing implementations would break, and we
> could hardly call
> these alternatives minor editorial changes to the document.
>
> 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
>
>
>