Subject: PMP> new draft available

From: Randy Turner <[email-masked]>
Date: Mon, 02 Jun 1997 20:01:02 -0700

There is a new printer MIB draft available:

ftp://ftp.pwg.org/pub/pwg/pmp/drafts/draft-ietf-printmib-mib-info-02.txt

The attached file contains a list of the approved modifications that
have been
made to the MIB.

Along with these changes, the following changes were made to allow
correct compilation by
the ISODE (Mosy) MIB compiler. (YES! it compiles correctly!)

1. Two alert code enumerations were duplicated in the textual convention
PrtAlertCodeTC:

coverOpened and coverClosed

These two enumerations were defined twice: once at positions 3 and 4 and
then again later
at 501 and 502.  The enums 501 and 502 were removed.

2. There was no DESCRIPTION clause for prtConsoleDisplayBufferTable. I
added one.

3. The compiler strongly objected to no length constraint on the OCTET
STRING for
prtGeneralSerialNumber. I gave it a length of (256).

But it compiles now! which is quite a relief I must say.

Randy
>From - Sat May 31 20:28:34 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 08:53:22 -0400
Subject: PMP> Definitions of Active, Busy, Idle, Standby
Content-Length: 1005

To:       pmp%pwg.org @ interlock.lexmark.com ("pmp%pwg.org") @ SMTP
cc:        (bcc: Lloyd Young)
From:     Lloyd Young
Date:     03/13/97 07:47:23 PM
Subject:  PMP> Definitions of Active, Busy, Idle, Standby

I had an issue to refine the defintions of active, busy, idle
and standby.
Active: the printer or subunit is performing it's primary function.
Busy: the printer or subunit is performing a function (not necessarily
it's primary function) and is not immediately available for it's
primary function.
Idle: the printer or subunit is immediately available and waiting
for instructions.
Standby: the printer or subunit is not immediately available but is
waiting for instructions.
Lloyd Young                       Lexmark International, Inc.
Senior Program Manager            Dept. C14L/Bldg. 035-3
Strategic Alliances               740 New Circle Road NW
internet: [email-masked]     Lexington, KY 40550
Phone: (606) 232-5150             Fax: (606) 232-6740

>From - Sat May 31 20:28:35 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 08:55:18 -0400
Subject: PMP> Final draft of my clarifications from the 4/29 conference
	 call
Content-Length: 3736

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     emking @ alfred.pfv.prtdev.lexmark.com (Matt King) @ SMTP
Date:     04/29/97 07:16:44 PM
Subject:  PMP> Final draft of my clarifications from the 4/29 conference
          call

Hi folks,
Here is the final draft of my clarifications to the MIB.
--Matt
The items:
1. Clarification of binary event management.
2. Clarification of prtChannelCurrentJobCntlLangIndex
   and prtChannelDefaultPageDescLangIndex by defining zero to
   mean does not have one.
3. Clarification of what should cause prtGeneralConfigChanges to
   be incremented.
1. Clarification of binary event management.
a) In section 2.2.13.4, all references to "simple" alerts should be
changed to "unary".
b) The following paragraph should be inserted before the last paragraph
of the section.
"In the event that a critical binary alert must be managed out of the
alert table; when space allows, if the condition still exists, the alert
must be re-added to the alert table even if there was no subsequent
transition into the associated state.  It is recommended that this be
done for non-critical binary alerts as well.  Note that the new alert
entry will not have the same index as the origional."
3. Clarification of prtChannelCurrentJobCntlLangIndex
   and prtChannelDefaultPageDescLangIndex by defining zero to
   mean does not have one.
a) The description of prtChannelCurrentJobCntlLangIndex refers to the
"Control Language Interpreter".  Should this be "Job Control Language
Interpreter"?
b) Replace the last sentence of the prtChannelCurrentJobCntlLangIndex
description, "Must be 1 or greater", with "A value of zero indicates
that there is no current Control Language Interpreter for this channel".
c) Replace the last sentence of the prtChannelDefaultPageDescLangIndex
description, "Must be 1 or greater", with "A value of zero indicates
that there is no default Page Description Language Interpreter for this
channel".
4. Clarification of what should cause prtGeneralConfigChanges to
   be incremented.
