I agree with Ron.
...jay
----- Begin Included Message -----
Date: Wed, 27 Aug 1997 15:37:57 -0700 (Pacific Daylight Time)
From: Ron Bergman <rbergma at dpc.com>
To: Tom Hastings <hastings at cp10.es.xerox.com>
cc: jmp at pwg.org
Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 6. when job
state reasons must be turned on and off
X-X-Sender: rbergma at it.dpc.com
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.
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
>>>
----- End Included Message -----