PMP Mail Archive: Re[2]: PMP> Novell Channel Type Info -Reply

Re[2]: PMP> Novell Channel Type Info -Reply

Bill Wagner (bwagner@digprod.com)
Wed, 16 Apr 1997 22:34:09 -0400

Scott,

1. Let me stress that I am being pragmatic, concerned with what stands
a good chance of being used rather that what is aesthetically
comforting.

2. In proposed change to PServer channel information, I did not change
the NDS keywords. I agree that multiple NDS queues reasonably are
represented by multiple channels, especially considering that it is
unlikely that there will be many of them.

3. Jay's original request was for the IP port number used for simple
TCP/IP channels. This was later expanded to keys necessary to allow
the print data path to be found. Despite forays into Applications MIBs
etc. I don't think that it was even intended that the printer MIB
provide all of the necessray information. Just enough so that, if
there were an application that wanted to locate a print data path, it
could. I know of no one planning to do this on a general basis for any
range of different channel types.

The Channel Information object was created for this purpose. It is
still open what keywords are supported; indeed, I believe that there
is some flexibility in keywords so that an IP PServer, for example,
could be addressed. Not a perfect solution. Perhaps something of a
Band-Aid. But I don't think it is clear that it will not work where it
is indeed necessary.


4. The question of discovery over IP is troublesome, with IPP going to
LDAP. I don't think that the printer MIB, at this point, could
reasonably develop an IP replacement for IPX SAP's. However, once
something is developed, perhaps the printer MIB will accommodate some
key to it in the channel information object?


5. The proposed change to the bindery based queue is pragmatic. I
don't have the details here, but there is any amount of workstation
software around that will find all PServers on a network using SAP's.
I have seem this work on networks with in excess of 4000 file servers.
I so not deny that there may be advantages to listing all file
servers; but you must agree that it is not necessary. So, I maintain
that:
a. there is an adequate solution without the multiple channels
listed
b. the problem relates to an 'old' print service

c. problems of communicating this information to the controller, of
maintaining multiple channel listings, and of changing the information
when file servers drop out (as they do) does not warrant the
unnecessary advantages.

Bill Wagner

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Novell Channel Type Info -Reply
Author: Scott Isaacson <Scott_Isaacson@novell.com> at Internet
Date: 4/16/97 7:33 PM

Bill,

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