Bill,
Here goes some thoughts on why having MANDATORY enums be specified
for mandatory objects, so that all conforming agents shall implement
them.
[However, on the telecon yesterday, I was the only person advocating
conformance on the enum values. So I won't keep bringing up this
subject anymore. The e-mail discussion this past week has prevented me
from getting the MIB I need to consult with some SNMP experts in this,
because my understanding of SNMP conformance (see the back of the
Printer MIB, is that conformance of enum values is an important
part of SNMP to help interworking between implementations from
different vendors).]
The major reason for having conformance on enum values is to increase
the chances that an application program
can interoperate with more than one implementation. If an application
program can count on certain enums as being present, because they
are mandatory, then the application designer/implementor can make
plans that will work with evey agent implementation (at least with
the conformant agents).
For those enums that are conditionally mandatory, the application program
designer/implementor knows that he can't count on those enums being
present in all implementations, so the application program has to
take account of the variability that it might encounter.
On the other hand, the conformance requirements for a conforming
monitoring application are that it be able to handle all job states
that an agent might return.
So the completed and aborted states are mandatory enums, so the
application can count on jobs being in those states after a while
and those are the last states that the jobs wind up in.
We as printer vendors can decide that all implementations have some
cases that they detect that causes an abort of the current job, so we
make that state mandatory, so that applications can count on that.
It would be extremely misleading if an application reports to a user that
his job completed, when in fact it really aborted. If the application was
from one vendor and the printer/agent from another there could be some
ugly finger pointing by a customer who was mislead by thinking that his job
printed ok (and he got into the meeting with his handouts or slides, only
to discover that the job was only partially done, because of an abort).
I can even see law suits down the road where a job was not printed
completely, but the customer didn't know that.
On some implementations there may not be the canceled state, such
as an agent instrumenting an IPP level 1 conformant device (which
doesn't have the canceljob operation). However, the monitoring application
designer can probably design around a system that never shows jobs in the
canceled state.
However, an application that also submits a cancel request via some job
protocol that the printer supports that has a CancelJob operation, say,
IPP level 2, and expects to see the result of the cancel through the Job
Monitoring MIB, has every right to expect to see the job end up in the
canceled state, not the completed (or aborted) state. By making the
canceled state CONDITIONALLY MANDATORY we force the IPP level 2 Job Monitoring
MIB agent to support the caneled state. This is because a state that is
labeled CONDITIONALL MANDATORY means that a conforming agent shall report jobs
in the 'canceled' state, if the device has a canceljob operation (which level
2 IPP says is MANDATORY).
If the canceled state were labeled OPTIONAL in JMP, instead of CONDITIONALLY
MANDATORY, then an application designer would have no right to expect to see
canceled jobs on an IPP level 2 JM MIB.
But since our requirements were to support accounting, we know that we must
make the 'canceled' state CONDITIONALLY MANDATORY in order to have meaningful
accounting applications use our MIB.
Remember some of these monitoring applications may be third party
accounting programs. They want accurate reporting on canceling versus
aborting, vs completed. Also a Kinkos customer wants to know what he/she
is getting charged for. If our MIB leaves out this crucial conformance
stuff, the third parties are much less likely to invest in an accounting
package product, because they don't know what they can count on in
the Job Monitoring MIB agents.
As another example, the job-state-reasons of canceled-by-user vs
canceled-by-operator, is very crucial when accounting comes in.
Users may have to pay for canceling their jobs, but not if the operator does.
Kinkos might not be interested using our MIB from various printer vendors,
if these basic accounting requirements are not MANDATORY (or at least
CONDITIONALLY MANDATORY with the condition being that the device supports
a canceljob operation) and so are not present in enough printers to make
it worth Kinko's investment in applications, such as accounting programs,
that use the Job Monitoring MIB.
Most systems that implement canceljob also have some sort of security
so that ordinary users can only cancel their own jobs, but the operator
can cancel any user's job. For any CONDITIONALLY MANDATORY enum, the
condition that makes the enum MANDATORY should be included with the definition
of the enum. So the condition for the canceled-by-user and canceled-by-operator
could be simply: that the device supports a canceljob operation and we know
that any viable implementation has to include the security necessary to
distinguish between the user and the operator. On the other hand, if there
were sufficient systems that did support canceljob, but didn't support the
distinction between a user and an operator, we could add a second condition
that the implementation distinguishes between users and operators.
At 10:56 06/04/97 PDT, Bill Wagner wrote:
> Tom,
>> I would still very much apprecaite a statement of why you (and I
> don't see any one else) insist that the enums must be specified as
> being mandatory or conditionally mandatory. At this point I am not
> even being argumentative. But I see no more reason to make these
> values mandatory than to make certain emulations mandatory, or
> certain paper handling mandatory, or any number of other enums in the
> printer MIB mandatory. All it has done is produce vast discussion of
> what state should be at what compliance level, and concepts of the
> agent fabricating states that are inperceptable by the equipment or
> by a user. Please Tom, what is the reason for assigning compliance
> levels to the state values?
>> Bill Wagner, Osicom/DPI
>>So conformance requirements in a MIB specification are ONLY on the agent as
>measured through SNMP operations by a management application.
>>For the completed state, its the agent, not the device that will usually
>retain the data for the row for each completed job. But if 'completed'
>were only conditionally mandatory, then the agent doesn't have to add
>anything extra to what the device already has. So if the device doesn't keep
>job information after the job finishes processing, the agent wouldn't
>have to either, IF the 'completed' state were conditionally mandatory.
>>So lets be clear that conformance requirements are for the agent, not
>the device (printer or server).
>>>>>