a) In the first sentence of the prtGeneralConfigChanges description,
replace "media size" with "any media attributes".
b) Replace the the prtGeneralConfigChanges description with the
following.
"Counts configuration changes within the printer.  A configuration
change is defined to be an action that results in a change to any MIB
variable other than those that reflect status or level or those that act
as counters or gauges.  In addition, any action that results in a row
being added to or deleted from any Printer MIB table is considered a
configuration change.  Such changes will often affect the capability of
the printer to service certain types of print jobs.
Management applications may cache infrequently changed configuration
information about sub-units on the printer. This object should be
incremented whenever the agent wishes such applications to invalidate
that cache and re-download all of this configuration information,
thereby signaling a change in the printer's configuration.
The following are examples of actions that would cause the
prtGeneralConfigChanges to be incremented: Adding an output bin,
changing the media in a sensing input tray, changing the value of
prtInputMediaType via SNMP.
As an additional example, this counter would not be incremented when an
input tray is removed or the level of an input device changes."
--
Matt King                                     Opinions are my own and
Staff Engineer                                    are not necessarily
Lexmark International, Inc.                          those of Lexmark
[email-masked]

>From - Sat May 31 20:28:36 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 08:56:17 -0400
Subject: PMP> IANA Registry for Interface Types
Content-Length: 681

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     rbergma%dpc.com @ interlock.lexmark.com (Ron Bergman) @ SMTP
Date:     04/28/97 05:51:08 PM
Subject:  PMP> IANA Registry for Interface Types

The following is my proposed text for Tuesdays conference call:

3.4  Interface Types
The interfaces group of RFC 1213 contains only a partial list of interface
types that can be specified in the ifType object.  For a complete list
refer to the IANA registry at ftp://ftp.isi.edu/mib/ianaiftype.mib.

If the text proposed by Bill Wagner is approved, Bill's section 3.4
ahould be changed to 3.5.

     Ron Bergman

>From - Sat May 31 20:28:37 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 08:57:07 -0400
Subject: PMP> Proposed enumeration for PrtInterpreterLangFamilyTC
Content-Length: 515

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     adamsc%pogo.WV.TEK.COM @ interlock.lexmark.com (Chuck Adams) @
          SMTP
Date:     04/22/97 06:29:28 PM
Subject:  PMP> Proposed enumeration for PrtInterpreterLangFamilyTC

Here is the proposed text to add to PrtInterpreterLangFamilyTC:
     langPDF(54),  -- Adobe Portable Document Format (PDF)
          -- from Adobe Systems Incorporated
Chuck Adams
Tektxonix Inc.
[email-masked]

