At 20:18 04/27/1998 PDT, don@lexmark.com wrote:
>
>Here's where I agree:
>
>IEEE Std 1284.1 uses the same concept to allow access to MIB objects. We
>including then entire OID string which allow access to any MIB including
>private extensionsm MIB 2, etc. This has worked out very well allowing
>using common code in the printer and presenting a single, unified
>presentation of printer status and configuration without having to worry
>about reconcilling two different name spaces. Additionally since the OID
>decoding code is already in the printer, the implementation was easy and
>small -- no need to carry lots of string constants around for comparisons.
snip...
I see two approach:
1. The full decimal OID as you suggest that allows any OID to be passed
in any standard or private MIB.
2. A tailored set of shortened OIDs for the Printer MIB (as suggested
by Harry).
We could do both. Each have their advantages and disadvantages.
Here are some issues with each approach:
For approach 1, the values of the "requested-attributes" Operation attribute
would be keywords. Keywords have to start with letters, so I suggest the
prefix 'mib' for those that can reference any MIB.
For example, to retrieve the prtInputMediumName object for the 3nd input
tray if the hrDeviceIndex were, say, 20:
'mib-1.3.6.1.2.1.43.8.2.1.12.20.3'
Issue 1: How would an application know that the printer device was
hrDeviceIndex = 20 (assuming that it is a value 1 is not acceptable,
though it might work for many implementations)?
We could add an IPP Printer attribute: hr-device-index (1setOf integer(1:MAX))
which would be this value. The application would query to get the
hrDeviceIndex value that it would insert as the second to last arc in
most Printer MIB OIDs (last OID arc for the General Table). The 1setOf
in needed for the case where an IPP Printer object is representing
multiple devices as indicated in our Model document picture.
Issue 1a: Or provide GetNext semantics to find the device (see Issue 2 also)
Instead of adding a "hr-device-index" Printer attribute, if GetNexte semantics
were used, instead of Get semantics, then the requester could request
the first item in the Printer MIB as:
'mib-1.3.6.1.2.1.43.5.1.1'
which would return the prtGeneralConfigChanges (column 1) with the
hrDeviceIndex (20 in this example) tacked on the end:
'mib-1.3.6.1.2.1.43.5.1.1.1.20' = n
Then the application would know what hrDeviceIndex to put into all future
requests to that device. (Alternatively, the application could attempt
to read the hr MIB to find the hrDeviceIndex for the printer device, but
that seems pretty hard.
Issue 2: How would an application read the alert table entries, since the
OID index is steadily increasing as the Printer generates alerts?
(The Alert Group is 18 and the prtAlertTime object is 9, and, say, the 500th
alert)
'mib-1.3.6.1.2.1.43.18.1.1.9.20.500
Issue 2a: Use GetNext semantics, instead of Get?
One solution would be to use the SNMP GetNext semantics, so that the requester
could have supplied "requested-attributes" with:
'mib-1.3.6.1.2.1.43.18.1.1.9.20.1' (or 'mib-1.3.6.1.2.1.43.18.1.1.9.20')
and get back:
'mib-1.3.6.1.2.1.43.18.1.1.9.20.500 = xxx in the response
Issue 2b: Provide GetBulk semantics, instead of GetNext?
It would be even more convenient if there was an input Operation attribute
that said how many to return starting with the first one that exists, i.e.,
the SNMPv2 GetBulk semantics. GetBulk can be easily implemented by an IPP
Printer with an SNMPv1 agent, by doing the requested number of GetNext
operations and incrementing by 1 after each to the SNMPv1 agent.
Approach 2 is to have shorter attribute keywords for just the Printer MIB
of the form:
'prt-t-c'
where t is the decimal table/group number and c is the column number.
So for scheme 2, the values of the "requested-attributes" Operation attribute
would be keywords, like the prtInputMediumName (column 12) for the 2nd
input tray (table 8) if the hrDeviceIndex were, say, 20:
'prt-8-12'
instead of:
'mib-1.3.6.1.2.1.43.8.2.1.12.20.2'
Issue 3: How represent multiple devices?
Add a "device-names-supported" Printer attribute which is the name(s)
of the device(s) supported. An input Operation parameter is the name of
the device (needed only if the IPP Printer object supports more than one
device.
Issue 4: How get prt table row instances?
Issue 4a: Return all row instances as a multi-value attribute?
To simplify, the return would be a multi-value attribute where each value
corresponds to each table row. So that the results would be the
media names for each of the input trays, no matter how many there were.
For the General table (group 5), in order to get the (new)
prtGeneralPrinterName object (column 16), the requester would provide:
'prt-5-16'
instead of:
'mib-1.3.6.1.2.1.43.5.1.1.16.20'
For the alerts (group 18), the requester would provide:
'prt-18-9'
to get the prtAlertTime values (column 9) for all alerts in the table as
a single multi-valued attribute, instead of:
requesting, say, the next 10 values using GetBulk semantics:
'mib-1.3.6.1.2.1.43.18.1.1.9.20.1
Issue 4b: Or have the GetBulk semantics, instead of returning
a multi-valued attribute?
With approach 2, we could use the GetBulk semantics, instead of always
returning all instances as a multi-valued attribute. That gives the
requester more control of which instances to get and how many. Doing
GetBulk also fits in nicely with SNMP semantics.
Using GetBulk for both approaches 1 and 2 makes the most sense if we have
both schemes.
Comments?
Tom