I am looking at attribute sets for printers. Rather than sit and think for
several weeks, the obvious thing to do is to look at the existing work done
by large groups of intelligent people who know this stuff inside out. So I
looked in TIPSI, here is a big set of attributes with their values and
meaning. Next I looked in 1759, aha - here are really detailed attributes
for paper trays, Oh and marking systems, and even cover panels - great. Next
I looked in the finisher MIB, great here is a REALLY detailed analysis of
punching and here is a detailed analysis for.. - but no - there are no more
detailed anaylses, only a scheme for recording them. So I have hit a
roadblock - where do I go to look for the attributes for, say , a perfect
binder. The FIN MIB requires that there be another document somewhere else -
the 'Perfect Binder Attribute Set for FIN MIB'
I have a practical problem - not a architectural one.
What you should have done is to do FIN MIB part1 (staple, punch and general
status), then done part2 (Binders, sorters and inserters) then
part3(shredders, igniters and bleachers). Or even done a separate MIB for
each FIN sub-unit.
I think the criticism that we should have said this earlier is not
reasonable. Nobody can read all drafts at all stages of revision.
> -----Original Message-----
> From: Harry Lewis [SMTP:harryl@us.ibm.com]
> Sent: Friday, June 19, 1998 8:27 AM
> To: fin@pwg.org
> Cc: jkm@underscore.com; rbergma@dpc.com; Paul Moore;
> hastings@cp10.es.xerox.com; Paul_Gloger@cp10.es.xerox.com
> Subject: Re: FIN> On reading the FIN draft
>
> Criticism can be healthy... and your points of view are valid, although I
> must
> say I wish they had been more timely. There ARE other points of view which
> were
> obviously factored into the design.
>
> >However, it is inappropriate behavior on the part of a standards body
> >to choose such a course, to go charging off into wild new territory,
> >without first at least clearly recognizing the problems that it entails
> >and clearly considering the alternatives. I don't think I ever saw that
> >done here.
>
> I'll spare the counter-criticism... rather, I'd like to seek a show of
> hands
> how many people are aware of customers using generic web browsers to
> effectively manage print, printers or printer extensions (finishers).
> Please
> take a look (ESPECIALLY with the Job MIB) at the types of objects we are
> managing!
>
> >I lacked the time and energy to raise the issue myself here.
>
> Welcome to the club. Precisely why rehashing seems like a tiresome
> setback.
> Let's see... haven't we gone through this with IPP recently?
>
> >Of course it is rather late to be raising this issue in connection with
> the
> >FIN or the JOB MIBs. This issue was timely for those a year and two ago.
>
> Thank You!
>
> >But the point is still well taken.
>
> OK. So what are you suggesting? What is the real issue NOW? I would like
> to see
> this discussion move to a more productive stage as opposed to a
> critical/defensive one. I'm hearing "We're gone too far with "SNMP"... So
> what's the antidote? Do we back up to a flat FIN MIB with sets of
> mandatory and
> optional attributes (this was ugly when we tried it!). Are we saying that
> some
> of our problems are just to complex to address with SNMP and the solution
> space
> should move to the SDP arena? Do we just need a FIN MIB FAQ to help with
> the
> understanding? I'm open to suggestions and eager to find a direction with
> more
> consensus.
>
> Please remember that there are significant numbers of PWG members who
> think the
> FIN MIB is fine... and worked quite hard to get it there. Please don't
> underestimate the effort and dedication even though the working group
> received
> less fame than (say) IPP. Also note that any solution... SDP or
> whatever... is
> VERY likely to result in SIMILAR complexity... after all the problems will
> be
> the same... we just won't be able to look back and say... "well, THAT's
> not
> SNMP!"
>
> Harry Lewis - IBM Printing Systems
>
>
>
> fin-owner@pwg.org on 06/18/98 11:14:00 PM
> Please respond to fin-owner@pwg.org
> To: fin@pwg.org
> cc: Paul_Gloger@cp10.es.xerox.com, hastings@cp10.es.xerox.com,
> paulmo@microsoft.com, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com,
> jkm@underscore.com
> Subject: Re: FIN> On reading the FIN draft
>
>
> I would like to echo Jay's statement, that Paul Moore has made an
> excellent
> point, and respond to Ron's question, "In what way does the use of
> attributes break SNMP?"
>
> The complaint is not that "the use of attributes breaks SNMP." The
> complaint is that the use of attributes like this is really not SNMP. As
> Paul M. says, SNMP has a clear, central model for representing
> objects/attributes and values thereof, and this attributes table approach
> does not follow the SNMP model. Instead, it uses SNMP as a mere framework
> or platform on top of which to build a significantly different attributes
> and values representational model. And it does this without benefit of
> appropriate documentation or standards or infrastructure or technical
> support or tooling or diagnostics or any of the zillion things that are
> normally expected when a new standard data representational model is
> established. (Does anybody have a MIB browser that will do a useful job
> of
> browsing attributes tables? I'd be very surprised - albeit pleasantly
> so.)
>
> It is conceivable that this attributes-table poor solution (poor because
> unsupported, as above) is the best available under the circumstances, that
> all the other available choices are worse. However, it is inappropriate
> behavior on the part of a standards body to choose such a course, to go
> charging off into wild new territory, without first at least clearly
> recognizing the problems that it entails and clearly considering the
> alternatives. I don't think I ever saw that done here. I lacked the time
> and energy to raise the issue myself here. Paul M. is now raising it.
>
> Of course it is rather late to be raising this issue in connection with
> the
> FIN or the JOB MIBs. This issue was timely for those a year and two ago.
> But the point is still well taken.
>
> /Paul Gloger
>
>
>
>
>
>