At 17:46 08/12/97 PDT, Ron Bergman wrote:
>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'm sorry that I didn't have time to respond before as to why I did not
include these (few) editorial comments. See if you agree with my reasoning
for not including them. I did include 99% of your suggestions and they
improved the document.
> I do not believe
>that any of the corrections change the intent of the document.
I agree that none of your corrections changed the intent of the document,
including these few that I did not include.
>>>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.
I disagree. I think that it is important to understand the terms that
the Job Monitoring MIB is using and to have an example mapping on this
term. I also didn't want to include only the PostScript example. It seems
more even handed to keep both examples to show that the mapping varies
depending on the job submission protocol.
>>2. The definitions in section 2 should begin with a capital letter.
> Example: "Job Set: A group of jobs..."
I agree and both the .doc and .txt files have "Job Set", not "job set".
None of the definitions themselves start with a capital letter, so I assume
that you are not talking about "A group of jobs...", as opposed to "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.
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.
>>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."
I think that it helps to clarify that there are several ways that
an implementation can set the value, so I left in both ways.
>>5. For jmGeneralAttributePersistence (page #76) the above comment
> also applies.
I left both in for the same reason.
>>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.
>>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."
>
I had taken your suggestion in V0.84, but kept it in the active voice:
When the agent cannot provide a reason for the current state of the
job, the agent SHALL set the value of the jmJobStateReasons1
object and jobStateReasonsN attributes to 0."
I have tried hard to avoid the passive voice, since there are many entities
in the system that do things: the agent, the device, the server,
the management app, etc. So I indicated that is the agent that sets
the values to 0.
>>> Ron Bergman
> Dataproducts Corp.
>
So I hope you agree that all of your editorial suggestions are closed.
Thanks,
Tom