I agree that the statements are contradictory. The problem is that
when we say "printer", sometimes we are talking about the agent and
printer combined, and sometimes we are talking about just the printer.
To help out, lets be more clear when we are talking about the agent
and when we are talking about the device that the agent is instrumenting
with SNMP.
My understanding of SNMP conformance is that there are two pieces to an
implementation:
1. the agent
2. the device
Of course the agent is usually implemented (embedded) in the device, so
when we say the "device" (or printer), its ambigugous as to whether we
are including the agent or not.
I have the following picture in mind:
management application <------SNMP----> agent <--> device
The interface between the agent and the device is implementation
dependent. The agent could even be elsewhere on the network.
But usually, the agent will be in the device that the agent is instrumenting:
a. in the printer (JMP config 1 and 3) or
b. in the server (JMP config 2)
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).
>
>I am not in favor of describing job states as mandatory or conditionally
>mandatory but I agree that COMPLETED is probably the most "interesting"
>state and would go along with applying some architectural emphasis
>(like was done for prtGeneralReset).
>
>>Then such a printer shall implement the conditionally mandatory
>>pending state. But an implementation that never waited a human perceptible
>>time should not have to implement the 'pending' state. Imagine that you
>>are building a product that is going to be tested against by a testing
>>company. If 'pending' is mandatory and your product doesn't ever show
>>'pending', that testing company might say you didn't conform to the
>>standard.
>
>I agree with Tom's imagination. All the more reason NOT to specify job
>state enumerations as mandatory (except, possibly for Completed).
I would hope that we could agree that all devices do 'processing', so
that making 'processing' be mandatory too won't make
any problems for an agent to be required to implement.
I would also hope that we could agree that all devices also encounter
problems, so that making 'processing-stopped' be mandatory won't make
any problems for an agent to be required to implement.
I also think that all devices abort jobs, so that making 'aborted'
mandatory won't make any problems either.
The remaining states should be conditionally mandatory:
'pending' need not be implemented by an agent that instruments a device
that never has to wait before starting processing for a human perceptable time.
'pending-stopped' not needed by the above and by an agent that instruments
a device that has no job submission attributes that 'hold' a job.
'canceled' is not needed by an agent that instruments a device that doesn't
support a CancelJob operation, such as an IPP level 1 device.
So how about the following conformance requirements for agents for our nine
states:
'other(1)' conditionally mandatory
'unknown(2)' conditionally mandatory
'pending(3)' conditionally mandatory
'pending-stopped(4)' conditionally mandatory
'processing(5)' mandatory
'processing-stopped(6)' mandatory
'canceled(7)' conditionally mandatory
'aborted(8)' mandatory
'completed(9)' mandatory
Tom
>
>Harry
>
>