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.
>
>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)
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.
>
> ...jay
>
>----- Begin Included Message -----
>
>>From jmp-owner@pwg.org Wed Jun 4 13:53 EDT 1997
>Date: Wed, 4 Jun 1997 13:56:06 -0400
>From: bwagner@digprod.com (Bill Wagner)
>Subject: Re: JMP> Re: jmJobState [which mandatory job states?]
>To: jmp@pwg.org
>Cc: case@snmp.com
>Content-Transfer-Encoding: 7bit
>
> 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
>So lets be clear that conformance requirements are for the agent, not
>the device (printer or server).
>
>
>
>
>
>----- End Included Message -----
>
>
>