Tom,
The following editorial corrections from revision 0.83 were not
incorporated into version 0.84. Please comment if there is a
reason that these should not be incorporated. I do not believe
that any of the corrections change the intent of the document.
Problems from 0.83:
1. Section 2. Terminology and Job Model (page 14) states:
"PJL systems use the term job to mean what we call a job in this
specification. PJL also supports multiple documents per job, but
does not support specifying per-document attributes independently
for each document."
This text should be a part of the mapping document. This additional
example does not provide any additional help in understanding the
subject paragraph.
2. The definitions in section 2 should begin with a capital letter.
Example: "Job Set: A group of jobs..."
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.
4. In jmGeneralJobPersistence (page #75), the second paragraph:
"Depending on implementation, the value of this object MAY be
either: (1) set by the system administrator by means outside
this specification or (2) fixed by the implementation."
Since this is a read only object do we need to define how it is
configured? We only need to describe the function. Suggest:
"Configuration of this parameter is implementation dependent."
5. For jmGeneralAttributePersistence (page #76) the above comment
also applies.
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.
7. Also in jmJobStateReasons1 (page #81), the next sentence:
"When
the job does not have any reasons for being in its current
state, the agent SHALL set the value of the jmJobStateReasons1
object and jobStateReasonsN attributes to 0."
I suggest it be reworded to:
"When the agent cannot provide a reason for the current
state of the job, the value of jmJobStateReasons1 object
and jobStateReasonsN attributes shall be 0."
Ron Bergman
Dataproducts Corp.