On Sun, 25 May 1997, Tom Hastings wrote:
> 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.
>RB> As you know, there is still some discussion regarding needsAttention.
> 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.
>RB> Exactly what does "mandatory" imply? Is the state only reported
RB> if implemented? It seems like it would be difficult to report if it
RB> is not implemented. Then what is the difference between "mandatory"
RB> and "conditionally-mandatory"? I propose that jmJobState is really
RB> what is "mandatory", not the possible values. All values possible
RB> in an implementation must be supported.
> 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.
>RB> In trying to answer your question I cannot find where I saw the
RB> duplicate text in jmJobState. I may have been looking at jobState
RB> on page 35. Will this (jobState) be removed in the next draft?
> 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?
>RB> That was not my original intent, but it is a good move. See comment
RB> above regarding mandatory.
> 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.
>RB> It appears that this may occur, but I don't believe that an agreement
RB> has been reached. We still need to resolve the "needsAttention"
RB> issue. Note that These issues should not delay the posting of the
RB> next draft update.
>> 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.
>RB> Very good!
> < 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.