>From - Sat May 31 20:28:38 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 08:58:01 -0400
Subject: PMP> Reference to other MIB's in RFC
Content-Length: 12850

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     bwagner%digprod.com @ interlock.lexmark.com (Bill Wagner) @ SMTP
Date:     04/17/97 08:21:11 PM
Subject:  PMP> Reference to other MIB's in RFC

     I recovered the following from the archives. It was submitted once,
     and I thought it was accepted. It did not find it way into the draft
     however, and I am remiss in not having flagged this sooner. I hereby
     resubmit it, again with the understanding that it is supposed to
     reflect the intent of the group; it is not supposed to change
     anything, merely to provide an explicit statement of what might not be

     clear to a first time reader.

     Recent suggestions for additions to the Printer MIB have related to
     information obtainable from objects in the Host Resource MIB. This
     suggests that the degree to which the Host Resource MIB is to be
     implemented in the printer MIB and perhaps the dual function of the
     Host Resource MIB are unclear. The inconsistent degree of Host
     Resource MIB implementation may be a result of the somewhat non
     definitive statement of requirement in paragraph 3.2 of the RFC
     compounded by the ambiguity about what may be covered in the Host
     Resource MIB versus what shall be covered, combined with the
     complexity and lack of utility in covering all devices.
        The confusion is additional compounded by the fact that the Host
     Resource MIB both deals with a superset of `printer' (specifically
     multiple printers sharing a common network node) where the printers
     are listed devices, and a constituent component of printers,
     specifically the System controller. This dual roll is made possible by

     the prtStorageRef and prtDeviceRef tables in the printer MIB,
     which-"associate particular storage and device entries to printers".
     The printer itself is a device in the hrDevice table, perhaps one of
     several printer devices.
        There also seems inconsistent use of the interfaces group of MIB to

     identify non-network interfaces in a printer. This may be because the
     MIB II interface group states that each "interface is thought of as
     being attached to a `subnetwork'", because the correlation of
     interfaces listed in MIB-II to the printers listed in the hrDevice
     table is confusing, or because it did not seem necessary. However, the

     interfaces correlation in necessary for channels, and for the
     identification of job path in the Jobs monitoring MIB.
        I propose adding the following paragraphs (or some refined,
     corrected, sanitized version) under section 3. I do not necessarily
     subscribe to the inclusion of all this `stuff', but I believe that
     this proposed addition explicitly states what is currently implicitly
     required. I believe the RFC must explicitly define what is to be
     included and give a little help in understanding the rather Byzantine
     structure. If my interpretation is incorrect, then I welcome
     corrections.
        Bill Wagner, DPI

        3. Groups from other MIB Specifications
        This section identifies the groups from other MIB's that shall be
     supported to supplement and complete a printer MIB implementation. The

     section also describes some of the less obvious characteristics of the

     Printer MIB structure that are related to the inclusion of these other

     MIB groups.
        3.1. System Group
        All objects in the system group of MIB-II (RFC 1213) shall be
     implemented; however, as described in paragraph 3.4, implementers must

     carefully consider what constitutes the system.
        3.2. System Controller
        The Storage and Device Groups of the Host Resources MIB (RFC 1514)
     shall be implemented to support the printer(s) system controller, and
     any supporting devices. If deemed appropriate by the implementer,
     other Groups of the Host Resources MIB (System, Running Software,
     Running Software Performance, and Installed Software) may be
     implemented. Because of the structure of the Host Resources MIB, the
     devices constituting the system controller are at the same level as
     the printer. See paragraph 3.4 for an outline of the implications of
     this.
        3.3. Interface Group
        All objects in the Interfaces Group of MIB-II (RFC 1213) shall be
     implemented for all print information interfaces to the printer,
     including non-network interfaces.
        3.4 Implications of the use of Groups from other MIB's
        In structuring the Printer MIB, it is inconvenient to follow
     directly the hierarchical structure implicit in the printer block
     diagram (Figure 2). There are two reasons for this:
        1. Figure 2 suggests that the printer interface to the network is
     through the interfaces group. It is generally required that this
     network node is supported by an implementation MIB-II (RFC1213).
     However, the network node may support one printer or several. And
     further, the SNMP agent may be within the `system controller' part of
     the functional printer, or it may be completely external to the
     printer as represented on the diagram.. Therefore, the relationship
     between the MIB-II defined network node, the agent implementing the
     MIB's and the functional printer may not be consistent with the
     structure suggested in figure 2.
        2. The printer controller is, in many cases, a full fledged
     computer containing many of the resources of a standard host computer
     in a workstation. This includes devices such as the memory,
     interfaces, network, and indeed, printer. The Host Resources MIB has
     well developed structures for such devices. However, the Host Resource
     MIB only deals with devices associated with a single `host', and it
     considers the printer to be a part of this host on the same level as
     memory, processor, and other devices considered part of the System
     Controller of the printer.
        It was convenient therefore to conceive of a `host' associated with

     the SNMP agent and with the network node by which the agent and
     ultimately the printer(s) communicate with the network. All
     host-resource devices communicating though this network node
     (including the one or more printers that are to be characertized) are
     considered part of the host and are supported by implementation of the

     Host Resources Device Group and the Host Resource Storage group. The
     system group of MIB -II relates to this `host'. The printer (s) are
     identified as part of the device table in the Host Resources MIB. Note

     that this consideration specifically means that the "system" described
     in the Systems group of MIB-II may not be the printer, and that a
     managment application cannot assume that any of the variables in the
     Systems Group of MIB-II relate to the printer. Indeed, the types of
     information in the Systems Group, as specifically referring to the
     printer `system' are all contained elsewhere in the referenced Host
     Resouce MIB segments or in the defined Printer MIB itself.
        Another aspect of printer as a device consideration is that, not
     only are the printer and the host resource devices constituting the
     System Controller of the printer at the same level, but if there are
     multiple printers, these printers and the Host Resource devices
     constituting these printers are all at the same level, whether the
     devices are dedicated to one printer or shared. The functional
     hierarchy implicit in the printer block diagram is therefore flattened
     with respect to host resource devices.
        3.4.1 Host Resource MIB Device Group For each instance of a host
     resource device operating from a given network node, including the
     printer(s), the device is listed in the Host Resource MIB device table

     with the following attributes. hrDeviceIndex hrDeviceType
     hrDeviceDescr hrDeviceID hrDeviceStatus hrDeviceErrors The Device
     Description, Device ID and Device Status listed in this table for each

     printer identify and characterize that printer. The hrDevice index for

     each printer is included as an indexing value for almost all variables

     in the printer MIB. In the case of multiple printers, the printer MIB
     appears as a composite MIB for all printers considered part of this
     host. Each table of the printer MIB which includes hrDeviceIndex as an

     index will contain the variables for each printer.
        Non printer devices listed in the table are associated with one or
     more listed printer devices by the prtDeviceRefTable in the printer
     MIB. This table, as most in the Printer MIB, is indexed by
     hrDeviceIndex; but unlike most of the other tables where the devices
     of interest are printers, the devices of interest for this table are
     non-printer devices. The only accessible variable for each row in this

     table is the device number of the printer device which is associated
     with the indexed non printer device. The table includes a second
     index, prtDeviceRefSeqNumber, which allows a listed device to be
     associated with multiple printer devices.
        For example, a fully integrated printer may contain, as part of its

     system controller, hrDeviceProcessor , hrDeviceNetwork
     hrDeviceDiskStorage hrDeviceParallelPort hrDeviceSerialPort
     hrDeviceVolatileMemory hrDeviceNonVolatileMemory
        Ideally, these must all be listed as devices in the virtual host,
     along with the printer (hrDevicePrinter) itself. Therefore, in this
     example eight devices would be included with hrDevice Index values of
     1-8. Since there is but one printer, the prtDeviceRefTable in the
     printer MIB would contain 7 entries, each with a value identifying the

     printer hrDeviceIndex. Because there is only one printer, devices are
     not shared and the prtDeviceRefSeqNumber index is (1) in all cases.
        Further, the Host Resource MIB defines device specific tables to be

     supported for certain devices. These devices, and the primary
     significance of the additional table(s) are:
        hrProcessorTable: identification and significant characteristics of

     processor hrNetworkTable: correlates a network device to a key to
     ifIndex (MIB-II). hrPrinterTable and hrPrinterErrorTable: the
     mechanism communicating the status of each printer hrDiskStorageTable:
     identifies disk access and media type and capacity hrPartitionTable:
     partitions on long term storage devices hrFSTable: identifies local
     file system type, characteristics and pertinent parameters
        3.4.2 Host Resource Storage Group
        Program and data storage exist both as physical devices in the Host

     Resource Device Table, and as logical storage areas supported in the
     Host Resource Storage Group. Logical storage is listed and assigned an

     index in the hrStorageTable. Storage is correlated to specific
     printers by the prtStorageRefTable in the printer MIB. This table is
     indexed by hrStorageIndex. The only accessible variable for each row
     in this table is the device number of the printer device which is
     associated with the indexed storage. The table includes a second
     index, prtStorageRefSeqNumber, which allows logical storage to be
     associated with multiple printer devices.
        3.4.3 MIB-II Interface Group
        The interfaces by which the printer receives print data are
     identified within the Interfaces table of MIB-II. In the case of
     multiple printers, the network interface for the `host' as well as all

     of the interfaces for all printers are listed in this table. The
     interfaces may also be listed as devices in the Host Resource Device
     table. Network Port devices are identified by ifIndex to correlate
     them back to the MIB-II Interface table; no such provision exists for
     "serial" and "parallel" ports. Interfaces listed in the Host Resource
     device table may be correlated to specific printers in the `host' by
     the prtDeviceRefTable in the printer MIB; this may be useful if there
     are multiple printers. The ifIndex is also used to identify the
     interface associated with each channel in the Printer MIB Channels
     group. Therefore, specific interfaces are also correlated back to
     specific printers via the channels mechanism.

