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 <jkm@underscore.com> 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.