I believe there are also embedded web servers that access (in a different way
than OIDs), printer MIB objects. Very few of these servers allow you to
"update"
these objects, usually they just display them. And if these web servers do
allow
users to update these objects, and do NOT allow a way to secure updating
these
objects, then this system is broken. Especially if these are high-end
departmental or enterprise printing facilities.
At the end of Peter's message is the list of things he is concerned about.
I think there are alot of other design issues that will have to be
addressed. It seems to me that there were decisions made during the design
of the Printer MIB, and its links to the host MIB, that presumed that the
objects would be retrieved using SNMP mechanisms, and we might have relied
on the fact that indices and other information are automatically returned
by SNMP PDUs.
My overall opinion is that its not entirely necessary to have one protocol
(IPP) be good at everything, its just going to get very complex (and huge)
to implement. We should use the best tool for the job and there are
semantic and operational aspects of the IPP model that do not translate
well (IMHO) to a robust device management protocol.
Randy
At 04:54 AM 4/27/98 -0700, Zehler, Peter wrote:
>All,
> I do not share most of Randy's concerns. I see the printer MIB as an
>agreed upon standard way of representing a printer. I believe it is rich
>enough to satisfy IPP's "host to device" needs. I am not concerned about
>circumventing standard SNMP security mechanisms. There are currently
>embedded web servers that also update the MIB objects. I see three views
>into the same data objects. The three are SNMP, Web Access and IPP. The
>implementers must insure that the model is not corrupted by multiple access
>methods. I see no difference between the "multiple view" scenario and
>multiple SNMP managers manipulating the printer object. I am also not
>concerned by the ability for IPP to carry SNMP syntax. As far as I know
>there is nothing in SMI that cannot be represented in IPP.
> The areas that I do have some concerns in is the definition of the
>req/resp for the printer MIB access operations. The other feature I am
>concerned with is the overlap of notification methods in SNMP and IPP. I
>have not yet seen if the overlap needs to be addressed. If the overlap
>needs to be addressed how will it be resolved?
>Pete
>
> -----Original Message-----
> From: Turner, Randy [SMTP:rturner@sharplabs.com]
> Sent: Friday, April 24, 1998 11:42 PM
> To: 'Kris Schoff'; 'SISAACSON@novell.com'; 'ipp@pwg.org'
> Subject: RE: IPP> ADM - Reminder about job openings and home
>work assignme nts
>
>
> I have some reservations about using the concept of using IPP to
> encapsulate OID to access SNMP MIB objects. I think we should be
>very
> careful about the scope and requirements for such a capability. The
> biggest problem I guess I have with this is that we MUST make sure
>that
> IPP is not used to circumvent or hack access to manageable objects
>which
> might otherwise be secured by standard SNMP security methods. There
>are
> other considerations such as the definition of request and response
> attributes, and whether or not we have a rich enough value syntax to
> describe current SMI data objects.
> I could go on but its Friday night and I'm getting dirty looks...;)
>
> Randy
>
> > -----Original Message-----
> > From: Kris Schoff [SMTP:kschoff@hpb18423.boi.hp.com]
> > Sent: Friday, April 24, 1998 4:41 PM
> > To: 'SISAACSON@novell.com'; 'ipp@pwg.org'
> > Subject: RE: IPP> ADM - Reminder about job openings and home
>work
> > assignme nts
> >
> > Scott,
> >
> > I would be very interested in tunneling SNMP OID's through IPP for
> > printer management. It seems like a very reasonable concept to do
>and
> > it could allow for the enabling of millions of printers in
>existence
> > today. I'd like to see you continue your effort within IPP.
> >
> > I am still a proponent that IPP was intended to become a
>universal,
> > catch-all printing protocol - which is why I am not on the SDP
>mailing
> > list. By definition of "Server-to-Device", it would seem as if
>the
> > client is already being left out. I could have sworn that some
>people
> > within the IPP WG were trying to limit the number of protocols
>that
> > needed to be implemented....
> >
> > Kris Schoff
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com]
> > > Sent: Wednesday, April 22, 1998 1:58 PM
> > > To: kschoff@hpb18423.boi.hp.com
> > > Subject: Re: IPP> ADM - Reminder about job openings and home
>work
> > > assignments
> > >
> > > Message-Id: <s53df244.076@novell.com>
> > > Date: Wed, 22 Apr 1998 13:35:23 -0600
> > > Subject:
> > > Sender:
> > >
> >
>Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f#
> > > com@hpbs1480
> > > FROM:
> > >
> >
>Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f#
> > > com@hpbs1480
> > > TO: cmanros@cp10.es.xerox.com,
> > > ipp@pwg.org
> > > Encoding: 17 text
> > >
> > >
> > > >>> Carl-Uno Manros <cmanros@cp10.es.xerox.com> 04/22 11:23 AM
>>>>
> > > > (snip)
> > > >HOME WORK ASSIGNMENTS
> > > >
> > > > (snip)
> > > >
> > > > 4) Revised draft on getting MIB info over IPP - Uncertain
>whether
> > > this is
> > > > still part of IPP or should be part of the SDP discussion?
>(Scott
> > > I.)
> > >
> > > Unless this is still part of an IPP discussion, then I am not
> > > interested in
> > > participating. I plan to rev the document and post and an I-D
> > (non-WG
> > > draft if necessary), but I would like for it to be a WG draft.
> > >
> > > Scott
> > >
>