>From - Sat May 31 20:28:41 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 08:58:47 -0400
Subject: PMP> Description for chPortHTTP
Content-Length: 469

To:       rturner%sharplabs.com @ interlock.lexmark.com (Randy Turner) @
          SMTP
cc:       Lloyd Young, pmp%pwg.org @ interlock.lexmark.com @ SMTP
From:     rbergma%dpc.com @ interlock.lexmark.com (Ron Bergman) @ SMTP
Date:     04/17/97 12:55:12 PM
Subject:  PMP> Description for chPortHTTP

Randy,
The current description for chPortHTTP (page #42) is:
"...(RFC's XXXX,etc.)"
Should be:
"...(RFC's 1945 and 2068)"

     Ron Bergman

>From - Sat May 31 20:28:42 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:00:28 -0400
Subject: RE: PMP> prtConsoleColorTC
Content-Length: 563

To:       rturner%sharplabs.com @ interlock.lexmark.com @ SMTP
cc:       pmp%pwg.org @ interlock.lexmark.com @ SMTP (bcc: Lloyd Young)
From:     harryl%us.ibm.com @ interlock.lexmark.com (Harry Lewis) @ SMTP
Date:     05/01/97 07:18:15 PM
Subject:  RE: PMP> prtConsoleColorTC

Classification:
Randy, I think we have enough consensus to request that you add a new
type-2
enum to the
PrtConsoleColorTC (pg. 52-53) with the following definition:
 orange (10)
It'd be great, if you could tuck this in.
Harry Lewis - IBM Printing Systems

>From - Sat May 31 20:28:43 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:01:29 -0400
Subject: add a new value to PrtInterpreterLangFamilyTC
Content-Length: 1326

To:       rturner%sharplabs.com @ interlock.lexmark.com @ SMTP
cc:       Lloyd Young, harryl%us.ibm.com @ interlock.lexmark.com @ SMTP
From:     fujitani%isp.rp.ricoh.co.jp @ interlock.lexmark.com (Satoshi
          FUJITANI) @ SMTP
Date:     04/18/97 09:29:33 PM
Subject:  add a new value to PrtInterpreterLangFamilyTC

Hi Randy,
My name is Fujitani, Ricoh,CoLtd Tokyo Japan. I am a enginner for printer
and
multi-function peripheral networking. I have subscribed PMP for only few
weeks.
So I don't know how to add a value as below.
Could you please add a new value to PrtInterpreterLangFamilyTC enums?
        langRPDL()      -- Ricoh Page Description Language for printer.
                        -- Technical manual "RPDL command reference"
                        -- No 307029. RICOH Co,LTD.
We have shipped laser printers and multi-function peripherals that have
RPDL as printing language from 1988. This language is for Japan domestic
and have been developed by Ricoh originally.
If you have comments, please contact me via at the e-mail.
Best regards,
Satoshi
                                                Satoshi FUJITANI
                                                RICOH Co.,LTD. Tokyo Japan
                                                [email-masked]

>From - Sat May 31 20:28:45 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:02:23 -0400
Subject: PMP> langXJCL(53) description editing not finished
Content-Length: 1859

To:       rturner%sharplabs.com @ interlock.lexmark.com (Randy Turner) @
          SMTP
cc:       pmp%pwg.org @ interlock.lexmark.com @ SMTP (bcc: Lloyd Young)
From:     hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings)
          @ SMTP
