Subject: Re: PMP> Novell Channel Type Info -Reply

From: Scott Isaacson <[email-masked]>
Date: Wed, 16 Apr 1997 18:25:36 -0600

Ira, Bill, Jay,

Thanks for the complete and prompt responses.  I am still digesting all of
your comments, but one thing Ira said stuck out immediately:

<IEM> Does NDPS only operate over one 'flavor' of RPC?  Probably a
<IEM>  dumb question, but perhaps relevant.  Certainly some other ISO
<IEM>  DPA-based systems operate over more than one 'flavor' of RPC
<IEM>  (eg, ONC RPC vs DCE RPC).  Might also need to be made explicit.

Oops, I ignored this entire RPC layer in my earlier comments.  Thanks for
catching it.  NDPS only currently runs over ONC RPC, but we have plans
for others.  So yes, in a perfect world this layer should be made explicit
as well, however I doubt it for the Printer MIB Channel Table.

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: [email-masked]
W: http://www.novell.com
************************************************************

---

From: Scott Isaacson <[email-masked]>
Date: Wed, 16 Apr 1997 19:01:55 -0600

Jay,

Thanks for the well thought out response.  I guess these years of "rabid"
discussion have been useful at least in helping us remember all of the
unsolved issues.

>>> JK Martin <[email-masked]> 04/16/97 02:38pm >>>
> 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

My vote is to continue to ignore the problem whatever we do seems to
never be enought.  However if we do "fix" the problem, then my votes
are below for the options you describe:

>  1.  Add another element to the Channel Entry definition

No

>  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.

No

>  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.

Number 2 would be hard to do if the printer only ran over IPX and the
client only ran over IP and the Printer's channel did not specify which?  
Doesn't really matter anyway, since if the client can do it or the printer
can't support it, the client ain't printing anyhow where the channel entry 
had the info or not.

>  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?

The suggestion is that NCP is like an RPC mechanism, not a "transport"
mechanism.  To date, NCP has only run over IPX.  NCP will now run over
IP.

> 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)?

This is the question!

> 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.

This sounds like a good solution, but still probably not sufficient. 
However since maybe it does solve MANY scenarios.  I voted NO earlier
in this message, maybe I should change my vote here??...

>  Is there anyone out there in PWG-land willing to stand up and declare
>  that he/she requires this Channel Type definition?

Bill W claims there are.

> This appears to be the same issue described in a couple of your other
> issues above, right?

Yes same issue.

---

From: Scott Isaacson <[email-masked]>
Date: Wed, 16 Apr 1997 19:33:35 -0600

Bill,

My comments on yours:

>>> Bill Wagner <[email-masked]> 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

---

From: JK Martin <[email-masked]>
Date: Thu, 17 Apr 1997 11:14:13 -0400 (EDT)

Scott,

You've raised a very critical issue with respect to specifying the
underlying transport associated with the print service (aka, Channel).

It would seem pretty useless to only specify (IP) when the service
requires, say, ONC RPC, as opposed to, say, DCE RPC.  This leads me
to suggest that if service requires only a simple TCP stream connection
(ala Port 9100), then we should define a "transport" called something
like "Raw" to raise the abstraction and allow RPC-like mechanisms to
share the same conceptual space as raw stream connections.

Comments on this idea are greatly appreciated.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: [email-masked] (Bill Wagner)
Date: Thu, 17 Apr 1997 11:35:01 -0400

Jay, 
     
     It would very much help to understand the specific purpose of a 
     suggestion such as you have made. At this point in the printer MIB 
     development, it is not a question of whether more information is or 
     could be useful; is it necessary?
     
     Bill Wagner, DPI/Osicom

______________________________ Reply Separator _________________________________
Subject: Re:  PMP> Novell Channel Type Info -Reply
Author:  JK Martin <[email-masked]> at Internet
Date:    4/17/97 11:14 AM

Scott,

        ...jay

---

From: JK Martin <[email-masked]>
Date: Thu, 17 Apr 1997 11:38:12 -0400 (EDT)

Bill,

I hope you're not thinking that I desire to add "academic" information
to the Printer MIB.  Most folks know me better than that, as I have
been fighting to reduce that kind of info in many of the PWG subgroups
over the last few years.

Is it necessary to be able to distinguish between ONC RPC and DCE RPC?
Yes, because a client is typically implemented to use one of those
RPC mechanisms, and it must be able to know whether the printer supports
the same mechanism.

If I have a client that is implemented to use ONC RPC, then simply saying
that the Channel supports "IP" doesn't give the client sufficient info.

Is this answer acceptable to you?

	...jay