Tom,
On Wed, 28 May 1997, Tom Hastings wrote:
[snip .... snip]
> >RB> As you know, there is still some discussion regarding needsAttention.
>> Yes, but I have not heard anyone who favors needsAttention as a job state
> respond to the IPP reasoning that needsAttention or printerStopped applies
> equally well to the pending state as to the processing state and so should
> be a job state reason, not a distinct job state.
>> Harry has pointed out that he doesn't like having a change in the printer
> state "ripple" though the pending jobs. However, one way to implement
> the job state reasons, is to only evaluate the printerStopped reason
> when an application actually does a Get for a particular job. This
> technique is sometimes called "lazy evaluation". The agent
> doesn't have to affect any of the other pending jobs, until the application
> actually does a Get for them. Then a change in state of the
> printer does NOT ripple through the pending jobs and is not an implementation
> problem for the agent. Instead, the user gets told that his job is the current
> job that is using or is in a queue for a stopped printer which IPP thinks
> is what users want to know.
>RB> See email from Bob Herriot late yesterday "RE: JMP> IPP>MOD HELD
RB> vs NEEDS-ATTENTION". This appears to be a very well constructed
RB> proposal and I hope will be discussed in todays IPP teleconference.
RB> I will participate, but only for the first 1.5 hours. Please review
RB> Bob's proposal.
> >
[snip .... snip]
> >RB> Exactly what does "mandatory" imply? Is the state only reported
> >RB> if implemented?
>> No, that is what a Conditionally Mandatory state is.
>> It seems like it would be difficult to report if it
> >RB> is not implemented. Then what is the difference between "mandatory"
> >RB> and "conditionally-mandatory"? I propose that jmJobState is really
> >RB> what is "mandatory", not the possible values. All values possible
> >RB> in an implementation must be supported.
>> Lets stick with the SNMP definitions of mandatory and conditionally
> mandatory. Mandatory is something the agent shall do in order to conform.
> Conditionally mandatory is something that the agent shall do, only if the
> implementation that the agent is instrumenting does or has.
>> So for example, if the canceled state is conditionaly mandatory, then
> the agent need only show the canceled state, if the printer that the agent
> is instrumenting supports an operation that cancels jobs. In fact, in IPP,
> level 1, the CancelJob operation is not present. Its only IPP level 2
> that has the CancelJob operation. So the canceled state is mandatory
> only at IPP level 2 conformance.
>> Similary in the JMP, we have agreed (I thought) that pending was conditionally
> mandatory. Only if a printer has jobs in a state where they are waiting
> to be processed, is it mandatory for the agent to show such jobs in the
> pending state.
>> On other hand, in IPP the completed state is mandatory. So even if the
> printer doesn't keep jobs around after they are completed (most do not),
> the agent shall keep the job information around in its MIB tables (though
> the document data may have long gone). So because the completed state
> is mandatory, the agent is forced to do something that the actual output
> device probably doesn't have (unless it was implemented after the Job
> Monitoring MIB was around, so that the agent and the output device are
> an integrated design).
>RB> Tom, I still have a hard time justifying that enums for an object
RB> are "mandatory" or "conditionally-mandatory". It made some sense
RB> for the Attribute Table but for objects in the Job State Table this
RB> generating significant confusion. I still prefer that the *object*
RB> jmJobState be "mandatory" and the enums for the object are implied
RB> to be "conditionally mandatory".
Ron Bergman
Dataproducts Corp.
> >
> >
> >
>>