You ask some very interesting questions. And thanks for all the great info
about NetWare! I'd like to try to respond to some of your questions, trying
to be as brief as possible:
> General Question:
> There is a wide mix of Channel types defined: some relatively high in a
> layered protocol stack (application protocols) and some lower
> (transports) and some even lower (hardware interfaces). What if some
> of the higher layer application protocols can run over multiple transports?
> Do we need to put into each channel type info which transport it is
> currently configured to run over or which transports it may run over or
> do we not define which transports are used? It is easy for some (FTP
> will run over TCP), but for some of the Netware channel types (PServer
> and NDPS) they will run over TCP or SPX. What do we include in the
> channel info for these channel types?
You know, this topic (like so many others) has arisen from time to time.
I recall a discussion about a year ago in which this topic was discussed
in fairly rabid detail. And, like so many other issues, no real consensus
was resolved.
So now what do we do? Perhaps the top-level choices are:
1. Ignore the problem (ie, the status quo)
2. Fix the problem now
If we chose to fix the problem, then at least these choices are possible:
1. Add another element to the Channel Entry definition
Pro: Probably the most complete and elegant solution
Con: This would be a very serious change to the MIB definition,
and we would have to determine/define how to represent the
the possible set of transport protocols (enums, strings, etc)
2. Define several more Channel Type values that "mirror" the existing
set, where the new ones explicitly encode the relevant transport
protocol; the existing values remain the same, but additional
description text would explicitly state the transport used.
For example, "chNetwarePServer" would be changed so that its
description would explicitly state the binding to IPX/SPX, and
a new Channel Type would be named, say, "chNetwarePServer-IP"
or something like that.
Pro: Least impact on the existing MIB (and existing implementations)
Con: Lots of duplication that would be annoying in the worst case
IMHO, this issue needs to be discussed ASAP by the group, even if the net
result is "retain the status quo". Hopefully we can resolve this on the
mailing list prior to the next scheduled PMP telecon.
> 1. Page 37
> Editorial: The use of the term PServer has several changes in
> capitalization: Pserver, PServer. Make them all consistent. Suggest
> PServer
I'm a bit surprised you don't insist on "PSERVER", as that string format
seems so prevalent in NetWare documention. But hey, you're representing
Novell, so what you say goes... ;-)
> 2. Page 37
> Question:
> If the channel type is chPortTCP(37), the only parameter identified for
> channel info is "port". Is it assumed that the IP address is already
> known? Also for all of the other TCP/IP based channels (FTP, HTTP,
> etc.), is it assumed that the IP address is already known because you
> are using SNMP to talk to the Printer? What if you are using SNMP over
> IPX to get the at the MIB, is there somewhere else to ask it its IP address?
I have always assumed that the IP address (or network address) can be
resolved via the related Interface index value defined as part of the
Channel Entry definition. (Is this a naive assumption?)
> I ask this because if the channel type is this one, chNetwareRPrinter(9),
> the transport protocol used is SPX. Do you also want to know the full
> IPX/SPX address for this node, i.e., net:node:socket?
> Should we add a paramenter called "Address" or is the IPX/SPX address
> obtainable from somewhere else?
Good question. One of the areas of general consensus for the Channel Table
in general (as I recall) is that this information serves two primary
purposes:
1. To provide a way to enable/disable a particular print service
(oops, I mean "Channel" ;-), as that capability is commonly available
via the front panels of so many printers; and, a top-level goal of
the Printer MIB itself is to provide as much functionality via SNMP
as would be available via the front panel.
2. To provide a way for a print client to "bootstrap" itself to be able
to communicate to the printer to submit a print job.
Regarding #2 above, a further consensus was reached in which the group
acknowledged that it is both unreasonable and undesirable to attempt to
provide absolutely ALL possible information in the Printer MIB for any
given Channel Type. Instead, only the most rudimentary info should be
made available that would allow a print client to identify whether it
would be able to communicate with the printer using a specific Channel
Types for which the print client was designed to handle.
As a bonafide "professional print driver developer", I was particularly
pleased to see the group reach such a consensus where simplicity was
the rule of the day. 8-)
> 4. Page 108
> The following line:
> -- Netware Print Server SPX/IPX based channel
> should probably be:
> -- Netware Print Server NCP based channel
> See comments below about NCP over IPX and IP.
I realize that this snippet is from the introductory text, and not
from part of an object definition, so this might not be that big of
a deal. However, might you be suggesting that "NCP" would be one
of the proposed "transport" values for a Channel Entry?
If so, then here is where things can get really sticky. It's one thing
for us to consider a new Channel Entry element describing the transport.
But to "factor out" differences and say "NCP" would make things far less
precise, and therefore (IMHO) far less useful.
For example, say I write a print client that can talk PSERVER, but that
the print client runs on a host that only supports IP. If the print client
then queries the printer (via SNMP) to determine whether the printer supports
the PSERVER protocol, how can I tell whether the printer supports PSERVER
over IP (and not the usual SPX)?
Again, it may not be that you're suggesting "NCP" as a potential "transport"
protocol value, but this situation is worthy of understanding the potential
pitfalls of taking this approach.
In either case, I believe you stated earlier that should we pursue adding
"transport" as a Channel Entry element, then only the "lowest" type of
transport protocol should be used (eg, "IP", "IPX", etc). This is a
good thing, IMHO.
> 5. Page 107
> Page 107 states:
> "-- The Print Job Delivery Channel table describes the
> -- capabilities of the printer and not what is currently being
> -- performed by the printer"
> In the next release of IntranetWare, NCPs will be able to run over both IP
> and IPX. When that is the case, shouldn't the channel info also include
> the possible IP address as well as the IPX address or just the fact that it
> can run over IP or IPX? This relates to my earlier questions about where
> the IP and IPX addresses are retrieved: are they just known or ar the
> queried in a MIB someplace?
>
> Do we need to add something like:
> -- Keyword: "Protocol"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Multiple
> -- Description: Either "IP" or "IPX" or both
I would be in favor of adding this new element, but this is going to
require a serious round of consensus from the group at large, given
the Pros and Cons listed earlier in this message.
> 6. Page 41
> Will anyone ever populate a channel type of just SPX as compared to
> NPrinter or PServer? Why do we have chPortSPX(41) separated out?
> Should it be part of chNetwareNPrinter and chNetwarePServer?
Boy, am I glad you asked these questions!
On one hand, it should be obvious that one could develop a mechanism
to submit print jobs using a simple (raw) stream using SPX in the
exact same manner as the current "chPortTCP" Channel Type, right?
On the other hand, does such a mechanism currently exist?
If no such implementation exists, then do we want to maintain definitions
in the Printer MIB of what "could be implemented" versus what "is currently
implemented"? This is pretty much a philosophical issue that will probably
end up being aligned with the "Big/Fat vs. Small/Light" argument for
specifications in general.
Is there anyone out there in PWG-land willing to stand up and declare
that he/she requires this Channel Type definition?
> 7. Page 42
> NDPS can run over TCP or SPX. Do I need to add a parameter to chNDPS
> to describe which transports are possible or is that the purpose of this
> channel info?
This appears to be the same issue described in a couple of your other
issues above, right?
Again, Scott, thanks for asking so many excellent questions. Hopefully
we'll get some real discussion rolling on the mailing list now.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------