Date:     04/21/97 04:37:53 PM
Subject:  PMP> langXJCL(53) description editing not finished

Randy,
On page 46 of the Internet-Draft, the description is only: "Xerox Corp."
Here is a copy of the 1-Oct-96 mail with the full description for XJCL.
Please update the Printer MIB accordingly.
Thanks,
Tom
Return-Path: <[email-masked]>
X-Sender: hastings@zazen (Unverified)
Date: Tue, 01 Oct 1996 22:34:33 -0700
To: [email-masked]
From: Tom Hastings <[email-masked]>
Subject: Updated request to register XJCL as a Printer Interpreter
  Language
Cc: [email-masked]
My action item from the August meeting:
I have secured agreement to prepend an X to the name JCL so that it does
not conflict with the long standing IBM batch processing language, JCL,
and to name the interpreter language Xerox Job Control Language.
Will the PWG please register this value at its upcoming meeting Oct 2-3.
          langXJCL(??)  -- Xerox Job Control Language (JCL). A Job Control
                        -- language originally developed for the Laser
                        -- Press printers and is capable of switching PDLs.
                        -- Technical reference manual:
                        -- "ART IV Reference Manual", No F33M.
                        -- Fuji Xerox Co., Ltd.
The contact person is the same about langART(48) as follows.
     Norio Iwamoto
     [email-masked]
     (044) 812-5174
     Fuji Xerox Co., Ltd.
     3-2-1 Sakado, Takatsu-ku, Kawasaki-shi.
     Kanagawa-ken, 213 Japan

