Ron,
Lets keep the discussion going on job state reasons, because your proposed
workding is just what I am worried about. My understanding of your proposed
wording suggests that the agent only need make the reasons be correct,
when the job state changes. This is exactly the interpretation that
the participant asked if it was ok to only make the reason be correct
when the job changed state (and was like the old PDP-11 devices).
In fact, an application is encouraged to look at the reasons whenever
it looks at the job. Also since we don't have trapping, there is no
way for an application to know when a job actually changes state, except
to notice that the job state value is different on the current poll cycle
from the last poll cycle.
I want to make it clear that the job state reason value(s) may:
1. change when the job state changes (the usual case)
Example: job changes state from 'processing' to 'completed' and the
'jobCompletedSuccessfully' reason is set at the same time. This reason
remains set for the entire remaining life of the job in the 'completed'
state.
2. change while the job state does not change, i.e., some job state
reasons may come and go while a job remains in the same state
(less likely)
Example: the job is in the 'pending' state and the printer stops,
so the reason 'deviceStopped' comes and goes while the job remains
in the 'pending' state.
Example: the job is canceled so the job transitions from 'processing'
to 'canceled', with the (new) 'processingToStopPoint' reason is set
and the 'jobPrinting' reason may be set.
However, while the job is in the 'canceled' state, the processing to
stop point completes and the marking media completes, so that the
'processingToStopPoint' and the 'jobPrinting' reasons go away (and
not necessarily at the same time).
3. remain the same while a job changes state (rare, but possible).
Example: a job with the "jobHold" attribute set would have the
'jobHoldSpecified' reason set as well. However, if the job was
canceled, the job would change from the 'pendingHeld' state to the
'canceled' state. The implementation MAY keep the
'jobHoldSpecified' reason set during the remaining life of the job.
I'm also trying to understand your concerns about the wording below:
At 15:37 08/27/97 PDT, Ron Bergman wrote:
>Tom,
>>I still do not like the disputed text and do not believe that it properly
>answers the question. I propose as an alternative:
>> "Since the Job State Reasons will be more dynamic than the Job State,
> it is recommended that a job monitoring application read this object
> every time the current Job State is updated."
>>This presents the same idea from a different perspective and also
>eliminates the tone of the previous statement that "this object is
>special and must be valid". And also implies that other objects do
>not have to be valid since I did not explicitly say so.
I'm still puzzled as to why you think the phrase: "when implemented as
with any MIB data" makes the reasons be special. The statement is trying
to say that reasson, like any other MIB data, must agree with the conditions
of the device.
I'm also puzzled as to why you think that the same phrase: "when implemented
as with any MIB data" allows any other MIB data to not be valid?
Is there a better way to say that reasons must be just as valid as
other MIB objects and attributes and that reasons must not become stale
(as with any other MIB data)?
Tom
>>Again, this is a minor issue and I am being somewhat hard-nosed, but
>I would like to get the wording correct now.
>>> ...Ron
>>>On Tue, 26 Aug 1997, Tom Hastings wrote:
>>> At 16:59 08/20/97 PDT, Ron Bergman wrote:
>> snip...
>>>> >> >6. In jmJobStateReasons1 (page #81), I find the following statement
>> >> > hard to disagree with, but why do we need to state this?
>> >> >
>> >> > "Furthermore, when implemented as with any MIB data, the
>> >> > agent SHALL return these values when the reason applies and
>> >> > SHALL NOT return them when the reason no longer applies whether
>> >> > the value of the job's jmJobState object changed or not."
>> >> >
>> >> > All this really states is that the value of an object must be valid.
>> >> > We do not have a similar statement for any other object.
>> >>
>> >> I disagree. One commentor asked whether the bits had to be turned off or
>> not,
>> >> so I felt it was important to clarify that these bits are meaningful while
>> >> the job is in each job state, not just when the job transitions from one
>> >> state to another. There are hardware implementations in which such bits
>> >> are only meaningful on the state transitions. As far as I'm concerned,
>> >> if someone asks about something it can't hurt to include the explanation
>> >> in the document. There will be others who will ask the same question, but
>> >> we won't be there to answer.
>> >>
>> >Since the question was asked, this should be in the FAQ and not in the
>> >specification. All this sentence states is "thou shall not lie". If
>> >the document states that this attribute indicates this condition and
>> >the implementation sets the attribute when the condition is not true,
>> >the implementation is violating the specification! I do not believe
>> >that the document should answer every question that was asked. That
>> >is why we should have a FAQ.
>>>> The question was asked about the text that was in the spec. I believe
>> that the FAQ should be answering questions that people have how haven't
>> read the document or are getting into it. Of course, after we publish
>> the specification, we can also use the FAQ to answer questions of
interpretation
>> of the standard, which would be better than nothing (since we can no longer
>> update the spec).
>>>> So if we have a question about interpretation of the text in the spec
>> BEFORE the spec is published, the answer should go in the spec.
>>>> Also from my experience with hardware devices, such as PDP-11 I/O
devices, the
>> question was whether the bits where only to be sampled when a job state
>> transition occurred, such as in some I/O devices, or could be sampled any
time.
>>>> Finally, I took into account your concern/question about "why wouldn't we
>> have to make a similar statement about other objects in the MIB", by adding
>> the phrase: "as with any MIB data", so we don't have to add the phrase
>> to any other object.
>>>> Since you said it was hard to disagree with, lets leave it in. Ok?
>>>> Tom
>>>>>>>>>