On Sun, 25 May 1997, Tom Hastings wrote:
> At 08:06 05/23/97 PDT, Ron Bergman wrote:
> >
> >I agree with all the changes proposed for alignment of the IPP and
> >JMP job states except for the removal of "Needs Attention". This
> >should be the most important state to indicate to a user since
> >unless he takes action the job may never complete. I would think
> >that this would also be very important for IPP as well.
>> In IPP the job-state-reasons 'printer-stopped' is used instead of a separate
> job state called 'needs-attention'. The job can be in either the 'pending'
> or 'processing' state when the reason 'printer-stopped appears.
> If the job is in the pending state, it is some other job that is having
> the problem, but ALL pending jobs are affected, unless the printer problem is
> attended to.
>> We have two choices for the Job Monitoring MIB:
>> 1. Follow IPP and get rid of the needsAttention state and add the
> deviceStopped value to the JmJobStateReasons1TC.
>> 2. Keep the needsAttention state. Don't add the deviceStopped value to the
> jmJobStateReasons1TC. When an agent is instrumenting IPP,
> the agent shall map the IPP 'processing' state to the JMP processing state,
> except when the IPP "job-state-reasons" contains 'printer-stopped'. Then the
> JMP agent shows the job in the JMP needsAttention state. When the IPP
> 'printer-stopped' value is removed from the IPP "printer-state-reasons"
> attribute, the JMP agent shall change the value of the job's jmJobState object
> from the needsAttention state to the processing state. The JMP
> jmJobStateReasons1 object would remain unchanged during this.
>RB> I would vote for number two if these were are only choices.
>> >I also agree with Harry that "requiredResourcesNotReady" and
> >"serviceOffLine" apply better to "Needs Attention" than "Held".
>> The IPP and JMP defintions of requiredResourcesNotReady, say "is not
> ready on any of the physical devices for which the job is a candidate"
> meaning before the job starts processing. Perhaps this reason should
> have a better name, like "requestedResourcesNotReady".
>RB> I don't see any difference in "required" vs "requested".
> IPP says that when the reason 'printer-stopped' is present, the client
> should check the printer-state and printer-state-reasons. For JMP the
> analoguous thing is to check the job's deviceAlert attributes and the
> associated device MIB.
>> But the IPP/JMP meeting also got rid of the held state.
>RB> Have we eliminated too much?
> IPP also renamed 'required-resources-not-ready' to
> 'job-hold-until-resources-are-ready'. The prefix "job-hold-" indicates
> that the job is held and will not process until the reason goes away.
>> Again, JMP could still keep the held state, even though IPP doesn't have it.
> Which may be a good idea, since MIBs use enums, not keywords, so that an
> application can't tell from the enum code whether the job has to have the
> reason removed before it can be processed, or whether the reason is a less
> important one that doesn't affect whether the job will start processing or not.
>> Then a JMP agent would represent the IPP 'pending' state with certain
> "job-state-reasons" value, such as 'job-hold-until-specified', and
> 'job-hold-until-required-resoureces-are-ready' as:
>> the JMP 'held' state and also show the same jmJobStateReasons1 object values.
>RB> I propose that we include the states that make sense for the Job MIB
RB> even if they are not in IPP, as long as they can be mapped into
RB> currently defined IPP states and reasons.
> >(I also agree with Harry that "Printing" is a better description
> >for a user than "Processing". Since this is an enum, a user or
> >management ap can display whatever text that is deemed
> >appropriate. So I will vote to keep "Processing" unless there
> >is very strong support for "Printing".)
> Thanks for being flexible.
>> >
> >(Didn't we discuss "serviceOffLine" in a previous meeting and
> >determined that no one except Dataproducts has ever implemented
> >such a capability? I also indicated that I had recently deleted
> >the feature because I felt it was "stupid".)
>> I don't remember this. Xerox has systems with service-off-line reason.
> The jobs that have been previously accepted are indicated as being in the
> held state with the serviceOffLine reason. Clients can still query the
> server since its the device that is really off-line, not the server.
> Perhaps we should rename the reason from serviceOffLine, to deviceOffLine
> and indicate that it is for configuration 2 in JMP?
>RB> I did not intend this to be a major issue. Leave it in.
> >
> >Also, I agree with Jay that "Needs Attention" should apply to all
> >conditions, other than "Held", that prevents the job from printing.
> >"Held" only implies an administratively set condition.
>> How can the Needs Attention job state apply to all conditions (states)?
> It could if Needs Attention were a job state reason. In IPP we made Needs
> Attention a job state reason, but then renamed it to 'printer-stopped',
> because a device could need attention even though jobs were still
> progressing, such as toner low.
>RB> Not States.. Conditions that prevent the job from printing, i.e. paper
RB> out, paper jam, out of toner, printer unplugged, etc, etc, etc. Then
RB> the "needsAttention" state applies.
> So maybe you and Harry could support the IPP job-state-reason 'printer-stopped'
> as equivalent a Needs Attention job state reason and more flexible than
> if Needs Attention were a job state?
>> >
> >Tom, since I could not participate in the Wednesday conference call,
> >could you explain why "Needs Attention" was not accepted by IPP?
> >It is very critical that JMP and IPP agree in this area and I would
> >hope this can be resolved quickly.
>> As I explained above, IPP thought that Needs Attention was better as a
> job state reason, rather than a job state, and then we renamed the reason
> to printer-stopped to be clearer.
>> I'm sorry that neither you nor Harry were able to call into the IPP
> call last Wednesday. The ball is in yours and Harry's court to see if
> you like the IPP approach and we can use it directly in JMP or whether
> JMP should perform a straight forward mapping when instrumenting an IPP
> system as I outlined above to the JMP held and/or JMP needsAttention states
> and some fiddling with job-state-reasons.
>RB> Again, I would support keeping both the needsAttention and held
RB> states. These could easily be mapped to IPP. Comments?
Ron Bergman
Dataproducts Corp