>From - Sat May 31 20:28:44 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:02:51 -0400
Subject: PMP> Auxiliary Sheet objects should have group, not table, in
	 name?
Content-Length: 830

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings)
          @ SMTP
Date:     04/21/97 04:27:43 PM
Subject:  PMP> Auxiliary Sheet objects should have group, not table, in
          name?

Sorry, I haven't been able to follow this DL, so this may have been
covered:
On page 67 of the Internet-Draft, the Auxiliary Sheet Group objects:
  prtGeneralStartupPage and prtGeneralBannerPage
should have the name of the group in them, not the name of the table,
to be consistent with the rest of the objects in the General Table.
So the names would be changed to:
  prtAuxiliarySheetStartupPage and prtAuziliarySheetBannerPage
And of course, change PrtGeneralEntry on page 61 to agree.
Thanks,
Tom

>From - Sat May 31 20:28:46 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:03:13 -0400
Subject: PMP> Mike MacKay is with Novell, not IBM
Content-Length: 471

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings)
          @ SMTP
Date:     04/25/97 07:19:30 AM
Subject:  PMP> Mike MacKay is with Novell, not IBM

Randy,
I just happened to notice the Mike MacKay is cited in the end of the
Printer
MIB as being with IBM. He used to work for Xerox and now works for Novell.
Can you fix?
Thanks,
Tom

>From - Sat May 31 20:28:47 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:04:10 -0400
Subject: PMP> MIB draft edit: change "intended" to "current" for
	 SubUnitStatus
Content-Length: 3305

To:       Lloyd Young, rturner%sharplabs.com @ interlock.lexmark.com @ SMTP
cc:       pmp%pwg.org @ interlock.lexmark.com @ SMTP,
          STUART%KEI-CA.CCMAIL.CompuServe.COM @ interlock.lexmark.com @
          SMTP, rbergma%dpc.com @ interlock.lexmark.com @ SMTP
From:     jkm%underscore.com @ interlock.lexmark.com (JK Martin) @ SMTP
Date:     04/30/97 08:59:55 AM
Subject:  PMP> MIB draft edit:  change "intended" to "current" for
          SubUnitStatus

