Gary, I'm not sure the genesis of documenting MIN-ACCESS. I guess I
considered it a formality.
Our interpretation of the spirit of the change to specify MIN-ACCESS was
to reflect that, in some cases, the printer can more accurately and/or
reliably sense the value. Example - level of paper in tray is R/W because
some printers are unable to sense. This allows an "operator" to load media
and use a software application to SET the current level. However, if the
device automatically detects dynamic changes in paper level... it seems
appropriate and desirable to disallow the SET. If the printer's own
measurements give an accurate, up-to-date value for an OID, then making it
R/W could actually reduce accuracy.
For OIDs like General and Console localizations, I agree, it doesn't seem
too practical to have specified MIN-ACCESS. Perhaps it would make sense if
the printer could only support one language (or one language at a time...
with re-boot required). This seems pretty far fetched.
Harry Lewis
IBM Printing Systems
"Gocek, Gary" <GGocek at crt.xerox.com>
Sent by: pmp-owner at pwg.org
09/29/2000 06:46 AM
To: "'pmp at pwg.org'" <pmp at pwg.org>
cc:
Subject: RE: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?
I made my point a little too broadly. We can see how MIN-ACCESS clauses
ease the implementation burden. However, we noticed a couple of cases
(prtGeneralCurrentLocalization and prtConsoleLocalization in particular)
where we feel that the new MIN-ACCESS clauses fundamentally change the
printer MIB, and we wonder if there is a justification for adding those
particular MIN-ACCESS clauses. There might be a few more instances, but
not
all 51.
Thanks again,
Gary
> -----Original Message-----
> From: Gocek, Gary [mailto:GGocek at crt.xerox.com]
> Sent: Thursday, September 28, 2000 4:35 PM
> To: 'pmp at pwg.org'
> Subject: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?
>>> Way back in the first draft (1997) of the new Printer MIB
> following RFC
> 1759, all objects with a MAX-ACCESS of read-write were given
> a MIN-ACCESS of
> read-only. Previously, only two objects had a MIN-ACCESS
> clause, but in the
> latest draft of Printer MIB v2 there are 51 such objects.
> There is a short
> note about this change in the document "changes_to_rfc_1759.pdf".
>> In a recent discussion with my colleagues, we wondered why
> these MIN-ACCESS
> clauses were added. Of course, we can implement read-write
> objects if we
> want to, because that's what the MAX-ACCESS clauses state.
> But we don't
> understand why the MIN-ACCESS clauses were added. We see cases where
> read-write access is helpful, such as during a remote printer
> installation.
>> Agent implementations that are compliant with RFC 1759 have
> the objects
> implemented as read-write, since there are no MIN-ACCESS
> clauses in 1759
> that allow read-only. New agent implementations of the v2
> MIB would be
> compliant with read-only access, but might break old
> management or other
> apps that expect to be able to set all those values.
>> Can anyone think of a good defense for the new MIN-ACCESS clauses?
>> Thanks,
> Gary Gocek, Xerox Corp.
>