Subject: RE: IPP> Using OID access with IPP/SDP

From: [email-masked]
Date: Mon, 27 Apr 1998 23:18:02 -0400

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.

Here's where I disagree:

Microsoft and many others need a single protocol to submit jobs and to
manage printers from a server, no matter how the printer is connected:

- Parallel
- Serial
- 1394
- IPX/SPX
- TCP/IP
- AppleTalk

So how do we reconcile the need to submit jobs and manage the printers
using one protocol and what Scott Isaacson said:

SAI> I see SNMP being used to MANAGE the printer.  I do not see using IPP
SAI> to MANAGE the printer.  I see IPP as being a protocol that an end user
SAI> uses (or an application on behalf of an end user) to query the printer
SAI> for characteristics and capabilities that help in requesting options
or
SAI> or formatting the job and then submitting the job and tracking and
SAI> simple management of that job (just query and cancel).

If everyone agrees that IPP should NOT be used to manage the printer, then
we cannot meet the requirement stated above using IPP.  That's why we
called it SDP (Server to Device Protocol) -- it's got to be fully usable
(read and write) so the server can fully understand and control the state
of the printer.

This really isn't hard.  If we are going to meet the requirements then we
have to either:

1) Extend IPP to allow job submission and full management
    and control
2) Document the straightforward mapping of IPP to IEEE Std 1284.1
    which already provides the management and controls features
    needed
3) Create something new.

Are there choices I'm missing?

**********************************************
* Don Wright                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: Randy Turner <[email-masked]>
Date: Mon, 27 Apr 1998 23:20:53 -0700

My comments are at the end of Don's last message below...

R.

>    which already provides the management and controls features

I would add two other possible options...others on the DL are welcome to
chime in with their own options.

4) Do nothing (for now). Deploy IPP 1.0 and let real world requirements
start accumulating. I really prefer this option, since I think we are
REALLY jumping the gun with this effort. With recent comments on the DL, I
think its very important that we concentrate on getting IPP 1.0 "out the
door" and deployed. We shouldn't appear to be splintering our focus. I do
think we need to consider notifications for IPP, but beyond that I would
say any presumptions on our part about what else is "needed" by customers
is very premature.

5) Consider new transport mappings for IPP, possibly for interfaces such as
1284,1394, USB, and others for which IP is not yet ubiquitous.

Randy

---

From: Tom Hastings <[email-masked]>
Date: Wed, 29 Apr 1998 00:11:27 PDT

Here are some alternatives to providing "stringified" OID access to
MIBs.  I'd like to discuss these at the Wednesday, 4/29, IPP telecon.

>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