IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from toda y's meeting

IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from toda y's meeting

IPP> MOD> printer-state-reasons PROPOSED RESOLUTION from toda y's meeting

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Sep 24 14:47:29 EDT 1999


Carl,

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 at us.ibm.com [mailto:kugler at us.ibm.com]
> Sent: Friday, September 24, 1999 8:41 AM
> To: Hastings, Tom N
> Cc: ipp at 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 at cp10.es.xerox.com> on 09/23/99 11:53:52 AM
> 
> To:   Carl Kugler/Boulder/IBM at IBMUS, ipp at pwg.org
> cc:   "Manros, Carl-Uno B" <cmanros at cp10.es.xerox.com>, Ira Mcdonald
>       <imcdonal at 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 at cp10.es.xerox.com]
> Sent: Thursday, September 23, 1999 09:05
> To: kugler at us.ibm.com; ipp at 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 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
> 
> 
> 



More information about the Ipp mailing list