> > 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".
Yeah, I agree with you, unless someone can make a clear case for a
difference in semantics between "requested" and "required" in this context.
> > 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?
I'm wondering the same thing. (But have no opinion either way right now.)
It just seems like we might be missing something here by eliminating HELD.
> RB> Again, I would support keeping both the needsAttention and held
> RB> states. These could easily be mapped to IPP. Comments?
I tend to agree. However, exactly what is abstracted as a "state"
versus a "reason" depends on exactly what problems we're trying to
solve (and which paradigm to use to solve those problems), would you
agree?
We need to hash this out pretty quickly!
...jay