Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition of "device"

From: Tom Hastings <[email-masked]>
Date: Tue, 26 Aug 1997 17:47:57 PDT

At 16:59 08/20/97 PDT, Ron Bergman wrote:
snip...
>> >3. The definition for "Device" (page 14):
>> >
>> >   "...interfaces to humans in human perceptible means, such as produces
>> >    marks on paper, scans marks on paper to produce an electronic
>> >    representations, or writes CD_ROMS..."
>> >
>> >   The second two examples don't appear to be human perceptible.  I am
>> >   not sure I understand the reason for including other than the first
>> >   example.
>> 
>> It is important to clarify that the device can produce other forms of
>> human perciptable output than just printing devices, as we agreed in
>> the requirements document.  So I left these other examples in.
>> 
>How is scaning marks on paper or writing a CD ROM human perceptible?
>The only way you know for sure the operation was completed (or even
>started) was a message on display or a printer.

A scanner takes media that has human preceptible marks on it and scans
it. I agree that the CD ROM writer is not human perceptible.

The full definition for "device" from V0.83 is:

Device:  a hardware entity that (1) interfaces to humans in human
perceptible means, such as produces marks on paper, scans marks on paper to
produce an electronic representations, or writes CD-ROMs or (2) interfaces
electronically to another device, such as sends FAX data to another FAX device.

But I feel that we need to make our definition agree with the requirements
that we worked on for so long that the MIB could also be used for jobs that 
scan, jobs that write CD-ROMs, and jobs that send FAX, though the inclusion
of attributes for such jobs was beyond the scope of the current MIB.

So how about:

Device:  a hardware entity that (1) interfaces to humans, such as produces
marks on paper or scans marks on paper, (2) accesses digitial media, such as
CD-ROMs, or (3) interfaces electronically to another device, such as sends
FAX data to another FAX device.

Tom

---

From: Ron Bergman <[email-masked]>
Date: Wed, 27 Aug 1997 15:37:57 -0700 (Pacific Daylight Time)

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:

> >> >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
> 
> 
>