Bill,
Sorry to miss the teleconference.
You wrote:
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************
>>> Bill Wagner <bwagner at digprod.com> 10/20/96 11:54pm >>>
The teleconference brought up some interesting points. Of course, Jay is
correct in that the MIB II system and the printer need not be the same.
One can think up special cases from multi-printer server boxes to
workstation-attached printers where the node is not unique to the
printer. However, these seem to me to be unlikely candidates to be
supporting the printer MIB, ...
>>> Bill Wagner <bwagner at digprod.com> 10/20/96 11:54pm >>>
Maybe I am biased since Novell has not ever been in the network printer
market (printers with NICs as true nodes on the network) , but I feel that
the following solutions are not just special cases:
- workstation attached shared printer
- server attached shared printer
- host attached shared printer
- print server (hardware box) attached shared printer
Special case implies that there there are relatively few instances. From
my point of view, there seems to be quite of few of these configurations.
I hope that there are fewer and fewer as the years go by, but I do feel
that it is an important enough configuration to worry about and not
ignore.
You also wrote:
>>> Bill Wagner <bwagner at digprod.com> 10/20/96 11:54pm >>>
6. But these interfaces are keyed to the channels...or should we
simply not key non-network interfaces to their channels. Or perhaps
we
should drop non network channels... that would simplify channels
nicely.
One could maintain that, for network administration, we need not care
about non-network connections. But if that is the decision, I think it
should be more clearly identified in the rfc. On the other hand, if
all possible interfaces to the printer are to be identified, that also
should be made clear; and if that is the case, then the problem with
rfc1213 dealing only with network interface should be addressed.
>>> Bill Wagner <bwagner at digprod.com> 10/20/96 11:54pm >>>
I agree with this completely. These non-network interfaces are key to
the channels as it is becoming, not how it channels should be. I support
the idea of dropping non-network channels and changing any wording in
the RFC to show that the Printer MIB is for Network Administration only.
The Printer MIB should not be used for determining how a printer is or
could be connected via non-network interfaces. These are used to
connect the printer to some "host" with a NIC card that supports some
non-network physical interface (server, print server external box, client
workstation, etc.) which then implements the MIB and shows the
channel as being the channel in through the network to it rather than the
non-network interface on the back end to the printer.
In the NDPS case, we have chosen to describe only one "channel" for
these non-network attached printers. The channel is the NDPS interface
through NDPS software on the server/client which makes them a
shareable, network printer. We are not interested in the
physical-connected ports and how they are being used for a given
printer that happens to be accessed through the NDPS channel on the
server/client.
Since I find this confusing, I must "get" the picture.
Scott I.