Randy and Lloyd,
Since we're getting right down to the wire on finalizing the draft,
it might be best to "capture" these kinds of edits and send them
to you (both) directly, perhaps making it a bit easier to keep track
of these changes to be made.
There have been no objections (to date) for the proposal by Stuart Rowley
to change "intended" to "current" when describing the "Online" state for
SubUnitStatus.
The changes aren't too bad:
  Section 2.2.12.2.2  Sub-unit Status
     The subsection of "On-line" has "Intended" twice.
     The subsection of "Transitioning" has the line "At intended state";
     this should change to "At current state".  The succeeding line
     says "Transitioning to intended state", but this might be ok as is.
  The MIB section defining "PrtSubUnitStatusTC"
     Exactly the same edits as above.
Thanks, Randy, for making these changes.  Lloyd, hopefully this message
can be used as "backing justification" should these changes be challenged
in the future.
     ...jay
----- Begin Included Message -----
>From [email-masked] Tue Apr 29 21:23 EDT 1997
Date: Tue, 29 Apr 1997 17:16:19 -0700 (PDT)
From: Ron Bergman <[email-masked]>
To: JK Martin <[email-masked]>
cc: [email-masked]
Subject: Re: PMP> What exactly is the definition of "Offline"?
X-X-Sender: [email-masked]
Jay,
I agree, "Intended" appears not to be what was *intended* ;-)
This should change to "Current".
     Ron Bergman

On Tue, 29 Apr 1997, JK Martin wrote:
> Stuart,
>
> Yes, I see where one would be confused about the definition of "Online"
> in your example.
>
> How about the rest of the folks?  Should we change "Intended" to
"Current"
> as Stuart proposes?  (I tend to agree with his proposed change.)
>
>    ...jay
>
> ----- Begin Included Message -----
>
> From [email-masked] Tue Apr 29 15:35 EDT 1997
> From: [email-masked]
> Date: 29 Apr 97 15:32:33 EDT
> To: <[email-masked]>
> Subject: Re: PMP> What exactly is the definition of "Offline"?
>
>      Jay,
>
>      I have been baffled by the use of Online in PrtSubUnitStatusTC.  The

>      text is:
>
>      On-Line
>
>                       Intended state is On-Line       0
>                       Intended state is Off-Line      32
>
>      I thought this value was NOT indicating the current state of the
>      device, but rather the intended state (although I couldn't think of
>      any devices with intended states of Off-line).  If this is to
indicate
>      current state, "Intended" should be changed to "Current".
>
>      I also agree that what constitutes an Off-line state should be
>      clarified.
>
>      Stuart Rowley
>      Kyocera Electronics
>
>
> ----- End Included Message -----
>

----- End Included Message -----

>From - Sat May 31 20:28:48 1997
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 1997 09:05:06 -0400
Subject: PMP> Novell channel types
Content-Length: 5202

To:       pmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:        (bcc: Lloyd Young)
From:     SISAACSON%novell.com @ interlock.lexmark.com (Scott Isaacson) @
          SMTP
Date:     05/02/97 11:24:38 AM
Subject:  PMP> Novell channel types

