Subject: IPP> Using OID access with IPP/SDP

From: Randy Turner <[email-masked]>
Date: Sun, 26 Apr 1998 22:33:51 -0700

Let me attempt to clarify my position on this effort to provide another
mechanism for accessing MIB data from IPP/SDP. Philosophically, I would
like to see only SNMP used to access MIB data through OID mechanisms.
Technically, I understand that we can also implement tunnels or "backdoors"
in other protocols that attempt to "hack" into the MIB data stream and take
advantage of the OID naming scopes that are used currently to expose
existing MIB data.

If we were to define another naming scope, say "attributes", that reflected
object-for-object, the data objects that are in our MIBs, then I would be
less opposed. To some degree we have already started doing this that in the
existing IPP 1.0 printer object attribute set.

The fact that we are switching naming scopes (printer-attributes over to
SNMP OIDs) in midstream seems a little odd, and emphasizes the technical
"shortcut" we are attempting, thus confusing the IPP model. I would much
prefer us to extend IPP the way we originally intended, through the use of
additional printer attributes.

I think I will always have reservations about doing this, but if the PWG
decides they want to do this anyway, then I would urge the PWG to include
text in whatever document is generated that says something like  "If this
mechanism is implemented co-resident with an existing SNMP agent, then the
mechanism must support, at a minimum, the minimum level of security that
the SNMP agent provides for the same objects". This should be a mandatory
compliance statement, and not just a strongly worded suggestion. This would
give future network administrators at least some comfort that there printer
MIB data cannot be "hacked".

---

From: [email-masked]
Date: Mon, 27 Apr 1998 12:48:23 -0400

Randy Turner said

>existing IPP 1.0 printer object attribute set.

Randy, I can't believe you said this.  Is this security by obscurity?  OK,
rather than call them OIDs will pick random series of numbers separated
by periods (that happen to match the MIB) to identify the attributes we
want and call them PORN - "Printer Object Random Numbers"

Anyone object?
**********************************************
* 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: "Turner, Randy" <[email-masked]>
Date: Mon, 27 Apr 1998 10:02:15 -0700

Pick whatever naming scope you wish, just pick ONE.

We already have printer attributes, why not stick with em'.

Randy

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Monday, April 27, 1998 9:48 AM
	To:	[email-masked]
	Cc:	[email-masked]
	Subject:	Re: IPP> Using OID access with IPP/SDP

	Randy Turner said

	>If we were to define another naming scope, say "attributes",
that
	reflected
	>less opposed. To some degree we have already started doing this
that in
	the
	>existing IPP 1.0 printer object attribute set.

	Randy, I can't believe you said this.  Is this security by
obscurity?  OK,
	rather than call them OIDs will pick random series of numbers
separated
	by periods (that happen to match the MIB) to identify the
attributes we
	want and call them PORN - "Printer Object Random Numbers"

	Anyone object?

---

From: Harry Lewis <[email-masked]>
Date: Mon, 27 Apr 1998 13:54:07 -0400

Randy said...

      >that reflected object-for-object, the data objects that are
      >in our MIBs, then I would be less opposed. To some degree
      >we have already started doing this in the

The main concern I have with using string named attributes rather than the
distinguishing part of the Printer MIB OID is the
processing required to differentiate strings vs. the (relatively short) OID
stubs.

Harry Lewis - IBM Printing Systems

---

From: "Scott Isaacson" <[email-masked]>
Date: Mon, 27 Apr 1998 12:47:25 -0600

My comments preceded by SAI>

>>> Randy Turner <[email-masked]> 04/26 11:33 PM >>>
>

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).  As Harry L.
SAI> pointed out, I do not see MIB SETs in IPP, so I don't see a "hack"
SAI> or a "back door".  I see a simple IPP front door (with a video
SAI> surveillance camera) just to see what the printer looks like.  We
SAI> can only WIN of the IPP model of the Printer is the same as
SAI> SNMP Printer MIB model of the Printer!

>additional printer attributes.

SAI> I see both sides of this argument: we already picked named attributes
SAI> for IPP, but in this case we are moving to querying already named
SAI> MIB objects (the name is the OID) - so we are just stringifying that name.
SAI> Seems consistent.

> MIB data cannot be "hacked".

