At 18:46 08/28/97 PDT, Ron Bergman wrote:
>Tom,
>>I understand exactly what you you mean. That is not the issue.
>>What I was trying to say in my new wording is that the Job Monitor Ap
>should read the Job State Reasons every time he attempted to update (i.e.
>read) the job state. He may read the job state many times before it
>changes. My meaning of "update" was "the monitor reads the job state".
>>So let me reword again:
>> "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 jmJobState is read."
>>Is this better?
Much better! I can live with it.
>> ...Ron
>>>>On Thu, 28 Aug 1997, Tom Hastings wrote:
>>> 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.
>>>RB-- My point is, we write a specification which defines the meaning
>RB-- for an object. We should not then have to then say, "if you
>RB-- implement this object, it must be valid".
>>> 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?
>>>RB-- By making a special case here it could be implied. If this is true
>RB-- for all other MIB data, why does have to be stated explicity here?
>>> 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)?
>>RB-- Good implementations always present valid information and should
>RB-- not have to be explicity told. I am trying to answer the question
>RB-- in, what I believe, is a better point of view. By indicating that
>RB-- the Monitoring Ap must look at this often implies what you have
>RB-- been trying to say. Again, I do not disagree with your statement,
>RB-- I just do not feel it belongs in the document.
>>>> 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
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>>>>>>