Subject: JMP> Re: jmJobState [which mandatory job states?]

From: Tom Hastings <[email-masked]>
Date: Tue, 3 Jun 1997 09:44:05 PDT

At 07:15 06/03/97 PDT, Harry Lewis wrote:
>Combining from a couple previous notes...
>
>>As I've tried to reason before, the 'completed' state is one of the
>>most important states to make mandatory, not conditionally mandatory.
>
>>Most printers today do not have a 'completed' state, at least not one
>>that lasts for a human perceptable time.  So if JMP doesn't make the
>>'completed' state mandatory, no one need implement it.
>
>>Tom
>
>These two statements are contradictory. If most printers don't
>have a completed state then how can we possibly make completed state
>mandatory?\

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

---

From: [email-masked] (Bill Wagner)
Date: Wed, 4 Jun 1997 13:56:06 -0400

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

---

From: JK Martin <[email-masked]>
Date: Wed, 4 Jun 1997 15:35:08 -0400 (EDT)

I completely agree with Bill here.  This whole issue seems quite
insane to me.  What is it about the Job MIB regarding enums that
is any different than any other MIB-related effort we've done???

Tom:  You posted a message to the IPP/JMP lists encouraging folks
      to read your documents relating to the IPP telecon later today.
      With regard to your pushing the definitions of MANDATORY and
      CONDITIONALLY MANDATORY for job enums...well, give it up.

As Bill points out, not one single person has stood up in defense
of a need for such definitions, so why are we still discussing this?
(Much less, taking up valuable telecon time)

	...jay

----- Begin Included Message -----

>From [email-masked] Wed Jun  4 13:53 EDT 1997
Date: Wed, 4 Jun 1997 13:56:06 -0400
From: [email-masked] (Bill Wagner)
Subject: Re: JMP> Re: jmJobState [which mandatory job states?]
To: [email-masked]
Cc: [email-masked]
Content-Transfer-Encoding: 7bit

   Tom, 

  Bill Wagner, Osicom/DPI

     

----- End Included Message -----

---

From: Tom Hastings <[email-masked]>
Date: Thu, 5 Jun 1997 08:39:04 PDT

>is any different than any other MIB-related effort we've done???

The Printer MIB is the only other MIB "we've" done and it has
some mandatory enums in it, so I'm very confused by your statement.
Here is the relevant lines from pages 91-92 of RFC 1759 which lists
mandatory enums in the prtGeneralReset object.

-- compliance statements
prtMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
        "The compliance statement for agents that implement the
        printer MIB."
    MODULE -- this module
    MANDATORY-GROUPS { prtGeneralGroup, prtInputGroup, prtOutputGroup,
                       prtMarkerGroup, prtMediaPathGroup,
                       prtChannelGroup, prtInterpreterGroup,
                       prtConsoleGroup, prtAlertTableGroup }

        OBJECT      prtGeneralReset
        SYNTAX      INTEGER {
                        notResetting(3),
                        resetToNVRAM(5)
                    }
        DESCRIPTION
            "It is conformant to implement just these two states in
            this object.  Any additional states are optional."

        OBJECT      prtConsoleOnTime
        MIN-ACCESS  read-only
        DESCRIPTION
            "It is conformant to implement this object as read-only."

        OBJECT      prtConsoleOffTime
        MIN-ACCESS  read-only
        DESCRIPTION
            "It is conformant to implement this object as read-only."

    -- the prtResponsiblePartyGroup, prtExtendedInputGroup,
    -- prtInputMediaGroup, prtExtendedOutputGroup,
    -- prtOutputDimensionsGroup, prtOutputFeaturesGroup,
    -- prtMarkerSuppliesGroup, prtMarkerColorantGroup,
    -- and the prtAlertTimeGroup are completely optional.
    ::= { prtMIBConformance 1 }

Part of the problem is that many of us are new to SNMP (me included),
so that these conformance issues are not well appreciated.

>(Much less, taking up valuable telecon time)

Ok, I'll desist for now and get the next version of the MIB out.
These discussions have been keeping me from updating the document
as quickly as I had hoped with the good agreements we have reached
in other areas.

However, I want to check with some real SNMP experts
here.  My experience with any standard that has significant implementations
and significant testing groups and significant producer implementations
interworking with consumer implementations from different implementation
organizations, is that conforance requirements is the only way to get
interoperability.

At Digital we had the PDP-11 whose implementations were all over the map.
Our answer was the VAX with specific conformance requirements that the
processors had to meet and that the software could count on.  The compatibility
was very high on the VAX, and not so good on the PDP-11.  (I was one of the
five authors of the VAX architectural spec, so I've been through this
interworking thing on a spec for an iterface).

The simplest example of a conformance requirement which shows that such
a requirement is more than the nonimal dimension is the tolerance dimensions 
on an interchangable part in manufacturing.  The size of something isn't, 
say, just a nominal 5 inches, but 5 inches plus or minus a specified tolerance,
say .01 inches.  A conforming implementation is one that measures within the 
tolerance and will fit into something that is expecting something in the 
range of 4.99 to 5.01 inches.

Without the conformance requirement specified in the interface spec, some 
implementor might have thought that 4.9 was close enough.  But his
implementation would not interwork with (plug into) something that 
expected 4.99 to 5.01 inches.

---

From: Tom Hastings <[email-masked]>
Date: Thu, 5 Jun 1997 08:38:44 PDT

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.

---

From: [email-masked] (Bill Wagner)
Date: Thu, 5 Jun 1997 13:30:08 -0400

Tom,
     
     Many thanks for the response. I think the point is moot now, but I 
     guess I would argue that:
        1. since the MIB is dealing with states of a short-lived entity,the 
     states are all transitory. The management applications have no 
     guarantee that they will see each state that the job goes 
     through,whether that state is mandatory or not.
        2. the MIB documents the desired implementation; the market 
     pressures and desire to add value to the product will ultimately be 
     the major driving force to follow this implementation as closely as 
     feasible. Getting into squabbles about what is compliant or not, when 
     it does not significantly aid utilization, is fruitless. 
     
     Bill Wagner,  Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: JMP> Re: jmJobState [which mandatory job states?]
Author:  Tom Hastings <[email-masked]> at Internet
Date:    6/5/97 8:38 AM

Bill,

different vendors).] ...