Subject: PMP> New IETF Draft review

From: [email-masked] (Bill Wagner)
Date: Fri, 4 Apr 1997 03:03:01 -0500

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.
     
     Bill Wagner, DPI

---

From: [email-masked]
Date: Fri, 04 Apr 1997 14:34:13 PST

>    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
::  [email-masked] Portland, Oregon        fax 503-228-5662