Subject: PMP> Interoperability issues found during testing

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Mon, 3 Feb 97 23:58:24 MST

Michael Kirkhan wrote

>1. Are values other than cover(6) (such has input(8) or output(9))
>considered valid for a prtAlertGroup entry added as the result of a cover
>being openned?  Should it be clarified which values other than
>cover(6) should be considered valid?

My immediate reaction is NO. However, I had posed the opposite question
some time ago... if there is a jam at the input or output, for example,
is it appropriate to call out the cover group and cover index (which
would most likely be opened to access the jam) rather than the input
or output groups. We had weak consensus - YES. I suppose someone could
view the scenario you described as synonymous.

In general, covers have their own group. While I can visualize a JAM
under a cover, I have a harder time supporting the notion of a cover
open in the input group.

>2. The operation of hrPrinterStatus (rfc 1514) is somewhat ambiguous due
>to a description which doesn't match the actual enumerations for the
>object.  The values listed for idle, printing and warmup in the
>description do not match the actual enumerations.  Also, the description
>mentions running(2) and warning(3) which are not defined in the syntax
>field.  Because of this they can't really be used legally.  So, if some
>sort of error condition occurs, should the value of hrPrinterStatus be set
>to other(1), or unknown(2)?  Currently one of the tests is checking that
>the status is not set to other(1), which would be wrong if other(1) is the
>proper value.

There is a table in the MIB which tries to correlate the "decoder ring"
as it is sometime called. Maybe best to review this tomorrow in person.

Harry Lewis - IBM Printing Systems