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
> -----Original Message-----
> From: Gocek, Gary [mailto:GGocek@crt.xerox.com]
> Sent: Thursday, September 28, 2000 4:35 PM
> To: 'firstname.lastname@example.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
> 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?
> Gary Gocek, Xerox Corp.
This archive was generated by hypermail 2b29 : Fri Sep 29 2000 - 08:54:50 EDT