The current draft lists processing, needsAttention, canceled, and completed
as Mandatory. Since needsAttention has gone away, that leaves three
states as mandatory: processing, canceled, and completed. Since we added
aborted, I assume that aborted should be added to the mandatory list.
The complicance at the end of the Job MIB spec also lists these states.
I assume that you didn't intend to remove that agreement.
So I'd like to add back the description that some are mandatory and the
rest are conditionally mandatory.
I agree on removing redundant text. However, in this case, the
description in jmJobState was simply a pointer to the textual
convention (after deleteing the sentence: "The value of this object shall
always be the same as that of the jobState attribute, so that this information
appears in both the jmJobStateTable and the jmAttributeTable simultaneously".
since we agreed to get rid of duplicates.
So the real thrust of your comment was to move the description from
the textual convention to the object. So I'll add the sentence about
the mandatory states to the jmJobState object as well, ok?
Tom
At 10:01 05/23/97 PDT, Ron Bergman wrote:
>Tom,
>>In reviewing the Job MIB relative to the job states, I noticed that
>the descriptions for jmJobState and JmJobStateTC are almost identical.
>I would like the specification for jmJobState to appear only once,
>and only in the jmJobState description. I propose that these
>descriptions be revised as follows:
>>jmJobState:
>-----------
>"The current state of the job (pending, processing, held, etc.). The
>final value for this attribute shall be either completed or canceled.
final value for this attribute shall be completed, canceled or aborted.
>before the agent removes the job from the table.
>>Management applications shall be prepared to receive all the standard
>job states. Servers and devices are not required to generate all job
>states, only those which are appropriate for the particular
>implementation. The corresponding attributes JmJobStateReasons1 through
>JmJobStateReasons4 provide additional information about the job states.
>While new job states cannot be added without impacting deployed clients,
>it is the intent that additional Job State Reasons enums can be defined
>without impacting deployed clients."
>>JmJobStateTC:
>-------------
>"Defines the current state of the job."
>>>A similar situation exists for jobStateReasons1 and JmJobStateReasons1TC.
>Again, my recommendation is:
I'm assuming that we have agreed to make jobStateReasons1 mandatory,
in order that the 'printer-stopped' value will always be present (the
new representation for the old needsAttention state that was removed).
Since jobStateReasons1 is an INTEGER, not OCTETS, we will move it to
the jmJobTable right after the jmJobState object, so that the descriptions
will be next to each other. Its name will be jmJobStateReason1.
I've done some further shortening of the description that you proposed.
How does it look?
>>>jobStateReasons:
jmJobStateReasons1;
>----------------
>---OCTETS: Additional information about the job's current state that
Additional information about the job's current state that
>augments jmJobState. The jobStateReasons1 attribute identifies the
>reason or reasons that the job is in the held, pending, processing,
>needsAttention, canceled, or completed state. The agent shall indicate
>the particular reason(s) by setting the value of the jobStateReasons1
>attribute.
augments jmJobState, including the reasons(s) that the job is in its
current state.
< When the job does not have any reasons for being in its
>current state, the agent shall set the value of the jobStateReasons1
>attribute to 0.
>>Companion job state reasons Textual Conventions: JmJobStateReasons2TC,
>JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for an
>additional 93 job state reasons for use with the corresponding
>attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4.
Additional job state reasons may be represented by the attributes:
jobStateReasons2, jobStateReasons3, and jobStateReasons4. See page xxx.
>This is a type 2 bit definition.
>>JmJobStateReasons1TC:
>---------------------
>"This textual-convention is used with the jobStateReasons1 attribute to
>provides additional information regarding jmJobState.
>>The following standard values are defined (in hexadecimal) as powers of
>two, since multiple values may be used at the same time:
>>>If anyone objects to these changes, please respond by June 13.
>>> Ron Bergman
> Dataproducts Corp.
>>>>