Scott,
Since this is an area in which I have some interest, I will provide
what I understand to be answers consistent with what PMP has done. I
cordially invite different opinions on what the consensus is, or what
it should be.
1. No objection
2. Typically, the channel refers to the service or the 'highest' level
protocol involved in delivering the print data to the printer.
Therefore, chPortTCP(37) refers to a dumb TCP/IP connection of some
undefined service on some host, to the interpreter. That is, there is
no 'print service involved. Same thing for local ports such as serial,
centronics and 1284.
If TCP/IP is used for IPP for example, the channel would be IPP. If
IEEE 1284.1 is used over IEEE1284, the channel would be IEEE1284.1.
Etc.
Each channel is correlated with the interface table in MIB-2, with the
prtChannelIfIndex pointing to the particular listing in the MIB-2
interface table that supports the channel. The Interface table has all
the good stuff like physical address. It is also keyed to the other
groups in MIB-2, including the IP group which includes the IP address
and more.
Unfortunately, the integrity of this reference is not insured, since
the relationship between the MIB-2 "device" and the printer is not
well defined. Further, for unknown reasons, the printer MIB only
requires the Systems group (which is useless with respect to a
printer) and the interfaces group to be supported. Most printer
implementations do support the applicable other groups of MIB-2 so
that the IP is covered. But this is not required by the Printer MIB.
Yes, there is a hole with respect to IPX/SPX as well as all other non
IP protocols. Some implementations have this filled in proprietary
MIBS. Conceivably, the Netware MIB could be implemented, but I do not
know if anyone is doing that. But does one really care about IPX/SPX
addresses when one has the SAP names used?
3. My suggestion with respect to the PServer was to simplify the
handling of the channel table. A particular Print Server can be
defined on multiple file servers (16 for DPI Print servers). This
would require 16 channels. The purpose and advantage of this is
unclear. The cumbersomeness is obvious. The information I suggested
was the same as that used for RPrinter; if it is adequate for an
RPrinter channel, I suggest that it is adequate for a PServer channel.
4, 5. Following the general approach, the interfaces could be enhanced
so that more than one interface entry (e.g., IP, IPX) could be
provided over one physical interface (ethernet). If this were done, a
PServer channel running over IP would be correlated to an IP interface
in the MIB-2 interface table. A PServer channel running over IPX would
be correlated to an IPX interface.
Alternatively, these may be independent channels on the same
interface, differentiated by another keyword in the channel
information object. But the distinction must provide some useful
information, not just an academic follow through on the structure.
6. Yes. Some implementations use a serverless IPX/SPX connection,
with no print services in channel, to provide a connection between a
user and a printer over which a print job (and response) is
communicated.
7. As with Print Servers, if the distinction is important to a
management application, the IP/IPC distinction could be handled by an
additional keyword under channel information (and treating the two as
separate channels) or conceivably by defining different interfaces in
MIB-2. I agree that PMP should suggest a preferred way. An additional
keyword, such as Protocol seems fine to me. But a given channel cannot
be both.
Bill Wagner Osicom/DPI
______________________________ Reply Separator _________________________________
Subject: PMP> Novell Channel Type Info
Author: "Scott A. Isaacson" <Scott_Isaacson at novell.com> at Internet
Date: 4/16/97 12:57 PM
Some comments about the draft and channel type info. Sorry to raise
some questions about Channel Type and Channel Info again after all of
these nice quite, peaceful months with no comments...
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?
1. Page 37
Editorial: The use of the term PServer has several changes in
capitalization: Pserver, PServer. Make them all consistent. Suggest
PServer
chNetwareRPrinter(9), -- Novell, Inc.
-- prtChannelInformation keywords:
-- Print Server Name
-- Keyword: "PServer"
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The PServer's SAP name
--
-- Printer Number
-- Keyword: "Printer"
-- Syntax: Integer
-- Status: Mandatory
-- Multiplicity Single
-- Description: The printer number
-- There must be one PServer and one
-- Printer entry
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 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?
3. Page 37 an 38
There has been some discussion lately about this. Bill W. proposed
something recently that I have just now had a chance to take a
better look at and I have some revisions to his suggestion:
chNetwarePServer(10), -- Novell, Inc.
-- prtChannelInformation keywords:
-- Server Name
-- Keyword: "Server"
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity Single
-- Description: The name of the server for
-- which the PServer is defined
--
-- PServer
--
-- Name: "PServer"
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity Single
-- Description: The Bindery name of the
-- PServer
--
-- NDS Tree
--
-- Keyword: "NDSTree"
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity Multiple
-- Description: The NDS Tree name
--
-- PServer
--
-- Keyword: "NDSPServer"
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity Single
-- Description: The fully qualified name
-- of the PServer object in the tree
--
-- There must be exactly one Server and
-- one PServer entry or exactly one NDSTree
-- and one NDSPServer Entry
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.
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
--
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?
chPortSPX(41), -- Sequenced Packet Exchange (SPX)
-- socket.
-- Novell, Inc. Similar to TCP, a
-- bi-directional data pipe using
-- Novell SPX as a transport.
--
-- prtChannelInformation keywords:
--
-- Network Number
--
-- Keyword: "Net"
-- Syntax: HexString
-- Status: Mandatory
-- Multiplicity Single
-- Description: The network number
--
-- Node Number
--
-- Keyword: "Node"
-- Syntax: HexString
-- Status: Mandatory
-- Multiplicity Single
-- Description: The Node Number
--
-- Socket Number
--
-- Keyword: "Socket"
-- Syntax: HexString
-- Status: Mandatory
-- Multiplicity Single
-- Description: The SPX socket number
-- There must be exactly one "Net" and one
-- "Node" and one Socket entry. A HexString
-- and one "Socket" entry. A HexString is a
-- binary value represented as a string of
-- ASCII characters using hexadecimal
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?
That all for now,
Scott
************************************************************
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
************************************************************