PMP Mail Archive: RE: PMP> New IETF Draft review
RE: PMP> New IETF Draft review
David_Kellerman@nls.com
Fri, 04 Apr 1997 14:34:13 PST
Bill Wagner wrote:
> I had previously suggested that requiring separate channel listings
> for every bindery-based NetWare queue was cumbersome and of little
> use. I have seen no refutation of this.
>
> I wish to repeat this contention, this time stressing the difficulties
> versus the benefits.
>
> The chNetwarePServer(10), prtChannelInformation keywords currently
> include file server and queue. Bindery based print servers can service
> multiple queues on multiple fileservers. The suggestion is that a
> separate channel listing should be provided for every queue on every
> file server.
>
> 1.This might amount to 16 or more channel listings.
> 2.These queues are, in general, not identified in the print server but
> rather are on one or more file servers. They must be determined at
> power up time and might change while the unit is powered.
> 3.The information on queues serviced, in general, is retained in the
> NIC
> 4.A given queue may be serviced by more than one print server. That
> is, knowing the queue does not mean that you know how to print to the
> printer.
> 5. Bindery based queues are 'old' Novell technology, being replaced by
> NDS queues.
> 6. The Keywords for Rprinter are the name of the printserver and the
> printer. I suggest that the name of the print server and the printer
> are also adequate channel information for Pserver channels operating
> from bindery based queues.
>
> A printserver will normally service just one NDS queue, so NDS queue
> is a justifiable keyword; therefore I do not object to the keywords
> NDSTree and NDSQueue for pservers in an NDS environment. However, I
> wonder if perhaps Pservers servicing bindery queues and those
> servicing NDS queues should be considered different channel types.
Look, Netware protocols are definitely not my specialty, and I frankly
had to fight to keep my eyes from glazing over on the text above. ;-)
So I'm definitely not going to be of any help on the specifics here.
But here is a way of looking at the situation that may be useful.
Things to remember about the prtChannelInformation field:
1. It's part of a prtChannelTable entry, so it ought to be consistent
with the other fields in the entry. For example, whatever the
"channel" is, you ought to be able to fill in these other fields
with reasonable (multiplicity one) values:
prtChannelProtocolVersion
prtChannelCurrentJobCntlLangIndex
prtChannelDefaultPageDescLangIndex
prtChannelState
prtChannelIfIndex
prtChannelStatus
2. The information it provides is primarily for the benefit of an
application trying to "bootstrap" the use of the channel for
submitting jobs to the printer. Information that goes beyond this
bootstrap requirement shouldn't be included (get it in
protocol-specific fashion, not from the MIB).
So my question is: What are the plausible scenarios for an application
using the channel information for establishing communications with the
printer in the case of a chNetwarePServer(10) channel, and what
information do they need? Or are there any plausible scenarios? Is
anyone realistically going to develop an application that uses this
information? (Answer NO to either of the last two questions, and things
get a lot simpler!)
While I don't understand the chNetwarePServer(10) case in detail, I
wonder from your explanation whether it is reasonable to expect an
application to use the MIB information in bootstrapping a connection.
If it's not, I wouldn't worry too much about what we put in the
prtChannelInformation field -- maybe even just document that we don't
envision using the MIB to configure a connection over this type of
channel.
Hope this helps.
:: David Kellerman Northlake Software 503-228-3383
:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662