My comments on yours:
************************************************************
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@novell.com
W: http://www.novell.com
************************************************************
>>> Bill Wagner <bwagner@digprod.com> 04/16/97 04:08pm >>>
>
> 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.
Since one of the goals as stated by Jay was to allow a client to
"bootstrap" itself in order to now how to "submit a print" job, if the
channel does take on the "highest" flavor and there are options for
mupltiple layers underneath, what does the client do? Try them all?
> But does one really care about IPX/SPX
> addresses when one has the SAP names used?
In the past no, SAP name is sufficient. In the future, when NetWare is
running over IP then something other than SAP will be used. Since this
is a semi-future (is end of 1997 future?) thing maybe we just wait to fix it
later for IPX vs IP.
> 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.
There are advantages to having multiple entries in the channel table.
After having reviewed it back here with more knowledgable people than
I, we don't think what you proposed is sufficient.
Consider Novell 3.x
If I am a user in Server B's bindery and the Printer, P, is only configured
to be a PSERVER in Server A's bindery, it is not in Server B's bindery,
then I don't print. P has to be configured to be a PSERVER in Server B's
bindery as well for users in Server B's bindery. Which is why we have
NDS now in Netware 4.x rather than the 3.x server-centric bindery
solution.
Consider NetWare 4.x and IntranetWare
If the Printer is a PSERVER_1 in TREE_A and in PSERVER_2 TREE_B then
any authorized user in TREE_A or TREE_B can print to it. If the channel
table only contains PSERVER_1 there is no reference to which Tree it is
PSERVER_1 in. The Printer Number has really no relavance at all for the
end user trying to print a job. However, if the channel table contains
two entries
NDSTree=TREE_A, NDSPServer=PSERVER_1 and
NDSTree=TREE_B, NDSPServer=PSERVER_2
users (managers too) can look up in either tree if they have rights to the
tree to determine if they have rights to print to the queues being serviced
by those PServers. If one of the goals is "too supply enough info to use
some other mechanism to get all the real details" then NDSTree and
NDSPServer name are both required for each channel but Printer Number
is not.
With NetWare 4.x and IntranetWare, it is VERY likely that a Printer will be
in only one or two trees. In NetWare 3.x is was VERY likely that the
Printer would be in MANY Binderies thus requiring many channel table
entries, but each necessary for the users on those servers.
> 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.
Why not both? A channel table entry might be
NDSTree=TREE_A
NDSPServer=PS1.Org.CompanyX
Protocol=IP, IPX
Scott