If nothing else, this thread serves as useful information
to be used as a rough design guideline for future efforts,
that's all.
I don't think anyone is jumping up and down to get the
FIN MIB substantially changed at this point. (Although
Paul Moore might be... ;)
One other thing. Please don't say that concerns weren't
raised about this generic topic before, because they were.
The designers of the Job MIB simply decided to ignore it,
that's all.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Harry Lewis wrote:
>
> 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