I apologize for missing what probably was stated, but is the intent to
finalize the excellent list of 'interesting' printer states (as
supplemented by others), or to agree on all of the values associated
with each state?
Further, assuming even that we are just finalizing the 'states', is it
implicit that compliance will require a printer to discern such
'states'? For example, I would regard Initial Power Up as a 'mute'
state in may cases simply because the printer can initialize before
the network interface sorts out who it is, where it is, does its
advertising, gets stacks built, and services the SNMP request.
Finally, I again suggest that the MIB walk analysis must include the
results of the referenced sections of MIB-II, unless of course we have
decided that the requirement for these groups is not necessary in the
printer MIB. Indeed, the argument that the Systems Group objects may
belong to some (real) host system and not to the printer may also be
applied to the Interface Group. How is one to distinguish between an
interface on the host system and an interface on the printer.
Alternatively, the main thing the printer needs is an identification
of the interface for reference to channel and potentially job
information; for printer management, there seems to be little need
(and in some cases, little applicability) to the rest of the
parameters in the interface table. There are several things involved
here, including the handling of local interfaces on the printer, the
handling of multiple NIC's, the coding used for interface types not
identified in MIB-II, and the degree of support for the various
parameters in the interface table. Also, although it is independent of
the printer MIB per se, there should be some understanding of need to
which a well designed interface node (in the printer or external to
it) should support the entire (current) MIB-II. I believe this is
necessary because, to the extent that we say certain groups are
necessary, it is inferred that the unlisted groups need not be
supported.
(Sorry to be so long winded about this, but it is an area that I have
substantial difference in implementation)
BTW, I have spent a little time on the wording of the
prtInterpreterFeedAddressability (and XFeedAddressibility), relying
upon memory of the discussions. What I do not remember however is what
anyone is going to use these values for. Considering that the tested
MIB implementations (I think) either misunderstood what was wanted or
put in a nominal value, is it going to be used for anything?
Bill Wagner Osicom/DPI
______________________________ Reply Separator _________________________________
Subject: PMP> Next PMP Conference Call
Author: Lloyd Young <lpyoung at lexmark.com> at Internet
Date: 2/20/97 4:17 PM
We completed the review of the MIB Walk Results in the conference
call today. If my count is correct, we have 6 clarifications to the
Printer MIB from reviewing the MIB walk.
The next PMP conference call will be on Wednesday March 5th from
2:00 to 4:00 PM EST (11:00 AM to 1:00 PM PST), access code: 820010,
phone number: 423-673-6717. The purpose of this call is to finalize
the printer state conditions (err1.txt) published in e-mail dated
2/18/97 from Chuck Adams. An updated copy of the pdf file has been
placed on the PWG server. There were minor formatting problems in
the original pdf file. The complete URL address to this file is
ftp://ftp.pwg.org/pub/pwg/pmp/contributions/err1.pdf. Discussion
regarding these conditions and resolution of most open issues
should occur via the mailing list. The purpose of the conference
call is to resolve any open issues that cannot be closed via the
mailing list.
Lloyd Young Phone: (606) 232-5150
Lexmark International Inc. Fax: (606) 232-6740
740 New Circle Road NW internet: lpyoung at lexmark.com
Lexington, KY 40511