At one of the last PMP calls, we talked about the queue-based
Novell channel types:
chNetwareRPrinter(9) and chNetwarePServer(10)
and what would be in the channel information fields for these
channel types.
The discussion centered around "how to allow a client to bootstrap
itself to find out HOW to print to this printer using this channel type".
In
the queue-based Novell environment, this eventually means finding the
name of the queue(s) which is(are)  being serviced by this printer.
A network shared printer services a queue either directly, that is the
printer is in queue server mode, or indirectly, the printer is in nprinter
mode and is attached to a pserver which is servicing the queue.
I suggested that we needed to include all queue information in the
channel table to realize this goal.  However, it is possible to get by with
just the pserver (or nprinter) info since all of the configuration info
(which queues are being serviced) is in the name service associated
with the objects that represent the pserver or nprinter.    A printer in
pserver
mode, logs in, gets all of the queue info from the objects in the name
service, and starts polling those queues.  The printer need not store this
info persistently since it can always go back to the name service to get
its
configuration info.
A client could do the SAME thing.  Once it knows the
pserver info, it could follow that object's configuration back through the
name service in order to get the queue info.  It then knows
how to submit a job to the printer.
To review, there are two channel types and each is supprted in the
3.x and/or 4.x environments:
chNetwareRPrinter(9), -- Novell, Inc.
-- For each entry of this type, the prtChannelInformation
-- must have a pair of keywords.  For NetWare 3.x channels
-- this must be a {PServer, Printer} pair.  For  NetWare 4.x
-- channels and for IntranetWare channels this must be a
-- {NDSTree, NDSPrinter} pair.
-- prtChannelInformation keywords:
--
-- Print Server Name
-- Keyword: "PServer"
-- Syntax: Name
-- Multiplicity: Single
-- Description: The PServer's SAP name
--
-- Printer Number
-- Keyword: "Printer"
-- Syntax: Integer
-- Status:
-- Multiplicity Single
-- Description: The printer number
-- NDS Tree
-- Keyword: "NDSTree"
-- Syntax: Name
-- Multiplicity: Single
-- Description: The tree's SAP name
--
-- NDS Printer object
-- Keyword: "NDSPrinter"
-- Syntax: Text (encoded unicode)
-- Status:
-- Multiplicity Single
-- Description: The fully qualified name of the Printer
--
-- In the 3.x environment, the client checks the Bindery object
-- representing the named PServer.  The client then checks for
-- queues which are associated with the numbered Printer.
-- In the 4.x and IntranetWare  case, the client looks up the queues
-- which are associated with the NDS Printer object in the named
-- Tree.  Depending on client access rights to those queues, the
-- client submits jobs to the appropriate queue.

chNetwarePServer(10), -- Novell, Inc.
-- For each entry of this type, the prtChannelInformation
-- must have a pair of keywords.  For NetWare 3.x channels
-- this must be a {Server, PServer} pair.  For  NetWare 4.x
-- channels and for IntranetWare channels this must be a
-- {NDSTree, NDSPServer} pair.
-- prtChannelInformation keywords:
-- Server Name
-- Keyword: "Server"
-- Syntax: Name
-- Status:
-- Multiplicity Single
-- Description: The SAP name of the server for
-- which the PServer is defined
--
-- PServer
--
-- Name: "PServer"
-- Syntax: Name
-- Status:
-- Multiplicity Single
-- Description: The Bindery name of the
-- PServer
--
-- NDS Tree
--
-- Keyword: "NDSTree"
-- Syntax: Name
-- Status:
-- Multiplicity: Single
-- Description: The NDS Tree name
--
-- PServer
--
-- Keyword: "NDSPServer"
-- Syntax: Text (encoded unicode)
-- Status:
-- Multiplicity Single
-- Description: The fully qualified name
-- of the PServer object in the tree
--
-- In the 3.x environment, the client checks the Bindery object
-- representing the named PServer on the named Server.
-- In the 4.x and IntranetWare case, the client checks the NDS
-- object representing the named PServer in the named Tree.
-- In either case, he client then checks for all queues associated that
-- PServer object.  Depending on client access rights to those
-- queues, the client submits jobs to the appropriate queue.

************************************************************
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: Harry Lewis <[email-masked]>
Date: Tue, 3 Jun 1997 11:59:51 -0400

Randy - thanks for all your hard work!

Can anyone (Lloyd, Chirs?) provide a *brief* outline of what we should
anticipate as a timeline with respect to this draft becoming a standard?

Harry

---

From: [email-masked]
Date: Tue, 3 Jun 1997 16:33:10 -0400

Harry,
This is a tough one to answer because so much is dependent on
items outside of our control. For example, we have to get the HR
MIB advanced before the Printer MIB can advance. I am thinking
that we might still be at a Draft Standard level by the end of
this year but I am always optimistic. Chris and I will certainly
keep the working group informed as we progress along the
standards track.
Lloyd

---

From: Bob Pentecost <[email-masked]>
Date: Tue, 3 Jun 1997 15:04:15 -0600

Lloyd,

Am I correct in assuming we will have a new RFC number in the next couple of months?

Bob

----------
From:  [email-masked][SMTP:[email-masked]]
Sent:  Tuesday, June 03, 1997 2:33 PM
To:  [email-masked]
Subject:  Re: PMP> new draft available

Harry,