SAI> I agree with this compliance statement. 
SAI> If we allow access through two doors to view whats in 
SAI> the shop, we should have the two security guards at each door working
SAI> off the same policy sheet that was passed out at the early morning staff
SAI> meeting (i.e., if the sheet says "Don't let Scott Isaacson in here anymore, 
SAI> he causes problems" then neither guard should allow Scott in either door.)

---

From: "Caruso, Angelo " <[email-masked]>
Date: Mon, 27 Apr 1998 07:49:03 PDT

Perhaps someone would please enlighten me as to why we need to build Printer
MIB OID access into IPP. I thought the intent was to extend the IPP
attribute list to eventually cover all the printer MIB stuff. Why is this so
difficult?

As for security, I guess I agree that IPP should afford the user the same
level of security they could achieve using SNMP, but I think this may be a
lot of unnecessary hand wringing. There is little that can be "hacked" in
the Printer MIB since most of it is read-only. And the little bit that is
writable is likely to be far less interesting to a hacker than the credit
card account numbers flying over the wire this very minute.

Thanks,
Angelo

---

From: Harry Lewis <[email-masked]>
Date: Mon, 27 Apr 1998 19:48:36 -0400

Angelo asked -

>Perhaps someone would please enlighten me as to why we need to build >Printer
MIB OID access into IPP. I thought the intent was to extend >the IPP attribute
list to eventually cover all the printer MIB stuff. >Why is this so difficult?

If we would accept SNMP (v3 perhaps) as the secondary channel between Server
and Device we wouldn't have to map OID's to IPP at all. The main convincing
argument (aside from "don't like it") I've heard against this is the desire to
have one solution for network and local attachments. Tail wagging dog, but
still, a valid argument.

Once we get to designing a single protocol for submission and monitoring, we
wish to maintain use of the MIB datastructures which are already in the device
for management purposes. Thus, we might want to extend the IPP attribute list
to cover all the printer MIB objects, as you suggest. However, it has been
observed that every printer MIB OID already has a unique, fairly terse "OID
stub" (the unique part, not the fully qualified OID). Since a lot of effort
goes into efficient use of controller MIPs, why make the device parse the
longer IPP attribute strings when any IPP application can do the matching for
human consumption?

---

From: "Scott Isaacson" <[email-masked]>
Date: Tue, 28 Apr 1998 08:55:10 -0600

Angelo,

>>> "Caruso, Angelo " <[email-masked]> 04/27 8:49 AM >>>

In the original "Sub-Units" proposal that I presented in Portland, I showed a
mapping from MIB OIDs to IPP attribute names.  It not really a complete mapping, 
but examples and some  rules of how to complete the mapping.  
This seemed simple enough to me.  This is the direction that I thought we were
going.

Some of the comments on the proposal during the meeting were:

1. Since an implementation of IPP with Printer MIB sub-unit support will most likely
be co-resident with a Printer MIB agent which already names things with OIDs,
it would be a waste of resources to require that implementation and agent
to translate back and forth between strings and OIDs.  So, in order to 
"extend the IPP attribute list to eventually cover all the printer MIB stuff."  the
thought process was to name the new attributes by their stringified OIDs
rather than some arbtrary symbolic name

2. The discussion seems to be focused on now "how hard can it be" but "is it
necessary" since we already have SNMP.

3. If we stick with arbitrary new strings for attributes, it might  be harder to get at
other MIBs using the same mechanism without a full mapping document.  For example,
the Finishing MIB.  If we just go with stringified OIDs we can easily extend that to any
MIB object OID without having to show a mapping to the IPP attribute name.

These are just the thoughts behind the disucsisons that I have heard.

Scott

---

From: "Caruso, Angelo " <[email-masked]>
Date: Tue, 28 Apr 1998 09:03:26 PDT

Scott,

This is an excellent clarification for those, like myself, who have been
trying to follow the discussion with minimal time invested. Thanks.

Using "stringified OIDs" has at least one additional benefit that I can
think of: it forces the implementation to maintain EXACTLY the same
semantics for the attributes. Thus, there can be no temptation to fix or
extend the semantics of those attributes that may be less than perfect in
their current form.

Thanks,
Angelo

-----Original Message-----
From:	Scott Isaacson [SMTP:[email-masked]]
Sent:	Tuesday, April 28, 1998 10:55 AM
To:	[email-masked]; [email-masked]
Subject:	Re: RE: IPP> Using OID access with IPP/SDP

Angelo,

>attribute list to eventually cover all the printer MIB stuff. Why is this
so

In the original "Sub-Units" proposal that I presented in Portland, I showed
a
mapping from MIB OIDs to IPP attribute names.  It not really a complete
mapping, 
but examples and some  rules of how to complete the mapping.  
This seemed simple enough to me.  This is the direction that I thought we
were
going.

1. Since an implementation of IPP with Printer MIB sub-unit support will
most likely
be co-resident with a Printer MIB agent which already names things with
OIDs,
it would be a waste of resources to require that implementation and agent
to translate back and forth between strings and OIDs.  So, in order to 
"extend the IPP attribute list to eventually cover all the printer MIB
stuff."  the
thought process was to name the new attributes by their stringified OIDs
rather than some arbtrary symbolic name

3. If we stick with arbitrary new strings for attributes, it might  be
harder to get at
other MIBs using the same mechanism without a full mapping document.  For
example,
the Finishing MIB.  If we just go with stringified OIDs we can easily extend
that to any
MIB object OID without having to show a mapping to the IPP attribute name.

Scott