Harry answered part of the question.
The concern revolves around the belief that some scenarios require
read-write access for certain values, and that prior management apps
expecting read-write access (the norm for 1759) might get read-only access
(allowed by v2). For example, a remote install task wants to write a few
values, such as the localization values, the current operator and service
person values, and maybe a few more. If a vendor claims to be compliant
with the printer MIB, but the mandatory service person info can't be set by
the customer, that seems pretty broken. Maybe the word "fundamental" is too
strong, but it's been a source of conversation for a few days here at Xerox.
In fact, for MOST objects, we can see how the MIN-ACCESS clause will ease
the implementation work (as Harry says), but it seems like the MIN-ACCESS
clauses were added without considering each object individually (as Harry
implies).
On that note, we now notice that of 53 objects with a MAX-ACCESS of
read-write, 51 have a MIN-ACCESS of read-only. The two without MIN-ACCESS
are prtGeneralReset and prtInputMediaDimXFeedDirDeclared, and we don't know
why they were chosen to be left without a MIN-ACCESS value.
And yes, I was the final editor for the v2 draft, but I (and we at Xerox)
didn't notice this MIN-ACCESS issue until now.
Thanks,
Gary Gocek, Xerox
> -----Original Message-----
> From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
> Sent: Friday, September 29, 2000 12:05 PM
> To: Gocek, Gary
> Cc: 'pmp@pwg.org'
> Subject: Re: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?
>
>
> Gary,
>
> Could you please explain why you feel "the new MIN-ACCESS clauses
> fundamentally change the printer MIB"?
>
> Ron Bergman
> Hitachi Koki Imaging Solutions
>
>
> "Gocek, Gary" wrote:
>
> > 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@crt.xerox.com]
> > > Sent: Thursday, September 28, 2000 4:35 PM
> > > To: 'pmp@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.
> > >
>
This archive was generated by hypermail 2b29 : Fri Sep 29 2000 - 13:10:30 EDT