At 08:08 05/27/97 PDT, Ron Bergman wrote:
>>>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.
Yes, but I have not heard anyone who favors needsAttention as a job state
respond to the IPP reasoning that needsAttention or printerStopped applies
equally well to the pending state as to the processing state and so should
be a job state reason, not a distinct job state.
Harry has pointed out that he doesn't like having a change in the printer
state "ripple" though the pending jobs. However, one way to implement
the job state reasons, is to only evaluate the printerStopped reason
when an application actually does a Get for a particular job. This
technique is sometimes called "lazy evaluation". The agent
doesn't have to affect any of the other pending jobs, until the application
actually does a Get for them. Then a change in state of the
printer does NOT ripple through the pending jobs and is not an implementation
problem for the agent. Instead, the user gets told that his job is the current
job that is using or is in a queue for a stopped printer which IPP thinks
is what users want to know.
>>> 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?
No, that is what a Conditionally Mandatory state is.
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.
Lets stick with the SNMP definitions of mandatory and conditionally
mandatory. Mandatory is something the agent shall do in order to conform.
Conditionally mandatory is something that the agent shall do, only if the
implementation that the agent is instrumenting does or has.
So for example, if the canceled state is conditionaly mandatory, then
the agent need only show the canceled state, if the printer that the agent
is instrumenting supports an operation that cancels jobs. In fact, in IPP,
level 1, the CancelJob operation is not present. Its only IPP level 2
that has the CancelJob operation. So the canceled state is mandatory
only at IPP level 2 conformance.
Similary in the JMP, we have agreed (I thought) that pending was conditionally
mandatory. Only if a printer has jobs in a state where they are waiting
to be processed, is it mandatory for the agent to show such jobs in the
pending state.
On other hand, in IPP the completed state is mandatory. So even if the
printer doesn't keep jobs around after they are completed (most do not),
the agent shall keep the job information around in its MIB tables (though
the document data may have long gone). So because the completed state
is mandatory, the agent is forced to do something that the actual output
device probably doesn't have (unless it was implemented after the Job
Monitoring MIB was around, so that the agent and the output device are
an integrated design).
>>> 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?
Yes, I've removed all of the attributes that have redundant objects in the
jmJobTable. However, I've moved any text from the attribute description
to the object, and made sure that there isn't any duplication in the TC.
So I was doing what you suggest, namely to eliminate duplication and put
most of the description in the object, instead of the TC.
You might want to take a look at the JmAttributeTypeTC and jmAttributeTypeIndex
because there is a lot of text in JmAttributeTypeTC that would seem hard
to move to the jmAttributeTypeIndex object.
>>> 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.
Unfortunately, its hard to gauge "consensus" by a few email responses
on an issue. Others may have not yet resonded, or may have no opinion.
It will be easy to change jmJobStateReasons1 back to a mandatory
attribute (or a conditionally mandatory) attribute after the next draft
if that is what we agree on.
But we really need some better way to bring up an issue, get some resonses
and then declare a decision.
Jay,
Boy would AltaVistaForum help these discussion in JMP. Sigh.
>>>> 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.
>>>