revised prtChannelInformation MIB object

revised prtChannelInformation MIB object

revised prtChannelInformation MIB object

David_Kellerman at David_Kellerman at
Fri Oct 25 17:16:45 EDT 1996

Here are resoponses to some requests for clarification from Jay Martin. 

>> Here are proposed prtChannelInformation definitions for selected
>> PrtChannelType values: 
>>     chLPDServer(8),     -- ...
>>                         -- prtChannelInformation entries:
>>                         --   printer queue name
>>                         --     name: QUEUE, mandatory, single value
>>                         --     value is the ASCII queue name as
>>                         --     described in RFC 1179
> How do you propose specifying multiple LPD queues?  Should the implementor
> provide multiple channel type entries (in which the singular QUEUE name
> is specified on a per-entry basis)?  Or should the QUEUE keyword be allowed
> to have multiple values?

Each queue needs its own Channel Table entry.  Each queue is a different
channel for providing data to the printer, and each may have distinct
settings for the items in its Channel Table entry.  For instance, it's
very likely that queues will have different values for

> Also, we had (privately) discussed the notion of defining "well-known"
> LPD queue names to effect common services types, for example:
>   "Raw"      The print job data is processed "as is" with no translation.
>   "AutoCR"   Any linefeed character encountered in the job data stream
>              will have a carriage return character automatically inserted
>              after the linefeed character.
> Should we bring up this topic now while the MIB spec is in flux?

Every time we start digging into lpr/lpd, I get depressed.  But here are
a couple of thoughts: 

 1. One would like to be able to answer the question "What sort of print
    jobs can I submit on this channel." 

 2. RFC 1179 job submission specifies subcommands that designate how the
    data in the job is to be handled.  These correspond vaguely to
    PrtInterpreterLangFamily values, but with an eclectic set of
        Caltech Intermediate Form plot data
        TeX DVI data
        formatted text
        Berkeley Unix plot library output
        data with control characters
        ditroff output data
        data to be formatted with pr
        FORTRAN carriage control
        troff output data
        SUN raster format data
    For a while, I considered whether the prtChannelInformation item for
    a chLPDServer channel should specify which of these settings were
    allowed by the queue.  But the list of choices bears so little
    relation to current practice that there seemed little benefit.  

 3. Current practice seems to be more in line with what Jay described
    above, where the queue name is linked to some data type or set of
    processing conventions.  But each vendor has their own choice of

 4. Rather than trying to codify queue names, I'm now tending toward
    using the prtChannelCurrentJobCntlLangIndex and
    prtChannelDefaultPageDescLangIndex items to characterize the print
    jobs allowed by the channel. 

    Jay's "Raw" example would have appropriate interpreter index
    settings for job control language (a langPSPrinter or langPJL
    interpreter, for instance) and default page description language (a
    langPS interpreter, for instance).  The "AutoCR" example is more of
    a mess -- it needs a control language setting of "none," which
    doesn't seem to be an available choice, and an interpreter index
    setting for its default page description language that might be a
    langLineData or langSimpleText interpreter (or a new enum value). 

    Has the idea that a channel might not have job control been
    considered?  And is there a language corresponding to the UNIX-style
    interpretation of ASCII newline as linefeed (ASCII carriage return /

>>     chDECLAT(32),       -- ...
>>                         -- prtChannelInformation entries:
>>                         --   port name
>>                         --     name: PORT, optional, single value
>>                         --   service name
>>                         --     name: SERVICE, optional, single value
>>                         -- Exactly one of port and service must be
>>                         -- specified. 
> The last sentence is a bit confusing.  Are you saying that only ONE of
> the defined keywords can exist in the value?  Actually, the text makes
> it sound like a chDECLAT channel type MUST specify either the PORT or
> the SERVICE; that is, neither keyword is really optional.  Can you clarify
> this?

I was trying to get too economical with words.  Try this: 

                       -- Port and service are mutually exclusive;
                       -- one must be specified, but not both. 

So, yeah, each one is conditionally mandatory (;-), if you want to put
it that way.  I figured that, considered individually, each was
conditional, but there was an additional constraint when the two were
considered together.  Perhaps if we used the more structured format you
suggested in another posting, the entry would say "see below," rather
than "optional."  I think, in general, there will be interactions like
this that just have to be spelled out in descriptive text. 

::  David Kellerman         Northlake Software      503-228-3383
::  david_kellerman at Portland, Oregon        fax 503-228-5662

More information about the Pwg mailing list