Subject: JMP> Should jobStateReasons1 be mandatory?

From: JK Martin <[email-masked]>
Date: Thu, 22 May 1997 18:37:02 -0400 (EDT)

[I have changed the Subject line to better reflect the topic]

Harry,

Maybe I'm reading your response wrong, but your comments make it
sound as if we have an excessively complex design for job state
and the associated reason(s):

> >You know, not mandating a "reason" string with the job state doesn't
> >feel good, given that the state may not really say what's going on
> >with the job.  This topic was touched on during yesterday's IPP telecon
> >in which we talked about job attributes wrt IPP vs. JMP definitions.
> 
> >We might want to mandate jobStateReasons1, and not let it fall into
> >the "conditionally mandatory" void, since it supports the #1 target
> >requirement for "tell me what my job is doing".
> 
> >Comments on this?
> 
> Yes, "Tell me what my job is doing", but please, just tell me what
> I want to know in a simple form that I can understand! Not 93
> possible reasons for 7 possible states in 4 seemingly arbitrary
> categories! PENDING, PRINTING, CANCELED, COMPLETE. Obscure PRINTING
> by calling it PROCESSING and throw in HELD and NEEDS ATTENTION (with
> alert code) for good measure - isn't this enough? Jay, have you looked
> at the 7.5 page list of Job State Reasons in the Job MIB? I'm behind
> on mail so maybe this has all been changed but... given the current state,
> of the specification, I prefer to keep the reasons OPTIONAL!

Your comments lead me to believe you're saying that it's too damn
difficult for the printer agent to say what the current "reason" is.
Is this true?  If it is, then I think we're in real deep water here...

I just went thru the V0.81 draft, but couldn't find 7.5 pages of
Job State Reasons in the MIB.  Can you give me a better pointer?
(Am I looking at the proper draft?)  I did find some tables on
various Reasons (pp. 57-58), but I guess I don't see the problem.

Have pity on this poor fool and point me in the right direction...  ;-)

I do agree with you, though, that PROCESSING is bogus, and that PRINTING
should have been the state we kept (and discard PROCESSING instead).
which will be the practical case.

	...jay