>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 entail=
s
>and clearly considering the alternatives. I don't think I ever saw tha=
t
>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). P=
lease
take a look (ESPECIALLY with the Job MIB) at the types of objects we ar=
e
managing!
>I lacked the time and energy to raise the issue myself here.
Welcome to the club. Precisely why rehashing seems like a tiresome setb=
ack.
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 wit=
h the
>FIN or the JOB MIBs. This issue was timely for those a year and two a=
go.
Thank You!
>But the point is still well taken.
OK. So what are you suggesting? What is the real issue NOW? I would lik=
e 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 manda=
tory and
optional attributes (this was ugly when we tried it!). Are we saying th=
at some
of our problems are just to complex to address with SNMP and the soluti=
on space
should move to the SDP arena? Do we just need a FIN MIB FAQ to help wi=
th the
understanding? I'm open to suggestions and eager to find a direction wi=
th more
consensus.
Please remember that there are significant numbers of PWG members who t=
hink 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 r=
eceived
less fame than (say) IPP. Also note that any solution... SDP or whatev=
er... is
VERY likely to result in SIMILAR complexity... after all the problems w=
ill 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 excel=
lent
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 approa=
ch
does not follow the SNMP model. Instead, it uses SNMP as a mere framew=
ork
or platform on top of which to build a significantly different attribut=
es
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 jo=
b of
browsing attributes tables? I'd be very surprised - albeit pleasantly =
so.)
It is conceivable that this attributes-table poor solution (poor becaus=
e
unsupported, as above) is the best available under the circumstances, t=
hat
all the other available choices are worse. However, it is inappropriat=
e
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 t=
ime
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 ag=
o.
But the point is still well taken.
/Paul Gloger
=