Channels, Interfaces and Loose ends -Reply

Channels, Interfaces and Loose ends -Reply

Channels, Interfaces and Loose ends -Reply

Scott A. Isaacson Scott_Isaacson at
Mon Oct 21 18:42:35 EDT 1996


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

>>> Bill Wagner <bwagner at> 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> 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

You also wrote:
>>> Bill Wagner <bwagner at> 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
     should drop non network channels... that would simplify channels 
     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> 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

Since I find this confusing, I must "get" the picture.

Scott I.

More information about the Pwg mailing list